Subject: Re: [boost] [safe_numerics] Formal review starts today
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2017-03-11 14:41:27
2017-03-11 15:27 GMT+01:00 Paul A. Bristow via Boost <boost_at_[hidden]>
> > -----Original Message-----
> > From: Boost [mailto:boost-bounces_at_[hidden]] On Behalf Of Robert
> Ramey via Boost
> > Sent: 09 March 2017 18:32
> > To: boost_at_[hidden]
> > 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'
> 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