Re: [boost] updated version of safe integer library

Subject: Re: [boost] updated version of safe integer library
From: Raphaël Londeix (raphael.londeix_at_[hidden])
Date: 2016-02-04 14:30:35

>
> Note that the safe<T> is really safe<T, exception_policy = default_ep,
> promotion_policy = default_pp>.  there are several policies of each kind
> to choose from.  One of the exception policies is ignore - but I don't
> think it currently actually works.
>

Yes, I know. The second part of my response was more about the fact that
you actually have some policies, rather than their exact names. My point
was that one of them (or a combination of them) do not incurs any overhead.

> What I actually expect is:
>
> a) some wierd bug can't be found.
> b) in desperation some intern just replaces all the ints with
> safe<T>
> c) problem is discovered - the safe... stuff is backed out and everyone
> (who is old enough) has a beer to congratulate themselves on how smart
> they are and the product is shipped.
> d) In some cases, someone might unintentionally leave the safe stuff in
> - since shipping is already way overdue.
>

I can't help it but I find your view very depressing ! Why not allow one to
remove all the runtime checks ? This would let people use your code with
the guarantee that it is always possible to remove the overhead, if needs
be. Designing a library as a tool that you remove to ship your real product
does not really help. I shamelessly quote myself:
>>  IMHO, it makes no sense to design your library to allow users *not*
using it.

> e) Or maybe some crusty old geezer who is tired of fixing this stuff
> after doing 50 times will game the system by doing:
>
> i) change all the int... to my_safe<int>
> ii) insert
>
> template<typename T>
> using my_safe<T> = safe<T>;
>
> then in one place in the program he can switch settings for all his
> integer types - without using macros.
>

That's exactly what I did, one typedef to rule them all. The ifdef DEBUG
was only there to demonstrate a possible usage where checks are only
enabled in debug builds.

> It's also possible I could use policies to optionally include
> initialization checking - which I see as relatively expensive.
>

If you're saying that you might check if a value as been initialized before
being used in a policy, then I would argue against it, and that was my
whole point.
I think that a safe builtin emulator should always be initialized, or
*explicitly* left uninitialized[1]. That should have been the correct
default for C++. I'm not sure how you will receive this, but as far as I
remember, in D, all numeric types are initialized to 0 (or the value given
to the constructor), but you can always remove that runtime cost by being
explicit about it.
If I remember correctly, the syntax is something like this:

    int i = void;

But, with your library, it could be:

    boost::safe<int> i = boost::uninitialized; // or boost::none, or
boost::whatever

Which should raise an eyebrow in a code review, and has the advantage of
being damn clear.

Cheers,

[1] This is the only point I am trying to make