Boost logo

Boost :

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


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