Boost logo

Boost :

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;
typedef int my_int;

But, you could instead market the following usage:

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

IMHO, it makes no sense to design your library to allow users *not* using
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
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,

Boost list run by bdawes at, gregod at, cpdaniel at, john at