Re: [PATCH] Add configure flag for operator new (std::nothrow)

[Marc Glisse <marc.glisse@inria.fr>]

On Tue, 3 Nov 2015, Mike Stump wrote:

> On Nov 3, 2015, at 1:10 PM, Martin Sebor <msebor@gmail.com> wrote:
>> The "as if" requirement implies that any observable effects of
>> "the (possibly replaced) ordinary version" must be preserved.
>> The repeated calls to the new handler are among such effects.
>
> Unless the standard is fixed to say that one cannot observe the repeated 
> calls.  We do this in some places, for some things:
[snip copy elision]
> in C++, so, it isnΒ’t out of the question.  I was looking for dynamic -> 
> static object optimization wording, but didnΒ’t find it in the first C++ 
> standard.  That is a fairly reasonable thing to do, and if done well, 
> can reasonably change the observable side-effects as well.

There is recent-ish wording in [expr.new] that says that 'new int' is not 
forced to call operator new. However, operator new (which can be called 
directly) has a rather strictly defined behavior. And a bad one at that, 
since it forces the use of an exception to report an error to the direct 
caller...


On Tue, 3 Nov 2015, Martin Sebor wrote:

> There are two sets of important observable effects: the calls to
> the handler, and the call to the (possibly replaced) ordinary
> operator new.

"This nothrow version of operator new returns a pointer obtained as if 
acquired from the (possibly replaced) ordinary version."

For a non-native speaker, it is extremely unclear if the (possibly 
replaced) ordinary version is the original one that has been displaced or 
if it is the user one that did the replacement.

> A C++ program is allowed to replace just the ordinary operator
> new (and not the nothrow version), call the default nothrow
> operator new, and expect to get back the same pointer that would
> have been returned from the replaced new had it been called instead.
> (Some implementations, including libstdc++, fail to conform to this
> requirement.)

That's also the interpretation I remember, and I find it contradictory 
with the C++ philosophy that exceptions are heavy, expensive, and should 
be avoided for local use. (of course allocation failure should be rare)

-- 
Marc Glisse