Re: [boost] Looking for help on preparing for review

Subject: Re: [boost] Looking for help on preparing for review
From: Paul A. Bristow (pbristow_at_[hidden])
Date: 2018-06-23 10:43:36

> -----Original Message-----
> From: Boost [mailto:boost-bounces_at_[hidden]] On Behalf Of Damian Vicino via Boost
> Sent: 18 June 2018 04:54
> To: boost_at_[hidden]
> Cc: Damian Vicino
> Subject: [boost] Looking for help on preparing for review
> 
> Hi,
> I'm preparing my library safe_float to be proposed for review.
> 
> The library was born in the GSOC2015, but it never reached a review ready
> state. My plan is to change that in the next few months.
> 
> At this point, I'm looking for some volunteers to proof-read the
> documentation. Code is going through major rewrite, and I will send another
> mail looking for help with reviewing the code when that is done.
> 
> The most current documentation can be read directly from the web here:
> https://sdavtaker.github.io/safefloat/
> 
> Any comment is appreciated.

I haven't had time to try safe_float 'in anger', but it looks potentially useful.

I'll be pleased to help with proof-reading when you have done an update.  I know from bitter experience how impossible it is to
proof-read what you have written.  Ping me off-list.

Some initial comments on docs appearance (generally very nice)

* An index might be useful.  I can advise how to produce this automatically.  

* I find using a different font for all 'code' items helps reading quite a lot.  You can spend many happy hours enclosed all
safe_float to `safe_float` ...  ;-)

* links to the source example would be helpful.  (And of course using code snippets ensures that WYSIWC 'what you see is what
compiles').  

It would be really nice if this played nicely with User-defined types like Boost.Multiprecision as well as the built-ins.  I can't
see any blindingly obvious reason why it would not work.  Might get complex 'under-the-hood'?

Some examples of how this plays with Boost.Math would also be useful as many users will naturally use these two together.
Boost.Math already does some checking against getting 'incorrect' results of course, and has its own policy system, powerful if
confusing. 

It is not clear to me if the 'no exceptions' camp can use this usefully in non-debug mode - the time when it will be most useful -
users come up with input values that testers never dream of.

You need to define 'incorrect' a bit more clearly? and I'd use the word 'silently' in describing on how C++ handles overflow etc by
default.

Looking good.

Paul

---
Paul A. Bristow
Prizet Farmhouse
Kendal UK LA8 8AB
[phone]