Force implicit call to nonstandard delete operator functions

Question

AFAIK in C++ (or at least in my compilers: gcc and clang) the following code is allowed:

struct BLA { void *operator new( std::size_t size, int i1, int i2 ); };

int main( void )
{
    struct BLA *bla = new (3,5) BLA;
    return 0;
}

IMAO this is quite cool since it allows a very clean syntax of allocating storage.
With this technique I can pass variables that attribute the way an object should be allocated in a very clean way and wouldn't have to abuse the constructor.
Unfortunately the C++ standard says (AFAIK) that the analogous way will not work for the 'delete' operator. i.e:

struct BLA
{
    void *operator new( std::size_t size, int i1, int i2 );
    void operator delete( void *p, int i1, int i2 );
};

int main( void )
{
    struct BLA *bla = new (3,5) BLA;
    delete (3,5) bla;
    return 0;
}

gives a hard error on the 'delete' line.
Is there a way (maybe a compiler switch) to allow this nonstandard implicit call to
BLA::operator delete( bla, 3, 5 )?

Using the above line would REALLY destroy the nice syntax :(

Answer 1

There is no way to pass arguments to the delete operator. Seen Bjarne's reasoning for this here. An overloaded delete such as the one you are implementing is only used when called explicetly or when the corresponding new throws.

If you need to make sure that the correct delete is called, there is a trick you can use though. If you only have two 32 bit ints that are passed to the constructor, just reserve 64 bit more than needed and put these two parameters in front of the object (you just need to return the offsetted position before returning the pointer). When you delete your object, do not pass any parameters, but instead fetch them from in front of the object and use them to deallocate correctly. This way you can use delete without parameters, and you can be sure that each object is deallocated correctly.

Not sure if the following would be considered a bug in your system:

struct BLA *bla = new (3,5) BLA;
delete (4,6) bla;

I.e. if it is possible to deallocate differently than allocating, this method will not work. If it is dangerous to deallocate differently, than this way with explicetly saving the parameters is actually much safer.