Precompiler question

[Martin Stich]

hi,
i would like to #define my own cp_new macro like this:
#define cp_new new(__FILE__,__LINE__)
for my custom new operator. this works fine so far.

however, i would additionally like to disallow the use of
the original new (i dont want to overload the global op. new
though). i thought of something like this:

#define new {DONT_USE_NEW_ANY_MORE}

so that it wont even compile. but then, the macro in the first
place wont compile either, of course. is there a way to
accomplish this ?

thanks
martin

[Pete Becker]

Martin Stich wrote:

i thought of something like this:

#define new {DONT_USE_NEW_ANY_MORE}

so that it wont even compile. but then, the macro in the first
place wont compile either, of course.
It should compile just fine.
is there a way to
accomplish this ?

Don't do it. Redefining keywords is a bad idea. For example, what will
you do with a third-party library whose headers use new?

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

[Chris Theis]

"Martin Stich" <ms****@primusnetz.de> wrote in message
news:bq*************@news.t-online.com...

hi,
i would like to #define my own cp_new macro like this:
#define cp_new new(__FILE__,__LINE__)
for my custom new operator. this works fine so far.

however, i would additionally like to disallow the use of
the original new (i dont want to overload the global op. new
though). i thought of something like this:

#define new {DONT_USE_NEW_ANY_MORE}
This should be okay, but why don't you call your macro new which will solve
the problems of other people's code using new instead of cp_new? I'd suggest
to use #define new new(__FILE__, __LINE__) and implement you specialized
behavior in an overloaded version of the global new operator. This word just
fine for me implementing a memory leak detection mechanism. However, one has
to say the redefinition of keywords is in general not a good idea because it
might introduce very unwanted and weird behavior which is hard to trace. If
I remember correctly there was an article by Herb Sutter about that in C++
Users Journal some time ago.

so that it wont even compile. but then, the macro in the first
place wont compile either, of course. is there a way to
accomplish this ?

thanks
martin

Regards
Chris

[Martin Stich]

This should be okay, but why don't you call your macro new which will solve the problems of other people's code using new instead of cp_new? I'd

suggest

because i'd also like to be able to circumvent the leak detection in very
special
cases, e.g. by something like raw_new which should do just what the original
new does. but this would then compile to new(__FILE__,__LINE__) which
is not what i want ;)
hm maybe i should write another version of new, which has an additional
parameter
for circumventing the leak detection...

thanks
martin

[Pete Becker]

Chris Theis wrote:

This should be okay, but why don't you call your macro new which will solve
the problems of other people's code using new instead of cp_new?

It breaks other people's code that uses placement new:

char data[28];
new(data)B;

Don't do it.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

[Paul Mensonides]

"Pete Becker" <pe********@acm.org> wrote in message
news:3F***************@acm.org...

Martin Stich wrote:

i thought of something like this:

#define new {DONT_USE_NEW_ANY_MORE}

so that it wont even compile. but then, the macro in the first
place wont compile either, of course.

It should compile just fine.

Out of curiosity, why are 'new' and 'delete' in the preprocessing-op-or-punc
production? This kind of implies that they cannot be identifiers even to the
preprocessor though the actual text of the standard makes no mention of that
being the case (though it does for the alternative tokens).

Regards,
Paul Mensonides

[Pete Becker]

Paul Mensonides wrote:

"Pete Becker" <pe********@acm.org> wrote in message
news:3F***************@acm.org...

Martin Stich wrote:

i thought of something like this:

#define new {DONT_USE_NEW_ANY_MORE}

so that it wont even compile. but then, the macro in the first
place wont compile either, of course.

It should compile just fine.

Out of curiosity, why are 'new' and 'delete' in the preprocessing-op-or-punc
production? This kind of implies that they cannot be identifiers even to the
preprocessor though the actual text of the standard makes no mention of that
being the case (though it does for the alternative tokens).

This is far outside my area of expertise, but it looks to me like 'new'
and 'delete' are valid identifiers in phase 4, which is when
preprocessor directives are processed. It's not until phase 7 that
they're treated as preprocessing-op-or-punc, and get converted to
tokens.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

[Chris Theis]

"Pete Becker" <pe********@acm.org> wrote in message
news:3F***************@acm.org...

Chris Theis wrote:

This should be okay, but why don't you call your macro new which will solve the problems of other people's code using new instead of cp_new?
It breaks other people's code that uses placement new:

char data[28];
new(data)B;

Which is of course true. Although for my special case (a quick leak
detection) it is okay. If you've got a more sophisticated approach I'd be
grateful if you could tell me about it 'cause I'm totally aware of the
aforementioned shortcoming.

Don't do it.

In general I totally agree with you.

Regards
Chris