Subject: Re: [boost] updated version of safe integer library
From: Robert Ramey (ramey_at_[hidden])
Date: 2016-02-04 11:45:56
On 2/4/16 1:08 AM, Raphaël Londeix wrote:
>> 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;
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.
What I actually expect is:
a) some wierd bug can't be found.
b) in desperation some intern just replaces all the ints with
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.
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>
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.
It's also possible I could use policies to optionally include
initialization checking - which I see as relatively expensive.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk