What is the point supporting class-specific new/delete? (and a fantasy)

66 views
Skip to first unread message

lie4pan1

unread,
Apr 29, 2015, 10:42:28 AM4/29/15
to std-dis...@isocpp.org
To 'fully' support such 'weird' features, the standard has to mandate some compiler magic for polymorphic deletions:

struct B
{
   
virtual ~B();
};

struct D : B
{
    virtual ~D();
   
static void operator delete(void *);
};

B *b = new D;
delete b; // not only D::~D, but also D::operator delete will be called

// Sweet??

However, class-specific new/delete are problematic. They unecessarily hide global new/delete by names. They don't play well with other memory allocation/deallocation facilities (which can usually do better), and even std::allocator neglects them. Their other usages like debugging can also be fullfilled with thin wrappers or even old preprocessor macros (though problematic on their own).

And more importantly IMO, they are unfortunately occupying the syntax room for things that should have been made possible:

WARNING: NOT REAL C++, MAYBE D(reamed)-- OR SOMETHING ELSE

::new C;                                // good-old-classic global new as ever
std::gc.new C;                           // many people's dream
auto p = new(std::gc) C;                 // by ADL, delegating to std::gc.new or even as Unified Call Syntax
delete(p, std::gc) ~C;                   // [*Note]same rule as above, std::gc::operator delete might be a nop though
std::aligned<8>::new C;                  // there may be superior solutions, but this is OK for simple demonstration
std::shared_ptr<C> sp(new C);            // classic way
sp.new(std::gc) C;                       // maybe with some magic to register the correct deleter to call in dtor?
std::shared_ptr<C> sq(new C, myAlloc);   // this one will always (try to) figure out the correct deleter
std::shared_ptr<C, MyAllocator>{}.new C; // same as above
std::vector<C> v(10, std::gc);           // what container allocators should have been

// [*Note]: the slightly verbose delete syntax here is to make 'placement delete' viable while avoiding ambiguous statement like
// delete (f)(p);
// in REAL C++, but that's another story.
// Further info on the ambiguity issue with 'placement delete' in C++: http://www.programd.com/97_a7e1e54a596d4c97_1.htm


No, I am really not proposing deprecating/removing class-specific new/delete here. I just want to ask a question:

Is there a good reason to (continue to) support them, other than maintaining backward-compatiblility?

Reply all
Reply to author
Forward
0 new messages