Re: operator new/delete forwarding

[Martin Sebor <sebor at roguewave dot com>]

Howard Hinnant wrote:
> On Jul 20, 2006, at 9:07 PM, Martin Sebor wrote:
>
> > > I think the standard allows either implementation.  Imho the one  I  
> > > outlined is higher quality.  I brought this issue up a long  time 
> > > ago  with the LWG:
> > > http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#206
> >
> >
> > Hmm, but the Rationale for closing this issue as NAD was that [the
> > possibility that the operators would become unlinked] was by design.
> > Doesn't that mean that it's a deliberate feature for users to be
> > able to replace one without causing the other to be replaced as
> > well?
>
>
> I would call it a deliberate implementation degree of freedom, rather  
> than a behavior that the client can rely on.  The standard text  doesn't 
> mandate forwarding, nor forbid it.

But why would implementations be given this latitude when there's
virtually no difference (from an implementer's standpoint) between
one and the other, and when the only likely effect is the lack of
portability (albeit in corner cases)? It seems to me that if that
were the case everyone would lose. Implementers would be left
wondering which of two apparently equivalent techniques to go with,
and users (of the standard) couldn't rely on one type of behavior
or the other and would have to be prepared to handle both.

> Thus the client can not  count on it 
> existing or not existing, despite the fact that it is  very visible.  So 
> as implementors, our job becomes to decide which  technique is most 
> valuable to the customer and go with that.  If at  some future date all 
> vendors come to the same conclusion, the  committee might standardize 
> existing practice (if prodded into it).

My preferred course of action would be to reopen your issue and
get a confirmation/consensus on what the intent is before changing
gcc. None of the compilers I tried (gcc, HP aCC, IBM XLC++, and Sun
C++) implements your proposed behavior, as reasonable as it sounds,
so changing gcc would introduce an incompatibility not only with
older versions of itself but also with most other compilers as
well.

Martin

PS I just tried MSVC 8. It behaves the way you propose. It would
be interesting to find out if that's by design. The test program
I used is attached.

#include <new>
#include <stdlib.h>
#include <stdio.h>

void* op_new (size_t n, bool nothrow)
{
    printf ("  operator new (%u%s)\n", n, nothrow ? ", nothrow" : "");

    void* const p = malloc (n);

    if (p || nothrow)
        return p;

    throw std::bad_alloc ();
}

#if REPLACE_NOTHROW_FORM

void* operator new (size_t n, const std::nothrow_t&) throw ()
{
    return op_new (n, true);
}

#else

void* operator new (size_t n) throw (std::bad_alloc)
{
    return op_new (n, false);
}

#endif

int main ()
{
    printf ("calling operator new (1):\n");
    operator new (1);

    printf ("calling operator new (1, nothrow):\n");
    operator new (1, std::nothrow);
}