-1

I am using Visual C++ 2013.

I need to redefine my delete keyword (yet another memory management tool)

#define delete foo(SOME,PARA,METERS), delete

The purpose is to redirect delete to an overridden version of mine, but I have an issue when using the "= delete" keyword or using external code using it.

Class Something {
public:
    Something() {}
    Something(const Something &) = delete;
}

Note : VC13 gives the following errors :

error C2061: syntax error : identifier 'instance'
error C2238: unexpected token(s) preceding ';'

Question

Is there a way to redefine delete without affecting =delete ?

Notes (edition)

Redefining a keyword is indeed something to handle with care and could probably be avoided by another design in practically any case. I am already fully aware of that and I do not ask for a workaround. See this question more as a research than an actual production development.

This being said I just want to discuss here the issue that we have a keyword having two different meanings in two different situations.

So the question is simply about defining delete when used as a release operation and not as a "no implementation" mark.

Ben
  • 78
  • 7
  • 7
    `#define delete ...` sounds like a bad idea. – erip Jan 21 '16 at 16:04
  • 4
    Implement `operator delete` instead of using MACRO. – Jarod42 Jan 21 '16 at 16:05
  • Why don't you want to use `operator delete()` instead. That seem to be more expected... – Alexander Stepaniuk Jan 21 '16 at 16:06
  • 1
    No, there isn't. This looks like a definite [X-Y Problem](http://meta.stackexchange.com/questions/66377/what-is-the-xy-problem). – molbdnilo Jan 21 '16 at 16:06
  • You will also need to watch out for this: http://stackoverflow.com/a/2726221/4342498 – NathanOliver Jan 21 '16 at 16:07
  • I do override delete, but I do need to redirect the standard delete to alternate overrides with different parameters, eventually context conditioned. I could also just create a mydelete operator and use it along my code. I could also use lots of workarounds, but I am mostly interested in knowing if there is anyway to define delete and not affecting =delete. – Ben Jan 21 '16 at 16:14
  • Never in your life you should even consider `#defin`ing a keyword. There is only one possible exception - when dealing with moronic libraries, I have seen a case or two when one had to redefine `private` to `public`. Wasn't something to be proud of, but a neccessary evil. But `#defin`ing `delete` or `new` is clearly insance. – SergeyA Jan 21 '16 at 16:19
  • By the way, not only you are breaking `= delete`. You will also break `operator delete`, and `delete[]`. – SergeyA Jan 21 '16 at 16:20
  • @SergeyA it looks like he want to replace operators with it. Problem, that he breaks ALL code which have written delete anywhere. Like standard library, which probably would not expect it. – Revolver_Ocelot Jan 21 '16 at 16:22
  • @Revolver_Ocelot, true - I am just showing Ben that the thing he asks about is not the only thing which will stop working. – SergeyA Jan 21 '16 at 16:24
  • If not used everyday and possibly threatening, redefining new and/or delete is not uncommon. For instance `#define new new(__FILE__,__LINE__)` is very commonly seen. Defining delete (moreover to remap it to a custom override) do not break if all cases are addressed. Here I can address mostly any. I still break the =delete function keyword. But please, I understand that this is an uncommon case and that there are a lot of possible workarounds. But the question regards mostly the =delete functions and how to have them not affected by a redefinition of delete, even if it is a bad idea – Ben Jan 21 '16 at 16:33
  • `delete` is a keyword in C++. If you use a macro to change the meaning of a keyword you're deep in undefined-behavior land. – Pete Becker Jan 21 '16 at 23:22

2 Answers2

7

I need to redefine my delete keyword

No, you don't.

The purpose is to redirect delete to an overridden version of mine,

You are allowed to provide your own definition of operator delete. This does not require redefining the keyword. As an added benefit, providing your own definition of operator delete also affects all library code which uses the delete keyword, even library code that has been compiled without including any of your headers, which seems like something you'd want.

Recommended further reading about that, including a simple example: operator delete, operator delete[]

  • I would rather end after the first sentence :). (No you don't). – SergeyA Jan 21 '16 at 16:16
  • Thanks for the reply. Obviously the design I chose that led me to this issue could be worked around (in my case with a lot of pain, but this is not the point). But since one can define delete, one might it a case when it could be of any use. Here this is the case and I found nothing for the moment discussing the conflict between defining delete and the =delete functions in C++11 – Ben Jan 21 '16 at 16:20
  • @Ben, see my comment under your question: `= delete` is not the only thing which breaks. – SergeyA Jan 21 '16 at 16:21
  • `s/this issue could be worked around/this issue must be fixed/` – Sebastian Mach Jan 21 '16 at 16:21
  • @SergeyA In fact you can avoid these issues. For instance when redefining delete and having overridden operator delete[] before you can make a delete[] work with a `#define delete foo(), delete` for instance – Ben Jan 21 '16 at 16:36
3

See cppreference for replaceable deallocation functions. You can override the global delete operators.

Yam Marcovic
  • 7,953
  • 1
  • 28
  • 38