This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: operator new/delete forwarding


On Jul 20, 2006, at 3:57 PM, Martin Sebor wrote:

Howard Hinnant wrote:
[...]

I view this forwarding as a valuable convenience to the client, however I believe it is incomplete, and slightly wrong. I respectfully propose the following slight alteration:

This makes sense but I wonder why the standard doesn't specify the nothrow operators just the way you describe instead of going through the same steps as for the ordinary forms and using the "as if" phrase? It almost looks like the intent was for both operators to be implemented in terms of the same (unspecified) function but not by calling each other, i.e., like so (calling new_handler omitted):

    void* op_new (size_t n, bool nothrow) {
        void *p = malloc (n);
        if (0 == p && !nothrow)
            throw bad_alloc ();
        return p;
    }

    void* operator new (size_t n) {
        return op_new (n, false);
    }

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

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

If you stare at the wording in 18.4.1 long enough you can find both support and non-support for various implementations. The wording is a little sub-par. One amusing point is that 18.4.1.1p12 requires any overridden operator delete to accept pointers from the *default* operator new. :-O

So this request is not based on what the standard mandates (whatever that is). It's based on (my opinion of) quality / robustness from the client's viewpoint, and which I believe to be standard conforming.

E.g. what happens if the client overrides new/delete (non-nothrow versions only) and then calls client code that allocates using new (nothrow) but deallocates using delete (non-nothrow -- which is perfectly legal). Technically the client is at fault for not overriding all 8 operators. But it's stuff like that that gives C++ a bad name in the usability department.

-Howard


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]