«

#define new DEBUG_NEW


I can't imagine that has defined behavior.

"Noah Roberts" <> wrote in
news: ups.com:

> #define new DEBUG_NEW
>
>
> I can't imagine that has defined behavior.
>
>


Why not? That's just a preprocessor directive that wherever it sees "new",
replace with "DEBUG_NEW". Whether that has a good or bad effect on the
rest of your code depends on the rest of your code. But that line in
isolation has perfectly defined behaviour.

Andre Kostur wrote:

> "Noah Roberts" <> wrote in
> news: ups.com:
>
>> #define new DEBUG_NEW
>>
>>
>> I can't imagine that has defined behavior.
>>
>>
>
>
> Why not? That's just a preprocessor directive that wherever it sees
> "new",
> replace with "DEBUG_NEW". Whether that has a good or bad effect on the
> rest of your code depends on the rest of your code. But that line in
> isolation has perfectly defined behaviour.

As soon as you find that line not in isolation but within a translation unit
(i.e., as soon as you try to actually compile that line), clause
[17.4.3.1.1/2] kicks in:

A translation unit that includes a header shall not contain any macros
that define names declared or defined in that header. Nor shall such a
translation unit define macros for names lexically identical to keywords.


Best

Kai-Uwe Bux

Kai-Uwe Bux wrote:

> As soon as you find that line not in isolation but within a translation unit
> (i.e., as soon as you try to actually compile that line), clause
> [17.4.3.1.1/2] kicks in:
>
> A translation unit that includes a header shall not contain any macros
> that define names declared or defined in that header. Nor shall such a
> translation unit define macros for names lexically identical to keywords.

Yeah, I didn't think it was legal.

Kai-Uwe Bux <> wrote in
news:eoonb9$olk$:

> Andre Kostur wrote:
>
>> "Noah Roberts" <> wrote in
>> news: ups.com:
>>
>>> #define new DEBUG_NEW
>>>
>>>
>>> I can't imagine that has defined behavior.
>>>
>>>
>>
>>
>> Why not? That's just a preprocessor directive that wherever it sees
>> "new",
>> replace with "DEBUG_NEW". Whether that has a good or bad effect on
>> the rest of your code depends on the rest of your code. But that
>> line in isolation has perfectly defined behaviour.
>
> As soon as you find that line not in isolation but within a
> translation unit (i.e., as soon as you try to actually compile that
> line), clause [17.4.3.1.1/2] kicks in:
>
> A translation unit that includes a header shall not contain any
> macros that define names declared or defined in that header. Nor
> shall such a translation unit define macros for names lexically
> identical to keywords.

Huh... didn't know that it was explicitly disallowed. I would have figured
it would have been under the heading of "really bad idea to do", like
"#define if while"......

Oh wait... That's under the section of "Library introduction". Aren't
those restrictions only on headers that are supplied by the C++ Standard
Library, and is not imposing additional requirements on user-supplied
headers? I interpret that to read that Standard Library headers will not
pull stunts like the aforementioned "#define if while" (or to word another
way, you can count on the standard library not messing with reserved
keywords).

Andre Kostur wrote:

> Kai-Uwe Bux <> wrote in
> news:eoonb9$olk$:
>
>> Andre Kostur wrote:
>>
>>> "Noah Roberts" <> wrote in
>>> news: ups.com:
>>>
>>>> #define new DEBUG_NEW
>>>>
>>>>
>>>> I can't imagine that has defined behavior.
>>>>
>>>>
>>>
>>>
>>> Why not? That's just a preprocessor directive that wherever it sees
>>> "new",
>>> replace with "DEBUG_NEW". Whether that has a good or bad effect on
>>> the rest of your code depends on the rest of your code. But that
>>> line in isolation has perfectly defined behaviour.
>>
>> As soon as you find that line not in isolation but within a
>> translation unit (i.e., as soon as you try to actually compile that
>> line), clause [17.4.3.1.1/2] kicks in:
>>
>> A translation unit that includes a header shall not contain any
>> macros that define names declared or defined in that header. Nor
>> shall such a translation unit define macros for names lexically
>> identical to keywords.
>
> Huh... didn't know that it was explicitly disallowed. I would have
> figured it would have been under the heading of "really bad idea to do",
> like "#define if while"......
>
> Oh wait... That's under the section of "Library introduction". Aren't
> those restrictions only on headers that are supplied by the C++ Standard
> Library, and is not imposing additional requirements on user-supplied
> headers?

No, the restrictions mentioned in this section are all about what client
code may or may not do. The point of these provisions is to make sure that
the standard library can rely on the meanings of all keywords and reserved
identifiers. From the standard [17.4.3] "Constraints on programs":

This subclause describes restrictions on C++ programs that use the
facilities of the C + + Standard Library.

As you see: restrictions on programs that _use_ the library not restrictions
on the implementation of the library.

They only thing funny is that you seem to be allowed to redefine new
provided you do not include any standard headers whatsoever.

> I interpret that to read that Standard Library headers will not
> pull stunts like the aforementioned "#define if while" (or to word another
> way, you can count on the standard library not messing with reserved
> keywords).

It's the other way around.


Best

Kai-Uwe Bux