Are macro names subject to the double/leading underscore restrictions?

[Pete C]

I was looking at Section 17.4.3.1 and I can't work out whether macro
names are also covered by Section 17.4.3.1.2 ("Global names").

I often see preple chastised for using include guards like
_INCLUDED_BLAH_ H (and I avoid them myself "just to be on the safe
side"). But if this is a mistake, then it is an astonishingly common
one. There are dozens of well-known libraries in my /usr/include that
do it.

Is this technically a mistake that doesn't matter in practice, or does
Section 17.4.3.1.2 refer only to post-processed names?

Thanks,
Pete

[red floyd]

Pete C wrote:

I was looking at Section 17.4.3.1 and I can't work out whether macro
names are also covered by Section 17.4.3.1.2 ("Global names").

I often see preple chastised for using include guards like
_INCLUDED_BLAH_ H (and I avoid them myself "just to be on the safe
side"). But if this is a mistake, then it is an astonishingly common
one. There are dozens of well-known libraries in my /usr/include that
do it.

Is this technically a mistake that doesn't matter in practice, or does
Section 17.4.3.1.2 refer only to post-processed names?

Thanks,
Pete

*ANY* identifier with a leading underscore followed by an uppercase, or
two consecutive underscores is subject to 17.4.3.1.2. Period.

[red floyd]

Pete C wrote:

I was looking at Section 17.4.3.1 and I can't work out whether macro
names are also covered by Section 17.4.3.1.2 ("Global names").

I often see preple chastised for using include guards like
_INCLUDED_BLAH_ H (and I avoid them myself "just to be on the safe
side"). But if this is a mistake, then it is an astonishingly common
one. There are dozens of well-known libraries in my /usr/include that
do it.

/usr/include *is* your implementation. Since the identifiers in
question are reserved to the implementation, /usr/include is quite free
to use them.

[Pete C]

red floyd wrote:

/usr/include *is* your implementation. Since the identifiers in
question are reserved to the implementation, /usr/include is quite free
to use them.

Hmm... I'm pretty sure that when the standard says "the
implementation" , it isn't referring to wxWidgets, boost, gtkmm or any
other crufty old library I happen to have installed in /usr/include ...
surely it is just referring to the implementation of ISO/IEC 14882 ?

[Pete Becker]

Pete C wrote:

red floyd wrote:

>/usr/include *is* your implementation. Since the identifiers in
question are reserved to the implementation, /usr/include is quite free
to use them.

Hmm... I'm pretty sure that when the standard says "the
implementation" , it isn't referring to wxWidgets, boost, gtkmm or any
other crufty old library I happen to have installed in /usr/include ...
surely it is just referring to the implementation of ISO/IEC 14882 ?

That's right. Being in /usr/include is not a license to use reserved
names. That's reserved to the compiler and its associated headers.

--

-- Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com)
Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." (www.petebecker.com/tr1book)

[=?ISO-8859-15?Q?Juli=E1n?= Albo]

Pete C wrote:

I often see preple chastised for using include guards like
_INCLUDED_BLAH_ H (and I avoid them myself "just to be on the safe
side"). But if this is a mistake, then it is an astonishingly common
one. There are dozens of well-known libraries in my /usr/include that
do it.

There are thousands of people, books, magazine articles, help files, web
pages and usenet posts that uses void main, and is still incorrect
according to the standard.

There are millions of programs with bugs, but that fact will not must
encourage anything to write buggy code on purpose.

--
Salu2