Re: [boost] updated version of safe integer library

Subject: Re: [boost] updated version of safe integer library
From: Robert Ramey (ramey_at_[hidden])
Date: 2016-02-03 19:41:40

On 2/3/16 4:00 PM, Raphaël Londeix wrote:
>>
>> Writing correct code is not considered a major problem by most
>> programmers and organizations which depend on code.  Code that works
>> most of the time is considered good enough.
>>
>
> Well, good enough is perfect in most projects. However, I do like simple
> drop-in wrappers that prevent stupid mistakes to ever compile, or that
> abort on overflows.
>
> About the construction topic, I think that a good compromise could be to
> choose a safe default (always initialize to 0) but to allow one to be
> explicitly unsafe:
>
> safe<int> i; // i == 0
> safe<int> j(boost::uninitialized); // undefined
>
> It happens that the developer knows that initialization will be done later,
> or has already been done (mapped memory for example).

The problem with this is that the usage of safe<int> changes the meaning 
of the program.

Example:

one has the following program

int i; // i not initialized
....   // program has weird behavior

in order to find the cause of the weird behavior someone makes the 
following change:

safe<int> i; // i now initialized to 0
...    // program has no weird behavior

This means that usage of safe<int> hides errors - which is even
worse than before.

I'm actually most inclined to require an initialization.  In this case 
the attempted fix would

safe<int> i; // compile time error
... // program doesn't compile

so in order to use safe integer one is forced to be explicit and use

safe<int> i = 0; // compile time error
... // program has no weird behavior

Then someone says - take out the safe stuff - it's slowing things down! 
(true or untrue doesn't matter).  So the fix would be:

int i = 0; // compile time error
... // program has no weird behavior

The only problem is that someone is going to say: "Wait - I don't need 
initialization! it's non-optimal".  He might be right" but I doubt it 
matters.  but safe integer isn't exactly equivalent to int any more it 
has different behavior - I hate it when this happens.  So the best
would be to include an initialization bit inside safe<int> uh-oh another 
howl.

Robert Ramey