# [safe_numerics] Formal review starts today

19 messages
Open this post in threaded view
|

## [safe_numerics] Formal review starts today

Open this post in threaded view
|

## Re: [safe_numerics] Formal review starts today

 On 3/1/17 3:36 PM, Andrzej Krzemienski via Boost wrote: Andrzej - why don't we post this on reddit/r/cpp as well? Robert Ramey > Andrzej Krzemieński, review manager. > > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost> _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Open this post in threaded view
|

## Re: [safe_numerics] Formal review starts today

 Ok, here it goes: https://www.reddit.com/r/cpp/comments/5x1z67/boostsafe_numerics_formal_review_starts_today/2017-03-02 1:48 GMT+01:00 Robert Ramey via Boost <[hidden email]>: > On 3/1/17 3:36 PM, Andrzej Krzemienski via Boost wrote: > > Andrzej - why don't we post this on reddit/r/cpp as well? > > Robert Ramey > > Andrzej Krzemieński, review manager. >> >> _______________________________________________ >> Unsubscribe & other changes: http://lists.boost.org/mailman>> /listinfo.cgi/boost >> >> > > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman> /listinfo.cgi/boost _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Open this post in threaded view
|

## Re: [safe_numerics] Review Part 1 (Documentation)

 In reply to this post by Boost - Dev mailing list AMDG All comments are as of 3bcfabe1cafb8ef6edf08d3bd8730a1555b1c45d General notes: You should have a root index.html that redirects to the top level documentation page. There are two copies of proposal.pdf in the repository. safe_numerics.pdf seems to be out-dated. VS2015: FAIL (as expected) directory structure is not quite boost ready. (needs include/boost/numeric/ instead of just include/) The include paths used in the documentation are a mess. I see at least 6 different variations: - boost/safe_numerics/include/ - boost/safe_numerics/ - safe/numeric/ - boost/numeric/ - safe_numerics/include/ - ../include - ../../include In boostbook, enables C++ syntax highlighting for code snippets.  (This is enabled by default for programlisting, but is used for non-C++ content enough that it needs to be specified.) Introduction: "Since the problems and their solution are similar, We'll..." "We" should not be capitalized. "...the results of these operations are guaranteed to be either arithmetically correct or invoke an error" "either ... or ..." here has a noun on one side and a verb on the other.  Try "... either to be ... or to invoke ..." "#include " I believe that this should be "safe_numerics" (with an "s") "Enforce of other program requirements using ranged integer types." Delete "of" "The library includes the types safe_range(Min, Max) and safe_literal(N)" These don't look like any C++ type I've ever seen unless they're macros. tutorial/1.html "When this occurs, Most" lowercase "Most" "When this occurs, Most C++ compilers will continue to execute with no indication that the results are wrong" Is it the compiler that continues to execute or is it the program built by the compiler? "        // converts variables to int before evaluating he expression!" s/he/the/ "The solution is to replace instances of char type with safe type" There are no char's in this example. tutorial/2.html: "This is a common problem with for loops" Is this really true?  The most common pattern of integer for loops is for(i=0;i tutorial/7.html         std::cout << x / y;         std::cout << " error detected!" << std::endl; Should this be "NOT detected"? eliminate_runtime_penalty.html: The name trap_exception doesn't convey the meaning of causing a compile-time error to me.  To me the term 'trap' implies a signal handler. eliminate_runtime_penalty/1.html: The links for native, automatic, and trap_exception are broken. eliminate_runtime_penalty/3.html     throw_exception // these variables need to need to what? integer.html: "std::numeric_limits.is_integer" should be "::is_integer" safe_numeric_concept.html: "However, it would be very surprising if any implementation were to be more complex that O(0);" I think you mean O(1).  O(0) means that it takes no time at all. "... all C++ operations permitted on it's base type..." s/it's/its/ "( throw exception, compile time trap, etc..)" Delete the leading space. promotion_policy.html: "auto sz = sx + y; // promotes expression type to a safe which requires no result checking is guaranteed not to overflow." The line wrapping ends up uncommented. What happens for binary operators when the arguments have different promotion policies?  Is it an error? Does the implementation randomly pick one?  Is there some kind of precedence rule for promotion policies? (Note: the same thing applies to exception policies) exception_policy.html: "EP | A type that full fills the requirements of an ExceptionPollicy" s/full fills/fulfills/, s/ExceptionPollicy/ExceptionPolicy/ "EP::underflow_error(const char * message)" Underflow is a floating point error that happens when the value is too close to 0.  (INT_MIN - 1) is an overflow error, not an underflow error. "template boost::numeric::no_exception_support" What do the arguments mean?  According to the table, there a 6 functions, not 3. safe.html: "T | Underlying type from which a safe type is being derived" "derived" has a specific meaning in C++ which is not what you mean. "...at runtime if any of several events result in an incorrect arithmetic type." It isn't the type that's incorrect, is it? "If one wants to switch between save and built-in types ..." s/save/safe/ "this type of code will have to be fixed so that implicit conversions to built-in types do not occur" So are explicit casts allowed? "This is because there is no way to guarantee that the expression i * i" The second 'i' seems to be outside the block. "This can be justified by the observe" This sentence is incomplete. "This can be done by specifying a non-default type promotion policy automatic" Should be "policy, automatic."  Also, automatic should probably be "All the work is done at compile time - checking for exceptions necessary (input is of course an exception)" I can't parse this sentence.  Also, the '-' should be an em-dash, I think. safe_range.html: "MIN | must be non-integer literal" I think this is supposed to be "non-negative integer" Also, this is only true for safe_unsigned_range. It would by weird if safe_signed_range didn't accept negative arguments. #include The directory safe/numeric/ doesn't exist.     safe_unsigned_range<7, 24> i missing ';' static_assert(std::is_same); Syntax error: expected '>' befor ')' Also, safe is defined in safe_integer.hpp which is not #included. promotion_policies/native.html: "It's main function is to trap incorrect..." s/It's/Its/ promotion_policies/cpp.html "...we can force the evaluation of C++ expressions test environment..." "...expressions /in the/ test..." Unless I'm misunderstanding something, the use of trap_exception will fail to compile at: d *= velocity; "Note the usage of the compile time trap policy in order to detect at compile time any possible error conditions. As I write this, this is still being refined. Hopefully this will be available by the time you read this." This comment seems out-dated. exception_policies.html: "no_exception_support" So now we have 4 parameters? exception_policies/trap_exception.html: "This exception policy will trap at compile time any operation COULD result in a runtime exception" There's a missing word here.  "...compile time /if/ any..." is one possible fix. exception_policies/no_exception_support.html Template Parameters table: waaaaaay too many O's. Also, the first two parameters (no exception and uninitialized) are missing. library_implementation.html: "correct bugs in it, or understand it's limitations" s/it's/its/ interval.html: boost/numeric/interval.hpp and boost::numeric::interval are already taken by Boost.Interval. checked_result.html: "checked_result(e, msg)" 'e' was not defined. "static_cast(c) | R | extract wrapped value - asserts if not possible" I think this is supposed to return the message as 'const char *' not the value as 'R'. exception_type.html: "dispatch(overflow_error, "operation resulted in overflow");" The template parameter EP is missing. rationale.html: "2. Can safe types be used as drop-in replacement for built-in types?" replacements (plural) "#include   typedef safe_t int16_t;" This may or may not compile as it is unspecified whether cstdint defines ::int16_t. In Christ, Steven Watanabe _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Open this post in threaded view
|

## Re: [safe_numerics] Review Part 1 (Documentation)

Open this post in threaded view
|

## Re: [safe_numerics] Review Part 1 (Documentation)

 AMDG On 03/02/2017 03:47 PM, Robert Ramey via Boost wrote: > On 3/2/17 12:12 PM, Steven Watanabe via Boost wrote: >> >> >> The include paths used in the documentation are a mess. >> I see at least 6 different variations: >> - > > Hmmm - where - in the documentation? In the examples? or?. >   This was just from reading the html documentation. the code taken from example/ constently uses ../include/ (probably because it was actually tested and this variation is one that works). The reference sections under Type Requirements and Types have the most variations such as: Header #include Header #include >> >> In boostbook, enables C++ >> syntax highlighting for code snippets.  (This is >> enabled by default for programlisting, but >> is used for non-C++ content enough that it needs >> to be specified.) > Hmmm - right now I'm using program listing and it looks good - syntax is > colorized.  For inline I'm using without the language.  Are > you suggesting that I change the inline to   Yes.  This is just a minor stylistic detail. The only real difference is that it will change the color of int in inline code. > > >> "However, it would be very surprising if any implementation were to be >> more complex that O(0);" >> I think you mean O(1).  O(0) means that it takes no time at all. > Hmm - to me O(0) is fixed time while O(1) is time proportional to x^1. > But I'll rephrase the O() notation which is confusing in this context. > The formal definition of O() is f(x) \in O(g(x)) iff. \exists C, x_0: \forall x > x_0: |f(x)| <= |Cg(x)| If g(x) = 0, then this reduces to \exists x_0 \forall x > x_0: f(x) = 0 i.e. the running time is zero. If g(x) = 1, then we have \exists x_0 \forall x > x_0: |f(x)| <= |C| meaning that the running time is less than some constant, regardless of the value of x. ...which brings us to the real problem with using big-O here: what is x?  For sequence algorithms, x is the length of the sequence, but there's nothing like that here. >> >> What happens for binary operators when the arguments >> have different promotion policies?  Is it an error? >> Does the implementation randomly pick one?  Is there >> some kind of precedence rule for promotion policies? >> (Note: the same thing applies to exception policies) > > In both cases: >     at least one policy must be non void >     if both are non void they must be equal > > I'll clarify this. > Err, what is a void policy? >> >> "EP::underflow_error(const char * message)" >> Underflow is a floating point error that happens >> when the value is too close to 0.  (INT_MIN - 1) >> is an overflow error, not an underflow error. > > Right.  There is no underflow error thrown in the current code. I found one use (probably accidental) at checked.hpp:410. > > >> Also, safe is defined in safe_integer.hpp which is not #included. > > this is included by safe_range.hpp.  But I agree that if I use > safe<..> I should include safe_integer.hpp even though it's > redundent. safe_range.hpp only includes safe_base.hpp. The only reason I noticed this was that Intellisense highlighted safe as undefined. > >> >> promotion_policies/cpp.html >> >> Unless I'm misunderstanding something, the use >> of trap_exception will fail to compile at: >> d *= velocity; > > > > ....  I guess this illustrates the impossibility > for normal people to actually write demonstrably correct code. > Tell me about it: https://github.com/boostorg/random/blob/develop/include/boost/random/uniform_int_distribution.hpp#L93> > > Ahhh - finally I see your point.  assignment using d as > an accumuator loses the range calculated at compile time > so subsequent operations can't be guaranteed to not > overflow. > Yeah.  This makes it a bit inconvenient to use trap_exception with anything other than a strict functional style. In Christ, Steven Watanabe _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Open this post in threaded view
|

## Re: [safe_numerics] Review Part 1 (Documentation)

 On 3/2/17 4:49 PM, Steven Watanabe via Boost wrote: > AMDG >> ....  I guess this illustrates the impossibility >> for normal people to actually write demonstrably correct code. ... without the help of something like this. > Tell me about it: > https://github.com/boostorg/random/blob/develop/include/boost/random/uniform_int_distribution.hpp#L93I took a look at this, and it looks good to me. > >> Ahhh - finally I see your point.  assignment using d as >> an accumuator loses the range calculated at compile time >> so subsequent operations can't be guaranteed to not >> overflow. >> > > Yeah.  This makes it a bit inconvenient to use > trap_exception with anything other than a strict > functional style. Actually this turns out to be a very quite interesting point. I started an example of taking a small micro computer program for controlling a stepper motor and using the compile time trapping facility to tweak the program so that it would guaranteed to not produce an invalid result without invoking any runtime overhead. Things went pretty well until I had to actually update the to position. At this point I had to more than "tweak" the program or give up on my goal of avoiding runtime overhead to guarantee no incorrect behavior.  At that point I suspended work on the example because it failed to illustrate my hope that I could take a legacy program for an foreign processor and make minimal changes to guarantee correctness w/o runtime overhead.  But the experiment was very interesting and useful and I hope to get back to it when I understand the science of computer programming better. Robert Ramey > > In Christ, > Steven Watanabe > > > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost> _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Open this post in threaded view
|

## Re: [safe_numerics] Review Part 2 (Implementation)

Open this post in threaded view
|

## Re: [safe_numerics] Review Part 2 (Implementation)

Open this post in threaded view
|

## Re: [safe_numerics] Review Part 2 (Implementation)

 2017-03-07 18:32 GMT+01:00 Robert Ramey via Boost <[hidden email]>: 247: >>         using result_base_type = typename boost::mpl::if_c< >>             std::numeric_limits::is_signed >>             || std::numeric_limits::is_signed, >>             std::intmax_t, >>             std::uintmax_t >>         >::type; >> Why division doesn't use calculate_max_t like multiplication >> deserves some explanation.  Division can overflow >> too (numeric_limits::max() / 1). >> > > Hmmm - I'm sure it's because I've presumed that the result > can aways be contained in the same size type as the number > being divide.  That t / x <= t - and divide by zero is > checked separately. Am I wrong about this? > I am not sure if this is what Steve meant, but:   int x = INT_MIN;   int y = -1;   int a = x / y; // overflows! safe does a check for this condition, but I find it quite surprising that it throws a domain_error rather than overflow_error. How do you make a call whether it is an overflow or a domain error? For mathematical ints dividing -2147483648 by -1 is well defined. Regards, &rzej; _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Open this post in threaded view
|

## Re: [safe_numerics] Review Part 2 (Implementation)

Open this post in threaded view
|

## Re: [safe_numerics] Review Part 2 (Implementation)

 In reply to this post by Boost - Dev mailing list On 3/7/17 11:33 AM, Andrzej Krzemienski via Boost wrote: > safe does a check for this condition, but I find it quite surprising > that it throws a domain_error rather than overflow_error. How do you make a > call whether it is an overflow or a domain error? For mathematical ints > dividing -2147483648 by -1 is well defined. Truth is I didn't take a whole lot of care in deciding which one to use. In this case, I think your right that overflow would be a better choice. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Open this post in threaded view
|

## Re: [safe_numerics] Review Part 3 (Tests + Summary)

 In reply to this post by Boost - Dev mailing list AMDG I vote to *ACCEPT* safe_numerics into Boost. The following issues *must* be resolved before inclusion: - Incorrect results for division (see below) - Linker errors from multiple definition (see below) - Name conflict for interval - The whole mess with automatic.  (Probably either allow   it to see the range of safe_base somehow or remove it.) - Test cases must verify results, not just exception or not - The precise rules for determining whether an operator   throws must be specified.  (My preferred definition:   An operator throws iff. it is mathematically undefined   or the mathematical result cannot be represented in the   result type.) All comments are as of 3bcfabe1cafb8ef6edf08d3bd8730a1555b1c45d The tests for the most part seem to check only whether the operation succeeds or fails.  They don't check whether the result is actually correct or not. test_z.cpp appears to be entirely #if 0'd test0.cpp doesn't seem to do anything that  isn't handled by the main tests. test_divide.hpp:129:                 assert(result == unsafe_result); unsafe_result is uninitialized.  (Most other uses are commented out) test_values.hpp: This is missing 0 which is kind of an important case. I've attached my own test case for +-*/. There's some behavior that I consider a little odd which I noted on lines 64-72.  Also it shows some incorrect results for division with automatic and negative [signed] char. for example: generic_test.cpp(76): error: in "test_div": check base_value(f(t, u)) == expected has failed [1 != 0] Failure occurred in a following context:     -85 [safe_base] / 3464536379 [safe_base] -> [safe_base<__int64,-9223372036854775808,9223372036854775807,automatic>] I had to make a couple minor edits to get the library to compile with vc15 (just released).  Patch attached. When I include the entire library in two translation units and link them together I get errors: test1.obj : error LNK2005: "class std::basic_ostream > & __cdecl std::operator<<(class std::basic_ostream > &,struct boost::numeric::checked_result const &)" (??$?6C@std@@YAAAV?$basic_ostream@DU?$char_traits@D@std@@@0@AAV10@ABU?$checked_result@C@numeric@boost@@@Z) already defined in include_all.obj test1.obj : error LNK2005: "class std::basic_ostream > & __cdecl std::operator<<(class std::basic_ostream > &,struct boost::numeric::checked_result const &)" (??$?6E@std@@YAAAV?$basic_ostream@DU?$char_traits@D@std@@@0@AAV10@ABU?$checked_result@E@numeric@boost@@@Z) already defined in include_all.obj test1.obj : error LNK2005: "class std::basic_ostream > & __cdecl std::operator<<(class std::basic_ostream > &,struct boost::numeric::interval const &)" (??$?6E@std@@YAAAV?$basic_ostream@DU?$char_traits@D@std@@@0@AAV10@ABU?$interval@E@numeric@boost@@@Z) already defined in include_all.obj test1.obj : error LNK2005: "class std::basic_ostream > & __cdecl std::operator<<(class std::basic_ostream > &,struct boost::numeric::interval const &)" (??$?6C@std@@YAAAV?$basic_ostream@DU?$char_traits@D@std@@@0@AAV10@ABU?$interval@C@numeric@boost@@@Z) already defined in include_all.obj   I tried using boost::format(...) % safe() and it fails because your operator% matches.  I notice that you have checks for ostream and istream with the shift operators, but it would really be better to make it more generic by checking is_arithmetic (or perhaps std::numeric_limits::is_specialized) on all the operators. In Christ, Steven Watanabe _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost generic_test.cpp (8K) Download Attachment safe_numerics_vc15.patch (1K) Download Attachment
Open this post in threaded view
|

## Re: [safe_numerics] Formal review starts today

 In reply to this post by Boost - Dev mailing list > -----Original Message----- > From: Boost [mailto:[hidden email]] On Behalf Of Andrzej Krzemienski via Boost > Sent: 01 March 2017 23:37 > To: [hidden email]; [hidden email] > Cc: Andrzej Krzemienski > Subject: [boost] [safe_numerics] Formal review starts today > > Hi Everyone, > Today, on March 2nd (or tomorrow, depending on your timezone), is the start > of the formal review of safe_numerics library by Robert Ramey. The review > will run till March 11th. I will be serving as review manager. > > safe_numerics is a set of drop-in replacements for the built-in integer > types, which make the guarantee that the results of operations are either > correct according to the rules of integer arithmetic or report a > diagnosable error (rather than offering modulo arithmetic results, or > resulting in undefined behavior, or returning incorrect results as in the > case of signed vs. unsigned comparisons). > > The library can be found on GitHub: > https://github.com/robertramey/safe_numerics/> > Online docs: > http://htmlpreview.github.io/?https://github.com/robertramey/safe_numerics/> master/doc/html/index.html > > Formal Review comments can be posted publicly on the mailing list or Boost > Library Incubator , or sent privately to the review > manager, that is myself. > > Here are some questions you might want to answer in your review: > >    - What is your evaluation of the design? Complicated to use (compared to int), and very, very complicated to write. But that is a consequence of the daft design of the C language. The language also doesn't allow use of hardware to handle overflow (and underflow) and doesn't have arrays etc as first class citizens. I don't believe that it is really a idiot-proof drop-in replacement for the built-in integral types, but it will be fine to be used for new projects, especially as it needed the fancy features of C++14. I agree that explicit conversions are the Right Thing, but they do carry a cost to the users - the need to understand the issues and take care with construction and assignment because this is a User Defined Type (UDT) and the special-case privileges of built-in do not apply (another daft design decision).  Floating-point and fixed-point UDT have proved unintuitive to use because of explicit conversions; there are big elephant traps awaiting the unwary. Costly at compile time because of the number of libraries included, but that's a cost worth paying. I like that the infrastructure might be extended to other than integral types. >    - What is your evaluation of the implementation? Above my pay grade. >    - What is your evaluation of the documentation? Good exposition of the problems and solutions. Good examples. Links to source of examples code would be *very* useful.  Starting with an example is the most common way of 'getting started'. Will using "" file specification #include "../include/safe_range.hpp" instead of <> #include <../include/safe_range.hpp> cause trouble for users trying to use/modify the examples in Boost or their own folder position? The common need for overflow (or underflow) to become 'saturation' == max_value (or min_value) is not an option (but then it is arithmetically 'wrong', I suppose ;-)) >    - What is your evaluation of the potential usefulness of the library? Very valuable to make programs that 'always work' instead of 'mostly work'. Users might appreciate a list of compiler versions that really do work. Sadly 'Compliant C++14' is a bit fuzzy.  (Should become clearer if accepted and test matrix visible). A good effort at working round fundamental C language defects. >    - Did you try to use the library? With what compiler? Did you have any    problems? Had a very brief try with VS 2015 with /std:c++latest added to command line (to try to ensure C++14 compliance) but am stuck with 1>j:\cpp\safe_numeric\safe_numeric\include\interval.hpp(107): error C2737: 'boost::numeric::anonymous-namespace'::failed_result': 'constexpr' object must be initialized 1>j:\cpp\safe_numeric\safe_numeric\include\safe_base_operations.hpp(131): error C2244: 'boost::numeric::safe_base::operator =': unable to match function definition to an existing declaration But I am sure that this is entirely my fault, but I'm out of my time allotted to this review. Also - Is this warning(s) avoidable/relevant/quietable? j:\cpp\safe_numeric\safe_numeric\include\safe_base.hpp(233): warning C4814: 'boost::numeric::safe_base::operator =': in C++14 'constexpr' will not imply 'const'; consider explicitly specifying 'const' I feel that all warnings should be avoided or supressed using push'n'pop pragmas. >    - How much effort did you put into your evaluation? A glance?  A quick  reading. >    - Are you especially knowledgeable about the problem domain? No. > Do you think the library should be accepted as a Boost library? Yes. Paul PS I noted a few typos in documentation (though I doubt these have escaped Steven's fine-tooth-combing ;-). multiplication etc. . C/C++ often automatically  - extraneous . similar, We'll  - should be lower case w. the expression will yield the correct mathematical result - missing . trap at compiler time all operations which might fail at runtime.  - compile-time (Better to use compile-time and run-time throughout? Inventing new words is unnecessary and hyphenating is good for readbility) This solution is simple, Just replace instances    - lower case j parameters are guarenteed to meet requirements when - guaranteed our program compiles without error - even when using the trap_exception exception policy  - missing . We only needed to change two lines of code to achieve our goal missing . ( throw exception, compile time trap, etc..) no implementation should return an arithmetically incorrect result.  - extraneous space after ( and missing . and new sentence No implementation ... C++ operations permitted on it's base type - should be its  (possessive!) --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Open this post in threaded view
|

## Re: [safe_numerics] Formal review starts today

Open this post in threaded view
|

## Re: [safe_numerics] Formal review starts today

 > -----Original Message----- > From: Boost [mailto:[hidden email]] On Behalf Of Robert Ramey via Boost > Sent: 09 March 2017 18:32 > To: [hidden email] > Cc: Robert Ramey > Subject: Re: [boost] [safe_numerics] Formal review starts today > > On 3/9/17 7:23 AM, Paul A. Bristow via Boost wrote: > > >> Here are some questions you might want to answer in your review: > >>    - What is your evaluation of the design? > > Complicated to use (compared to int), > > Hmmm - a major design goal is that it be a no-brainer to use.  I'd like > to see you exand a little on this comment. One needs to fully understand static_cast - it's an unintuitive name for something that has unexpectedly complicated implications.     > > But that is a consequence of the daft design of the C language. > > tl;dr; > > I want to defend the C language design. My first exposure to C was in > 1980?  I was introduced to Ratfor which was a fortran implemented C like > language introduced in the Plauger book "Software Tools".  After that I > lusted after a C language tool.  The machine I had at my disposal was a > Data General Eclipse - a 16 bit architecture.  I got a hold source code > for a compiler for the Z80 and managed to port it to the DG machine. > Then I managed to compile the standard source which my compiler.  I was > hooked!  The C language then was the world's first "portable assembler". >   This was huge at the time.   I can't resist saying that my reaction to learning of C design philosophy was LOL :-( But programmers liked quick'n'dirty and being trusted  (the biggest mistake of all), a host of .edu starting teaching C, and like FORTRANs bottomless pit of working subroutines, it was unstoppable. And so here we are putting Band-Aids on the C++ and STL Band-Aids*. > I'm hoping to bridge two worlds here.  I'm not hopeful.  I'm a sucker for lost causes. I'm optimistic.  I'm not the only one getting cross with 'mostly work' programs, and as you observe, people will get *really cross* with 'mostly work' killer cars. Chris Kormanyos has publicised how to use recent C++ on bare-metal in his book Real-Time C++. > > Users might appreciate a list of compiler versions that really do work. They really *must* have such a list. > >>    - Did you try to use the library? With what compiler? Did you have any    problems? > > Had a very brief try with VS 2015  and failed. John Maddock has since explained why nothing I tried worked.  I'm a bit shocked that it hasn't been tested on MSVC.  My acceptance was on the assumption that it would work.  It really must be portable over recent GCC, Clang and MSVC at the very minimum. I suggest that we should pause the review until you adopt John's patches and reissue the review code and then restart the review. It'll be a bit poor to accept the library until a few people confirm it's working on MSVC. Keep going! Paul * Band-Aid Trademark of Johnson and Johnson ;-) --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Open this post in threaded view
|

## Re: [safe_numerics] Formal review starts today

 2017-03-11 15:27 GMT+01:00 Paul A. Bristow via Boost <[hidden email]> : > > -----Original Message----- > > From: Boost [mailto:[hidden email]] On Behalf Of Robert > Ramey via Boost > > Sent: 09 March 2017 18:32 > > To: [hidden email] > > Cc: Robert Ramey > > Subject: Re: [boost] [safe_numerics] Formal review starts today > > > > On 3/9/17 7:23 AM, Paul A. Bristow via Boost wrote: > > > > >> Here are some questions you might want to answer in your review: > > >>    - What is your evaluation of the design? > > > > Complicated to use (compared to int), > > > > Hmmm - a major design goal is that it be a no-brainer to use.  I'd like > > to see you exand a little on this comment. > > One needs to fully understand static_cast - it's an unintuitive name for > something that has unexpectedly complicated implications. > > > > But that is a consequence of the daft design of the C language. > > > > tl;dr; > > > > I want to defend the C language design. My first exposure to C was in > > 1980?  I was introduced to Ratfor which was a fortran implemented C like > > language introduced in the Plauger book "Software Tools".  After that I > > lusted after a C language tool.  The machine I had at my disposal was a > > Data General Eclipse - a 16 bit architecture.  I got a hold source code > > for a compiler for the Z80 and managed to port it to the DG machine. > > Then I managed to compile the standard source which my compiler.  I was > > hooked!  The C language then was the world's first "portable assembler". > >   This was huge at the time. > > I can't resist saying that my reaction to learning of C design philosophy > was LOL :-( > > But programmers liked quick'n'dirty and being trusted  (the biggest > mistake of all), > a host of .edu starting teaching C, and like FORTRANs bottomless pit of > working subroutines, > it was unstoppable. > > And so here we are putting Band-Aids on the C++ and STL Band-Aids*. > > > I'm hoping to bridge two worlds here.  I'm not hopeful.  I'm a sucker > for lost causes. > > I'm optimistic.  I'm not the only one getting cross with 'mostly work' > programs, > and as you observe, people will get *really cross* with 'mostly work' > killer cars. > Chris Kormanyos has publicised how to use recent C++ on bare-metal in his > book Real-Time C++. > > > > Users might appreciate a list of compiler versions that really do work. > > They really *must* have such a list. > > > >>    - Did you try to use the library? With what compiler? Did you have > any    problems? > > > > Had a very brief try with VS 2015  and failed. > > John Maddock has since explained why nothing I tried worked.  I'm a bit > shocked that it hasn't been tested on MSVC.  My acceptance > was on the assumption that it would work.  It really must be portable over > recent GCC, Clang and MSVC at the very minimum. > According to formal Boost criteria, it is sufficient for the library to work on two major compilers. These formal criteria are met by safe_numerics. Of couse, I acknoledge, that formal criteria are not the ony thing in the world. > > I suggest that we should pause the review until you adopt John's patches > and reissue the review code and then restart the review. > From the formal point of view, the two options for this I can see are:    - To conclude the review as rejected, and schedule a new one.    - Accept the library conditionally, and make the fix a hard condition/ It'll be a bit poor to accept the library until a few people confirm it's > working on MSVC. > Accepting the library does not mean it is immediately available in the next Boost release. If the library is accepted conditionally, you would be guaranteed that the users will get MSVC support (if adding this support is doable). Regards, &rzej; _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost