Boost logo

Boost :

Subject: Re: [boost] a safe integer library
From: Brook Milligan (brook_at_[hidden])
Date: 2016-01-13 09:58:31


> On Jan 12, 2016, at 10:36 PM, Robert Ramey <ramey_at_[hidden]> wrote:
>
> Within the design intention of the library of the library one would simply
>
>
> safe_... x;
> int y
>
> try{
> y = x; // or x = y;
> }
> catch(cont std::exception e &){
> // cast failed
> …
> }

Fair enough. However, my understanding of best practice is that using exceptions for non exceptional behavior, e.g., branching on a condition, is an indication of incomplete design and runs counter to the goal of making code clear and expressive, something this library strives to do and otherwise achieves very well in my opinion.

Is there some reason that this use case--inquiring about the potential safety of a value—should not be an inherent element of the design? Is it not a valid use case to have a value in a wide type for which one needs to know whether it can be converted to a particular safe type? Is this not required for some aspects of interoperability with “non-safe” types?

I am left wondering why something as basic as this is so controversial, especially given that there seem to be no runtime costs in exactly the same set of cases for which the above code has no runtime costs. Why sacrifice code clarity by not supporting this?

Cheers,
Brook


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk