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 04:08:43

>
> The problem with this is that the usage of safe<int> changes the meaning
> of the program.
>
> int i; // i not initialized
> ....   // program has weird behavior
>

In this particular case, the fact that the program was relying on UB means
that the program had no meaning at all. So it adds a meaning maybe :)

However I see your point ; you expect people to do something like:

#ifdef DEBUG
typedef safe<int> my_int;
#else
typedef int my_int;
#endif

But, you could instead market the following usage:

#ifdef DEBUG
typedef safe<int, SomePoliciesWithRuntimeChecks> my_int;
#else
typedef safe<int, SomePoliciesWithOnlyCompileChecks> my_int;
#endif

IMHO, it makes no sense to design your library to allow users *not* using
it.
If it is possible to disable some or all the runtime checks, the users has
no excuse to just switch to builtin types. Moreover, the incentive to
switch *from* builtin types is higher, as users can choose to do it
gradually: First all our integers will be initialized and compile-time
checked,
then we can add runtime checks in debug mode, and finally, we can bench the
whole thing with the runtime checks in release builds.

My 2 cents,