This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: [PATCH] Add configure flag for operator new (std::nothrow)
- From: Mike Stump <mikestump at comcast dot net>
- To: Martin Sebor <msebor at gmail dot com>
- Cc: Daniel Gutson <daniel dot gutson at tallertechnologies dot com>, Aurelio Remonda <aurelio dot remonda at tallertechnologies dot com>, libstdc++ at gcc dot gnu dot org, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, daniel dot gutston at tallertechnologies dot com, Jonathan Wakely <jwakely dot gcc at gmail dot com>
- Date: Tue, 3 Nov 2015 15:08:49 -0800
- Subject: Re: [PATCH] Add configure flag for operator new (std::nothrow)
- Authentication-results: sourceware.org; auth=none
- References: <1446554133-3090-1-git-send-email-aurelio dot remonda at tallertechnologies dot com> <56391843 dot 1070807 at gmail dot com> <CAF5HaEVeD4G1Mj8GwbpLyZ8V+GWNRAy1=5qbfVHgrZ=GpkbHbg at mail dot gmail dot com> <563922C6 dot 7080706 at gmail dot com>
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:
15Whenever a temporary class object is copied using a copy constructor,
and this object and the copy have the same cv-unqualified type, an
implementation is permitted to treat the original and the copy as two
different ways of referring to the same object and not perform a copy
at all, even if the class copy constructor or destructor have side
effects. For a function with a class return type, if the expression
in the return statement is the name of a local object, and the cv-
unqualified type of the local object is the same as the function
return type, an implementation is permitted to omit creating the tem-
porary object to hold the function return value, even if the class
copy constructor or destructor has side effects. In these cases, the
object is destroyed at the later of times when the original and the
copy would have been destroyed without the optimization.111)
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.