underscore-prepended variable names

57 views
Skip to first unread message

hektor...@my-deja.com

unread,
Oct 30, 1999, 3:00:00 AM10/30/99
to
Both Lippman+Lajoie ("C++ Primer") and Gamma et al ("Design Patterns:
Elements of OO Software") use underscore-prepended member variables
names, such as "_variableName".

I know that the Standard forbids users from starting identifiers with a
double-underscore, or with an underscore followed by a capital letter.
In addition, underscores followed by anything are reserved for the
implementation in the global namespace.

So, it would appear, that the practice of the two paragons above would
be correct, since the underscore is always followed by a lower-case
letter, and the identifier concerned is always in class scope.

My question is -- is it? Is it safe to use this convention? If so,
why does Stroustrop categorically advise against starting ANY
identifier with an underscore in "The C++ Programming Language"?

Sent via Deja.com http://www.deja.com/
Before you buy.

[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
[ about comp.lang.c++.moderated. First time posters: do this! ]

[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std...@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]

Valentin Bonnard

unread,
Oct 30, 1999, 3:00:00 AM10/30/99
to
hektor...@my-deja.com wrote:

> Both Lippman+Lajoie ("C++ Primer") and Gamma et al ("Design Patterns:
> Elements of OO Software") use underscore-prepended member variables
> names, such as "_variableName".

> My question is -- is it? Is it safe to use this convention?

In theory it is.

> If so,
> why does Stroustrup categorically advise against starting ANY


> identifier with an underscore in "The C++ Programming Language"?

Because many implementation have used such identifiers
for their own purposes.

Perhaps also because one day or another someone will use
a capital letter after the initial underscore.

--

Valentin Bonnard
---

David R Tribble

unread,
Nov 2, 1999, 3:00:00 AM11/2/99
to
hektor...@my-deja.com wrote:
>
> Both Lippman+Lajoie ("C++ Primer") and Gamma et al ("Design Patterns:
> Elements of OO Software") use underscore-prepended member variables
> names, such as "_variableName".
>
> I know that the Standard forbids users from starting identifiers with
> a double-underscore, or with an underscore followed by a capital
> letter. In addition, underscores followed by anything are reserved
> for the implementation in the global namespace.
>
> So, it would appear, that the practice of the two paragons above would
> be correct, since the underscore is always followed by a lower-case
> letter, and the identifier concerned is always in class scope.
>
> My question is -- is it? Is it safe to use this convention? If so,
> why does Stroustrop categorically advise against starting ANY

> identifier with an underscore in "The C++ Programming Language"?

It's not a good idea, in spite of the preponderance of examples that
do it. The standard reserves names beginning with an underscore
for various (but not all) scopes, and reserves all names containing
two or more consecutive underscores anywhere.

Many library writers use leading underscores on the basis that they,
as library writers, consider themeselves part of "the implementation",
and such names are reserved for "the implementation". Which is fine
if you really are writing part of the standard library. It's not
so fine if you're simply providing your own (non-standard) library.

Many programmers take the safer approach of using a unique prefix
or suffix on their names rather than simply "_". For example,
company XYZ could prefix all of their externally visible names
with 'xyz_', 'Xyz', or 'XYZ'. Such names run a much lower risk of
colliding with user and other third-party names than names beginning
with just '_'.

Namespaces alleviate a lot of these problems, but don't entirely
eliminate them; you still have to deal with preprocessor names (which
have no scope limitations) and coming up with a fairly unique
namespace to begin with.

Then there's the problem of differentiating between things like
member functions and member variables. Some programmers provide
access functions like size() which access private members variables
such as _size. I prefer to use an 'm_' prefix for member variables,
and 's_' for static member variables; it has the benefit of making
it somewhat clearer where the name comes from when seen in the code
of my member functions.

Then there's the problem of how to name function parameters and
local variables within functions.

In summary, while there's no single, easy solution, the best advice
is to try to avoid collisions among externally visible names with
user and other third-party names. ("Externally visible" means
namespaces, typedefs, struct/class/union tags, enumeration constants,
global functions, global variables, global constants, and preprocessor
macros.) Using a single underscore is generally not enough.

-- David R. Tribble, da...@tribble.com, http://www.david.tribble.com --

Hendrik Schober

unread,
Nov 3, 1999, 3:00:00 AM11/3/99
to

[note to mods: I noticed that posting to two moderated newgroups
at once is not appreciated. this is a follow-up, however. Am I
supposed to post to the groups seperately?]

{ NO. It is best to post to the one group which fits the subject
best. If it fits both groups, crosspost, do not multipost.
-mod/jep clc++m }

David R Tribble <da...@tribble.com> wrote:
> hektor...@my-deja.com wrote:
> > [...]


> > I know that the Standard forbids users from starting identifiers with
> > a double-underscore, or with an underscore followed by a capital
> > letter. In addition, underscores followed by anything are reserved
> > for the implementation in the global namespace.
> >
> > So, it would appear, that the practice of the two paragons above would
> > be correct, since the underscore is always followed by a lower-case
> > letter, and the identifier concerned is always in class scope.
> >
> > My question is -- is it? Is it safe to use this convention? If so,
> > why does Stroustrop categorically advise against starting ANY
> > identifier with an underscore in "The C++ Programming Language"?

I used to use underscored names for protected and private class members
and types. to tell their inaccessability. Protected members and types
had one underscore, private members two of them. Types started with an
uppercase letter, others with a lowercase letter. I used underscored
identifiers within unnamed namespaces, too, to emphazise their restricted
scope and accessability.
Because people (especially in clcm ;-), try deja) mocked about it
quite often, I recently dropped this. Now I'm looking for new conventions
which have the expresional power of the (combined) old once.
I am, however, not really convinced, that there could be any problems
other than the history of a compiler, which will give you problems
anyway. Just out of curiosity I gave a member '_vptr' and one or two
other "special" names a try once -- no problem on the compilers I had
access to. On the other hand side I've had many problems with names
where there shouldn't be any problems at all (like having a function
parameter of a certain type named 'size' would sometimes give really
weird errors on parsing a function declaration; simply by renaming
it to 'sz', 'foo', or 'fifi' we got rid of the error).

> It's not a good idea, in spite of the preponderance of examples that
> do it. The standard reserves names beginning with an underscore
> for various (but not all) scopes, and reserves all names containing
> two or more consecutive underscores anywhere.

Applied to my convention, this shouldn't make any problems. My names
had always been in a scope of my own (either class or namespace).

> [...]


> Many programmers take the safer approach of using a unique prefix
> or suffix on their names rather than simply "_". For example,
> company XYZ could prefix all of their externally visible names
> with 'xyz_', 'Xyz', or 'XYZ'. Such names run a much lower risk of
> colliding with user and other third-party names than names beginning
> with just '_'.

I thought that's what namespace were invented for:
'xyz::company_identifier'

> Namespaces alleviate a lot of these problems, but don't entirely
> eliminate them; you still have to deal with preprocessor names (which
> have no scope limitations) and coming up with a fairly unique
> namespace to begin with.

I can see that using underscored preprocessor names (like my
former favorite '__INCLUEDED__MYHEADER_H__') is not the thing
to do.

> Then there's the problem of differentiating between things like
> member functions and member variables. Some programmers provide
> access functions like size() which access private members variables
> such as _size. I prefer to use an 'm_' prefix for member variables,
> and 's_' for static member variables; it has the benefit of making
> it somewhat clearer where the name comes from when seen in the code
> of my member functions.
>
> Then there's the problem of how to name function parameters and
> local variables within functions.

My favorite:

MyClass::MyClass(unsigned uSize)
: _uSize(uSize)
{
}

Knowing my conventions, simply looking at the name '_size' you
would know that it is the name of an unsigned int variable which
is a protected class member. No context needed.

> In summary, while there's no single, easy solution, the best advice
> is to try to avoid collisions among externally visible names with
> user and other third-party names. ("Externally visible" means
> namespaces, typedefs, struct/class/union tags, enumeration constants,
> global functions, global variables, global constants, and preprocessor
> macros.)

Of course. Who wouldn't want this?

> Using a single underscore is generally not enough.

Mhmm. Why? (Still not convinced.)

Schobi


[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
[ about comp.lang.c++.moderated. First time posters: do this! ]

[ comp.std.c++ is moderated. To submit articles, try just posting with ]

Francis Glassborow

unread,
Nov 5, 1999, 3:00:00 AM11/5/99
to
In article <7vorl0$v1e$1...@news1.transmedia.de>, Hendrik Schober
<h.sc...@nospam.callassoftware.com> writes

>Because people (especially in clcm ;-), try deja) mocked about it
> quite often, I recently dropped this. Now I'm looking for new conventions
> which have the expresional power of the (combined) old once.

Why not consider appending qualifiers rather than prepending them:

name_ rather than _name

The double underscore is more awkward but something like:

name_protected
name_public

if you really want to draw attention to the odd cases

or

name_2 // for private
name_1 // for protected
name_0 // for public

My point is that we should not obscure well chosen identifiers by
prepending secondary information, if you really want a style that
includes this secondary information in an identifier, put it at the end.


Francis Glassborow Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
---

Al Stevens

unread,
Nov 9, 1999, 3:00:00 AM11/9/99
to

The introduction of namespaces and the std:: namespace would seem to make
the underscore prefix rule a relic. No standard library implementer needs to
use an underscore to insulate global symbols from other symbols in the
global namespace because they are protected by the std namespace.

Furthermore, since an implementation is not required to issue a diagnostic
to offenders (presumably to keep from having to somehow tell the difference
between standard library declarations and user declarations in the same
translation unit, which std is supposed to take care of anyway), the rule
cannot be enforced and, like any such unenforceable rule, is no rule at all.

I do not understand why this obsolete rule was not eliminated from the
standard. Perhaps there is a nuance I am missing? Wouldn't be the first
time.

(Is "prepend" really a word?)

Pete Becker

unread,
Nov 9, 1999, 3:00:00 AM11/9/99
to

Al Stevens wrote:
>
> I do not understand why this obsolete rule was not eliminated from the
> standard. Perhaps there is a nuance I am missing? Wouldn't be the first
> time.
>

Macros.

> (Is "prepend" really a word?)
>

Not according to my dictionary.

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

Matt Austern

unread,
Nov 9, 1999, 3:00:00 AM11/9/99
to

"Al Stevens" <alst...@midifitz.com> writes:

> The introduction of namespaces and the std:: namespace would seem to make
> the underscore prefix rule a relic. No standard library implementer needs to
> use an underscore to insulate global symbols from other symbols in the
> global namespace because they are protected by the std namespace.

Except for macros. How should this program behave? Should its
behavior depend on whether the library implementor happens to
use a symbol called 'tmp'?

#define tmp 137
#include <iostream>

int main() {
std::cout << "Hello, world!" << std::endl;

Barry Margolin

unread,
Nov 9, 1999, 3:00:00 AM11/9/99
to
In article <38285AFB...@acm.org>,
Pete Becker <peteb...@acm.org> wrote:

>
>Al Stevens wrote:
>> (Is "prepend" really a word?)
>>
>
>Not according to my dictionary.

I found it on www.dictionary.com, but not www.m-w.com. It's probably a
term that computer geeks coined.

--
Barry Margolin, bar...@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
---

Al Stevens

unread,
Nov 9, 1999, 3:00:00 AM11/9/99
to
The standard macros are well-defined. We know what they are, there aren't
many of them, and I don't think any of them use the underscore prefix,
anyway, so those macros present no problem.

>How should this program behave? Should its
>behavior depend on whether the library implementor happens to
>use a symbol called 'tmp'?
>
> #define tmp 137
> #include <iostream>
>
> int main() {
> std::cout << "Hello, world!" << std::endl;
> }


That's the nuance I was looking for. I wouldn't think to code something
awful like that. But it's no worse (albeit more likely) than this:

#define cout foo
#include <iostream>

Of course the ready answer is that programmers should not do what your
example does. If they do, however, and if the tmp upsets how iostream uses
tmp, chances are very good that you'll get a diagnostic, exactly as you will
if you and the library both use _Tmp. So the question is, which is best to
prescribe? Don't use _Tmp, don't use macros ahead of #includes of standard
headers, or don't use macros at all?

David R Tribble

unread,
Nov 9, 1999, 3:00:00 AM11/9/99
to
Al Stevens wrote:
>
> The introduction of namespaces and the std:: namespace would seem to
> make the underscore prefix rule a relic. No standard library
> implementer needs to use an underscore to insulate global symbols
> from other symbols in the global namespace because they are protected
> by the std namespace.
>
> Furthermore, since an implementation is not required to issue a
> diagnostic to offenders (presumably to keep from having to somehow
> tell the difference between standard library declarations and user
> declarations in the same translation unit, which std is supposed to
> take care of anyway), the rule cannot be enforced and, like any such
> unenforceable rule, is no rule at all.
>
> I do not understand why this obsolete rule was not eliminated from the
> standard. Perhaps there is a nuance I am missing? Wouldn't be the
> first time.

None of your points above apply to preprocessor macro names. Such
names should have a way of being used by the implementor with the
guarantee that they won't collide with user names.

There's also the possibility that an implementation might require
global names outside the std:: namespace (perhaps for some linkage
convention to be compatible with C, for example).

Hence, the rule.

> (Is "prepend" really a word?)

Well, it *should* be a word if "append" is a word (cf. "affix",
"suffix", and "prefix"). But it is not listed in the online
Webster's dictionary (<http://www.m-w.com/>). It's the same
situation with "optimal" and "pessimal" (see The Hacker's Dictionary,
or <http://www.netmeg.net/jargon/terms/p.html#pessimal>.)

-- David R. Tribble, da...@tribble.com, http://david.tribble.com --

Hendrik Schober

unread,
Nov 10, 1999, 3:00:00 AM11/10/99
to

Francis Glassborow <fra...@robinton.demon.co.uk> wrote:
> Why not consider appending qualifiers rather than prepending them:
>
> name_ rather than _name

I'd seen this and considered it. Probably good. Still not sure...

> The double underscore is more awkward but something like:
>
> name_protected
> name_public
>
> if you really want to draw attention to the odd cases
>
> or
>
> name_2 // for private
> name_1 // for protected
> name_0 // for public
>
> My point is that we should not obscure well chosen identifiers by
> prepending secondary information, if you really want a style that
> includes this secondary information in an identifier, put it at the end.

I found it helpful to see whether an identifier can be used in
a specific context (class user, derived class etc.). To add an
"protected" or "private" suffix is of course awkward, but I never
considered this. (Numbers are a concept for computers, not for
humans.)
That's why I'm so sad about giving up my conventions. They were
short to type, simple to understand, and wouldn't get into the way
when reading the code.
Appending the underscores instead of prepending them probably
will be as close as possible to this without making anybody
unhappy about possible problems.

Michiel Salters

unread,
Nov 10, 1999, 3:00:00 AM11/10/99
to

Al Stevens wrote:

> The standard macros are well-defined. We know what they are, there aren't
> many of them, and I don't think any of them use the underscore prefix,
> anyway, so those macros present no problem.

> >How should this program behave? Should its
> >behavior depend on whether the library implementor happens to
> >use a symbol called 'tmp'?
> >
> > #define tmp 137
> > #include <iostream>

> > int main() {
> > std::cout << "Hello, world!" << std::endl;
> > }

> That's the nuance I was looking for. I wouldn't think to code something
> awful like that. But it's no worse (albeit more likely) than this:

> #define cout foo
> #include <iostream>

This is illegal, you're not allowed to #define cout before including
any standard header (ANY, not only iostream). The same protection is offered
for _tmp, but not for tmp. Which is why the rule is still needed.

(I'm not sure the ANY header part is literally in the standard, but it
follows from the fact that any standard header may include other
standard headers).


Michiel Salters

James Kuyper Jr.

unread,
Nov 11, 1999, 3:00:00 AM11/11/99
to
Al Stevens wrote:
>
> The standard macros are well-defined. We know what they are, there aren't
> many of them, and I don't think any of them use the underscore prefix,
> anyway, so those macros present no problem.

It's the user-defined macros that matter for this example, not the
standard ones. Also, the fact that such names are currently reserved to
the implementation, means that you should expect that any standard
header might #define macros using such names.

> >How should this program behave? Should its
> >behavior depend on whether the library implementor happens to
> >use a symbol called 'tmp'?
> >
> > #define tmp 137
> > #include <iostream>
> >
> > int main() {
> > std::cout << "Hello, world!" << std::endl;
> > }
>
> That's the nuance I was looking for. I wouldn't think to code something
> awful like that. But it's no worse (albeit more likely) than this:

Would you care to identify what's awful about that? The only features it
contains that matter are a #define of an unreserved symbol, followed by
a #include of a standard header. That's not a particularly rare
combination. If all symbols were unreserved, this would be a severe
problem for implementors.



> #define cout foo
> #include <iostream>

Which is illegal, unlike the first case, because cout is reserved to the
implementation in this context. This is an example of the purpose of
reserved names.

> Of course the ready answer is that programmers should not do what your
> example does. If they do, however, and if the tmp upsets how iostream uses
> tmp, chances are very good that you'll get a diagnostic, exactly as you will

Don't count on it. Often such a #define will silently convert legal code
to different legal code which doesn't, however, do what you expect. Even
if you get a diagnostic, there's a good chance it will be even more
obscure than usual, due to the altered naming.

> if you and the library both use _Tmp. So the question is, which is best to
> prescribe? Don't use _Tmp, don't use macros ahead of #includes of standard
> headers, or don't use macros at all?

How can you guarantee not using macros ahead of #includes of standard
headers? Standard headers may be #included by your own headers, or
headers associated with third-party software. Those headers may also
define macros. If you #include two different user-written headers, the
macros #defined by the first one might interfere with the standard
headers #included by the second one, if it weren't for the existence of
reserved names.

Steve Clamage

unread,
Nov 11, 1999, 3:00:00 AM11/11/99
to
Al Stevens wrote:
>
> The standard macros are well-defined. We know what they are, there aren't
> many of them, and I don't think any of them use the underscore prefix,
> anyway, so those macros present no problem.

The standard macros for C++ are well known, and don't begin
with underscores. But the implementation is allowed to add its
own macros that begin with "__" or "_<letter>", and you don't
know what those are. In addition, there are other standards with
their own prescriptions, such as POSIX or X/Open in the Unix
world, whatever Microsoft decides to use on Windows, whatever
Apple decides to use on MacOS, etc, etc.

>
> >How should this program behave? Should its
> >behavior depend on whether the library implementor happens to
> >use a symbol called 'tmp'?
> >
> > #define tmp 137
> > #include <iostream>
> >
> > int main() {
> > std::cout << "Hello, world!" << std::endl;
> > }
>
> That's the nuance I was looking for. I wouldn't think to code something
> awful like that. But it's no worse (albeit more likely) than this:
>

> #define cout foo
> #include <iostream>

The standard already proscribes that example. If you declare or
define
a name in a context where it is reserved, the program results are
undefined. (17.4.3.1/3)

--
Steve Clamage, stephen...@sun.com

Darin Adler

unread,
Nov 11, 1999, 3:00:00 AM11/11/99
to
Al Stevens <alst...@midifitz.com> wrote:

> The standard macros are well-defined. We know what they are, there aren't
> many of them, and I don't think any of them use the underscore prefix,
> anyway, so those macros present no problem.

>> How should this program behave? Should its


>> behavior depend on whether the library implementor happens to
>> use a symbol called 'tmp'?
>>
>> #define tmp 137
>> #include <iostream>
>>
>> int main() {
>> std::cout << "Hello, world!" << std::endl;
>> }

Note that the issue doesn't only exist when you define a macro before an
#include of a standard header, because even macros defined after an #include
of a standard header can cause trouble when macros defined in the header are
expanded.

So in this example:

#include <cstdlib>
#define offset_helper 123

If you go to use the offsetof macro later, the library vendor must be sure
not to use the identifier offset_helper in the offsetof macro expansion. The
C and C++ standards solve this problem by reserving the identifiers that
begin with underscores, so the library vendor can use something like
std::_offset_helper and be sure that there will not be a collision.

> Of course the ready answer is that programmers should not do what your
> example does. If they do, however, and if the tmp upsets how iostream uses
> tmp, chances are very good that you'll get a diagnostic, exactly as you will

> if you and the library both use _Tmp.

This is fine if you plan to use your program with only one library
implementation and are not trying to write portable code. If you expect your
code to work on more than one implementation, you might want guarantees that
correctly written code will compile even with other versions of the library,
rather than "chances are very good that you'll get a diagnostic".

> So the question is, which is best to
> prescribe? Don't use _Tmp, don't use macros ahead of #includes of standard
> headers, or don't use macros at all?

The C++ standard says that you must not use _Tmp because it's reserved for
use by the library. This is in section 17.4.3.1.2 of the standard. If you
want to ignore this and decide that you want to use _Tmp, the standard no
longer provides any guarantee that your code will work.

For standard-conforming code, the only choice is "don't use _Tmp", and it
does not seem to me to be an onerous restriction.

I think it's also a good idea to use macros as little as possible.

-- Darin

fl...@my-deja.com

unread,
Nov 11, 1999, 3:00:00 AM11/11/99
to
In article <mC0W3.3492$t%4.12...@newscene.newscene.com>,

"Al Stevens" <alst...@midifitz.com> wrote:
> The standard macros are well-defined. We know what they are, there
aren't
> many of them, and I don't think any of them use the underscore prefix,
> anyway, so those macros present no problem.

What about standard library implementations that use macros INTERNALLY
for conditional compiling for specific platforms?

> >How should this program behave? Should its
> >behavior depend on whether the library implementor happens to
> >use a symbol called 'tmp'?
> >
> > #define tmp 137
> > #include <iostream>
> >
> > int main() {
> > std::cout << "Hello, world!" << std::endl;
> > }
>

> That's the nuance I was looking for. I wouldn't think to code
something
> awful like that. But it's no worse (albeit more likely) than this:
>
> #define cout foo
> #include <iostream>
>

> Of course the ready answer is that programmers should not do what your
> example does. If they do, however, and if the tmp upsets how iostream
uses
> tmp, chances are very good that you'll get a diagnostic, exactly as
you will
> if you and the library both use _Tmp.

Unfortunately, sometimes you DO NOT get a warning or whatever. Think
about it. It sounds like you don't have any experience with large scale
projects that are portable to multiple platforms.

So the question is, which is best to
> prescribe? Don't use _Tmp, don't use macros ahead of #includes of
standard
> headers, or don't use macros at all?

Why not just stick to the standard and don't use underscore prepended
symbols (and use ALL_UPPER_CASE for user defined macros, unless you
have a good reason)? this rule is much easier to follow than "don't use
macros ahead of #includes of standard headers" and/or "don't use macros
at all". Macros have their uses, and they are not going away, unless
you live in an isolated world. I just wish conforming compilers issue a
warning (can be turned off by options, of course) about underscore
prepended symbols in user code.

Fly


Sent via Deja.com http://www.deja.com/
Before you buy.

[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]

Hendrik Schober

unread,
Nov 11, 1999, 3:00:00 AM11/11/99
to

> Al Stevens <alst...@midifitz.com> wrote:
> >
> > The introduction of namespaces and the std:: namespace would seem to
make
> > the underscore prefix rule a relic. No standard library implementer
needs to
> > use an underscore to insulate global symbols from other symbols in the
> > global namespace because they are protected by the std namespace.
> > [...]

> > I do not understand why this obsolete rule was not eliminated from the
> > standard. Perhaps there is a nuance I am missing? Wouldn't be the first
> > time.

Pete Becker <peteb...@acm.org> answered:
> Macros.

Matt Austern <aus...@sgi.com> answered:
> Except for macros. [...]

David R Tribble <da...@tribble.com> answered:


> None of your points above apply to preprocessor macro names. Such
> names should have a way of being used by the implementor with the
> guarantee that they won't collide with user names.
>
> There's also the possibility that an implementation might require
> global names outside the std:: namespace (perhaps for some linkage
> convention to be compatible with C, for example).

Still seems like none of these would affect identifiers within my
(class) namespaces. I always thought it's because a compiler might
insert a -- say -- '__vptr' member into my classes and the like.
But having a class like
class MyClass {
protected:
virtual void _plugInForDerivedClasses() = 0;
private:
int __notAccessible;
};
would not be affected by the macro argument. Am I missing something?

{Yes. Macros don't respect scope. They're purely a text substitution
before language rules even begin to be considered. -hps}

Schobi

Steve Clamage

unread,
Nov 12, 1999, 3:00:00 AM11/12/99
to
Hendrik Schober wrote:
>

>
> Still seems like none of these would affect identifiers within my

> (class) namespaces. ... having a class like


> class MyClass {
> protected:
> virtual void _plugInForDerivedClasses() = 0;
> private:
> int __notAccessible;
> };
> would not be affected by the macro argument. Am I missing something?
>

If a standard header or the compiler itself defined a macro
__notAccessible (which it is allowed to do, since that name
is in the implementor's namespace), your class definition
would be turned into trash.

--
Steve Clamage, stephen...@sun.com
---

David R Tribble

unread,
Nov 13, 1999, 3:00:00 AM11/13/99
to
Al Stevens wrote:
>> I do not understand why this obsolete rule was not eliminated from
>> the standard. Perhaps there is a nuance I am missing? Wouldn't be
>> the first time.

Pete Becker wrote:
> Macros.

(You should know that, Al!)

Half in jest, half seriously, I have suggested that we add namespaces
to the preprocessor. Since the rest of the C++ language has
namespaces, why not the preprocessor? Granted, it would take a
few changes in the preprocessor lexicon, e.g.:

#define std::getc() ...
#define std::offsetof(t,m) ...

#ifdef std::getc
...
#endif

#define MINE::SIZE ...

etc.

We could go one step further and add a preprocessor "using"
directive:

#using std // recognizes implicit 'std::' macro prefixes

This would work and macros would once again look more like constants,
variables, and function names, they way they used to in good ol' C.
It would also reduce the scoping problem of macros, since the prefix
(or #using) would be required.

However, as some of you undoubtedly have noticed, this whole thing
is not really very different from simply using a prefix on the macro
names:

#define std_getc() ...
#define std_offsetof(t,m) ...

#ifdef std_getc
...
#endif

#define MINE_SIZE ...

etc.

Most good packages use a unique affix on their names to minimize
collisions with client code and other third-party code. It's a pity
that none of the standard C and C++ library names do this, though.
If they did, I expect that more programmers would be in the habit
of doing it in their own code.

Hendrik Schober

unread,
Nov 13, 1999, 3:00:00 AM11/13/99
to
Hendrik Schober <h.sc...@nospam.callassoftware.com> wrote:
> Still seems like none of these would affect identifiers within my
> (class) namespaces. I always thought it's because a compiler might
> insert a -- say -- '__vptr' member into my classes and the like.
> But having a class like

> class MyClass {
> protected:
> virtual void _plugInForDerivedClasses() = 0;
> private:
> int __notAccessible;
> };
> would not be affected by the macro argument. Am I missing something?
>
> {Yes. Macros don't respect scope. They're purely a text substitution
> before language rules even begin to be considered. -hps}

So what? To #define a macro '__notAccessible' is explicitly forbitten by
the standard.

Schobi

Darin Adler

unread,
Nov 15, 1999, 3:00:00 AM11/15/99
to

Hendrik Schober <h.sc...@nospam.callassoftware.com> wrote:

>> But having a class like
>>
>> class MyClass {
>> protected:
>> virtual void _plugInForDerivedClasses() = 0;
>> private:
>> int __notAccessible;
>> };
>>
>> would not be affected by the macro argument. Am I missing something?
>>
>> {Yes. Macros don't respect scope. They're purely a text substitution
>> before language rules even begin to be considered. -hps}

> So what? To #define a macro '__notAccessible' is explicitly forbitten by
> the standard.

A conforming program is forbidden to define a macro with the name
__notAccessible. But an implementation is not forbidden to define a macro
with that name. Names with double-underscore sequences are reserved for the
implementation for any use [17.4.3.1.2], including the possibility of
predefining macros with these names.

The standard allows any compiler to define a macro named __notAccessible.
This is precisely why conforming programs can not rely on the fact that such
a macro is not defined.

-- Darin


[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
[ about comp.lang.c++.moderated. First time posters: do this! ]

[ comp.std.c++ is moderated. To submit articles, try just posting with ]

Pete Becker

unread,
Nov 15, 1999, 3:00:00 AM11/15/99
to

Hendrik Schober wrote:
>
> Hendrik Schober <h.sc...@nospam.callassoftware.com> wrote:
> > Still seems like none of these would affect identifiers within my
> > (class) namespaces. I always thought it's because a compiler might
> > insert a -- say -- '__vptr' member into my classes and the like.
> > But having a class like
> > class MyClass {
> > protected:
> > virtual void _plugInForDerivedClasses() = 0;
> > private:
> > int __notAccessible;
> > };
> > would not be affected by the macro argument. Am I missing something?
> >
> > {Yes. Macros don't respect scope. They're purely a text substitution
> > before language rules even begin to be considered. -hps}
>
> So what? To #define a macro '__notAccessible' is explicitly forbitten by
> the standard.
>

No, it's not forbidden. It's reserved to the implementation. Such a name
can be used in the standard headers.

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

[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]

James Kuyper Jr.

unread,
Nov 15, 1999, 3:00:00 AM11/15/99
to

Hendrik Schober wrote:
....

> So what? To #define a macro '__notAccessible' is explicitly forbitten by
> the standard.

Yes - and this thread is about a suggestion that that prohibition be
removed, supposedly because the existence of namespaces removes the need
for it.

{No, because compilers and standard library headers are permitted to
#define __notAccessible, which will not respect namespaces or any
other kind of scope. -hps}

Joerg Barfurth

unread,
Nov 15, 1999, 3:00:00 AM11/15/99
to

Hendrik Schober <h.sc...@nospam.callassoftware.com> wrote:

> Hendrik Schober <h.sc...@nospam.callassoftware.com> wrote:
> > Still seems like none of these would affect identifiers within my
> > (class) namespaces. I always thought it's because a compiler might
> > insert a -- say -- '__vptr' member into my classes and the like.
> > But having a class like
> > class MyClass {
> > protected:
> > virtual void _plugInForDerivedClasses() = 0;
> > private:
> > int __notAccessible;
> > };
> > would not be affected by the macro argument. Am I missing something?
> >
> > {Yes. Macros don't respect scope. They're purely a text substitution
> > before language rules even begin to be considered. -hps}
>

> So what? To #define a macro '__notAccessible' is explicitly forbitten by
> the standard.

That's just the point: it is forbidden to #define a macro
'__notAccessible' in _user_ code. That name belongs to the
implementation for ANY use. So the implementation (compiler,standard
library,...) may use it:
- for a macro - EXAMPLE:
#define __notAccessible __illegal() { delete this; }
- for an implementation-specific extension - EXAMPLE:
linker directive: disregard all references to this class
- for a hidden member in all non-POD classes
- ... (be creative)

Greetings
-- Jörg Barfurth

Al Stevens

unread,
Nov 15, 1999, 3:00:00 AM11/15/99
to

>This is illegal, you're not allowed to #define cout before including
>any standard header (ANY, not only iostream).

Are you referring to a specific rule in the standard that makes that
particular #define illegal, or just saying that it's really not a good idea?

Al Stevens

unread,
Nov 15, 1999, 3:00:00 AM11/15/99
to

>Why not just stick to the standard and don't use underscore prepended
>symbols (and use ALL_UPPER_CASE for user defined macros, unless you
>have a good reason)? this rule is much easier to follow than ...

All rules are easy to follow when the translator issues a diagnostic. In the
case of the underscore rule it is not required to. The rule then, is only a
paper rule written in the standard document, which targets primarily
developers of language translators rather than programmers who use the
language. This suggests a catch 22. The standard articulates but fails to
specify enforcement of a rule that exempts the programmers who are most
likely to read the rule and applies to those who are most likely not to read
it.

Hendrik Schober

unread,
Nov 15, 1999, 3:00:00 AM11/15/99
to

Steve Clamage <stephen...@sun.com> wrote:
> Hendrik Schober wrote:
> > (class) namespaces. ... having a class like

> > class MyClass {
> > protected:
> > virtual void _plugInForDerivedClasses() = 0;
> > private:
> > int __notAccessible;
> > };
> If a standard header or the compiler itself defined a macro
> __notAccessible (which it is allowed to do, since that name
> is in the implementor's namespace), your class definition
> would be turned into trash.

Huh? Macro in a namespace?
I see your point, though. I just didn't dream of anybody using
macro names which aren't capitalized.

Schobi

James Kuyper Jr.

unread,
Nov 16, 1999, 3:00:00 AM11/16/99
to

Hendrik Schober wrote:
>
> > Al Stevens <alst...@midifitz.com> wrote:
> > >
> > > The introduction of namespaces and the std:: namespace would seem to
> make
> > > the underscore prefix rule a relic. No standard library implementer
> needs to
> > > use an underscore to insulate global symbols from other symbols in the
> > > global namespace because they are protected by the std namespace.
> > > [...]
> > > I do not understand why this obsolete rule was not eliminated from the
> > > standard. Perhaps there is a nuance I am missing? Wouldn't be the first
> > > time.
>
> Pete Becker <peteb...@acm.org> answered:
> > Macros.
>
> Matt Austern <aus...@sgi.com> answered:
> > Except for macros. [...]
>
> David R Tribble <da...@tribble.com> answered:
> > None of your points above apply to preprocessor macro names. Such
> > names should have a way of being used by the implementor with the
> > guarantee that they won't collide with user names.
> >
> > There's also the possibility that an implementation might require
> > global names outside the std:: namespace (perhaps for some linkage
> > convention to be compatible with C, for example).
>
> Still seems like none of these would affect identifiers within my
> (class) namespaces. I always thought it's because a compiler might
> insert a -- say -- '__vptr' member into my classes and the like.
> But having a class like

> class MyClass {
> protected:
> virtual void _plugInForDerivedClasses() = 0;
> private:
> int __notAccessible;
> };
> would not be affected by the macro argument. Am I missing something?

Yes - the possibility that __notAccessible or _plugInForDerivedClasses
or MyClass might have been given a macro definitions before reaching
this point in your code.
Without the reserved namespace rules, you couldn't be sure about any of
those three, no matter whether this is user code or standard header
code, no matter whether or not it is enclosed in a namespace.

With the reserved namespace rules, it depends upon whether MyClass is
meant as an example of user code or as an example of code inside a
standard header. I'm not sure which you meant it to be, but it's
incorrect for either use:

As user code:
The user can't be sure that an implementation didn't define
__notAccessible, possibly as a macro, maybe even as a keyword extension
to C++. You should drop it down to something unreserved in this context,
such as _notAccessible.

As code contained in a standard header:
The implementor can't be sure that user code previous to #including the
standard header might not have defined a macro named MyClass. You should
change it to something reserved in this context, such as _MyClass.

Either way, the code could break, most likely with a diagnostic, but
there's no guarantee that you'll get any warning. Namespaces are no help
whatsoever in avoiding such problems.

Steve Clamage

unread,
Nov 16, 1999, 3:00:00 AM11/16/99
to

Hendrik Schober wrote:
>
> Steve Clamage <stephen...@sun.com> wrote:
> > Hendrik Schober wrote:
> > > (class) namespaces. ... having a class like

> > > class MyClass {
> > > protected:
> > > virtual void _plugInForDerivedClasses() = 0;
> > > private:
> > > int __notAccessible;
> > > };
> > If a standard header or the compiler itself defined a macro
> > __notAccessible (which it is allowed to do, since that name
> > is in the implementor's namespace), your class definition
> > would be turned into trash.
>
> Huh? Macro in a namespace?
> I see your point, though. I just didn't dream of anybody using
> macro names which aren't capitalized.
>

Unfortunately, we have two different meanings for the word
"namespace".

It makes no difference whether a macro is defined inside or outside
any C++ namespace, since macros definitions are recognized and all
uses are expanded before the spelling "namespace" is recognized as
a keyword.

The other use of "namespace" is in meaning a set of identifier
spellings -- that is the usage in the C standard. Some sets of
identifiers are reserved for use by the implementation (the
implementer's namespace), the remainder being reserved for use by
the programmer (the programmer's namespace).

--
Steve Clamage, stephen...@sun.com

James Kuyper Jr.

unread,
Nov 17, 1999, 3:00:00 AM11/17/99
to
Hendrik Schober wrote:
>
> Steve Clamage <stephen...@sun.com> wrote:
> > Hendrik Schober wrote:
> > > (class) namespaces. ... having a class like
> > > class MyClass {
> > > protected:
> > > virtual void _plugInForDerivedClasses() = 0;
> > > private:
> > > int __notAccessible;
> > > };
> > If a standard header or the compiler itself defined a macro
> > __notAccessible (which it is allowed to do, since that name
> > is in the implementor's namespace), your class definition
> > would be turned into trash.
>
> Huh? Macro in a namespace?

No, not a macro in a namespace, a macro anywhere in the code above the
place where you define or use __notAccessible. Macros work across
namespace boundaries, so namespaces provide no protection against the
damage they can do.

> I see your point, though. I just didn't dream of anybody using
> macro names which aren't capitalized.

That convention is not required by the standard. Many macros in the C++
standard headers are not fully capitalized, including assert, errno,
L_tmpnam, offsetof, setjmp, stderr, stdin, stdout, va_arg, va_end, and
va_start. The C standard allows some of these to be functions, but
they're all required to be macros in C++.

James Kuyper Jr.

unread,
Nov 17, 1999, 3:00:00 AM11/17/99
to
Hendrik Schober wrote:
>
> Hendrik Schober <h.sc...@nospam.callassoftware.com> wrote:
> > Still seems like none of these would affect identifiers within my
> > (class) namespaces. I always thought it's because a compiler might
> > insert a -- say -- '__vptr' member into my classes and the like.
> > But having a class like

> > class MyClass {
> > protected:
> > virtual void _plugInForDerivedClasses() = 0;
> > private:
> > int __notAccessible;
> > };
> > would not be affected by the macro argument. Am I missing something?
> >
> > {Yes. Macros don't respect scope. They're purely a text substitution
> > before language rules even begin to be considered. -hps}
>
> So what? To #define a macro '__notAccessible' is explicitly forbitten by
> the standard.

Yes - but you were apparently arguing for removal of that rule.

Ron Natalie

unread,
Nov 17, 1999, 3:00:00 AM11/17/99
to
Al Stevens wrote:
>
> The introduction of namespaces and the std:: namespace would seem to make
> the underscore prefix rule a relic. No standard library implementer needs to
> use an underscore to insulate global symbols from other symbols in the
> global namespace because they are protected by the std namespace.

Perhaps it is not the "Standard" library that's the issue.
Unfortunately,
the standard doesn't bar the implementation from poluting the namespace
with underscore prefixed junk. Just about every implemetation (even
those purporting to be standard) tends to def in a few preprocessor
symbols like __machine_type or the like. It also allows a "safe and
compliant place" to park some extensions to the language such as new
data types (__int64) and other implementation extensions.


>
> Furthermore, since an implementation is not required to issue a diagnostic
> to offenders (presumably to keep from having to somehow tell the difference
> between standard library declarations and user declarations in the same
> translation unit, which std is supposed to take care of anyway), the rule
> cannot be enforced and, like any such unenforceable rule, is no rule at all.

There's all kinds of unenforcable stuff in the C++ spec under the guise
of "undefined behavior." What exists, are rules by which the programmer
must play by to avoid bumping into these lawless local dependencies.

> I do not understand why this obsolete rule was not eliminated from the
> standard. Perhaps there is a nuance I am missing? Wouldn't be the first
> time.

Perhaps they figured that they'd never get the implemetations cleaned
up so they allowed this digression.

James Kuyper

unread,
Nov 17, 1999, 3:00:00 AM11/17/99
to
"James Kuyper Jr." wrote:
>
> Hendrik Schober wrote:
> ....

> > So what? To #define a macro '__notAccessible' is explicitly forbitten by
> > the standard.
>
> Yes - and this thread is about a suggestion that that prohibition be
> removed, supposedly because the existence of namespaces removes the need
> for it.
>
> {No, because compilers and standard library headers are permitted to
> #define __notAccessible, which will not respect namespaces or any
> other kind of scope. -hps}

I assumed that Hendrik was referring only to portable user code, since
his statement would be true in that context; I suppose I should have
made that clearer.
I do understand that macros don't respect namespaces, and the
consequences of that fact in this context. That's why I used the term
"supposedly".
---

James Kuyper Jr.

unread,
Nov 17, 1999, 3:00:00 AM11/17/99
to
Ron Natalie wrote:
....

> Unfortunately,
> the standard doesn't bar the implementation from poluting the namespace
> with underscore prefixed junk. Just about every implemetation (even

You can't easily implement the standard library without having a name
space reserved to the implementation. The standard classes need members
and base classes in addition to the ones required by the standard. Those
will have to be given names, and those names must not conflict with any
macro #defined ahead of the standard header.
In addition, efficient implementations often use inline functions whose
parameter names and local variables must also not conflict with such
macros.

> those purporting to be standard) tends to def in a few preprocessor
> symbols like __machine_type or the like. It also allows a "safe and

Yes - that's an ordinary commonplace need, which is one of the key
reasons why such names were reserved.

....


> There's all kinds of unenforcable stuff in the C++ spec under the guise
> of "undefined behavior." What exists, are rules by which the programmer
> must play by to avoid bumping into these lawless local dependencies.

You misunderstand "undefined behavior". It is a deliberate license for
the implementation to do things in the way that's most convenient for
the implementation, even if those ways cause problems under
circumstances which allow undefined behavior. It's unenforceable because
there was a deliberate decision to not enforce something. It is
deliberately the case that the standard allows undefined behavior to
include doing something useful.

> > I do not understand why this obsolete rule was not eliminated from the
> > standard. Perhaps there is a nuance I am missing? Wouldn't be the first
> > time.
>
> Perhaps they figured that they'd never get the implemetations cleaned
> up so they allowed this digression.

Well, that's true, in a sense. It's practically impossible to implement
the standard library reliably without some kind of reserved name space.
So what you call a "cleaned up" implementation is indeed unlikely.

Pete Becker

unread,
Nov 17, 1999, 3:00:00 AM11/17/99
to

Ron Natalie wrote:

>
> Al Stevens wrote:
> >
> > I do not understand why this obsolete rule was not eliminated from the
> > standard. Perhaps there is a nuance I am missing? Wouldn't be the first
> > time.
>
> Perhaps they figured that they'd never get the implemetations cleaned
> up so they allowed this digression.
>

No, "they" understood that it's still necessary to give implementors a
way of protecting themselves from user-defined macros.

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

[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
[ about comp.lang.c++.moderated. First time posters: do this! ]

[ comp.std.c++ is moderated. To submit articles, try just posting with ]

Gabriel Dos_Reis

unread,
Nov 17, 1999, 3:00:00 AM11/17/99
to
"Hendrik Schober" <h.sc...@nospam.callassoftware.com> writes:

| Steve Clamage <stephen...@sun.com> wrote:
| > Hendrik Schober wrote:

| > > (class) namespaces. ... having a class like


| > > class MyClass {
| > > protected:
| > > virtual void _plugInForDerivedClasses() = 0;
| > > private:
| > > int __notAccessible;
| > > };

| > If a standard header or the compiler itself defined a macro
| > __notAccessible (which it is allowed to do, since that name
| > is in the implementor's namespace), your class definition
| > would be turned into trash.
|
| Huh? Macro in a namespace?

| I see your point, though. I just didn't dream of anybody using
| macro names which aren't capitalized.

Can you say 'assert' ?

--
Gabriel Dos Reis, dos...@cmla.ens-cachan.fr
---

Hendrik Schober

unread,
Nov 18, 1999, 3:00:00 AM11/18/99
to

James Kuyper Jr. <kuy...@wizard.net> wrote:
> Hendrik Schober wrote:
> > [...] Am I missing something?


>
> Yes - the possibility that __notAccessible or _plugInForDerivedClasses
> or MyClass might have been given a macro definitions before reaching
> this point in your code.
> Without the reserved namespace rules, you couldn't be sure about any of
> those three, no matter whether this is user code or standard header
> code, no matter whether or not it is enclosed in a namespace.
>
> With the reserved namespace rules, it depends upon whether MyClass is
> meant as an example of user code or as an example of code inside a
> standard header. I'm not sure which you meant it to be, but it's
> incorrect for either use:

I'm concerned of my code, not the library implementers' code ;-)

> As user code:
> The user can't be sure that an implementation didn't define
> __notAccessible, possibly as a macro, maybe even as a keyword extension
> to C++.

After so many posts I see this now.

> You should drop it down to something unreserved in this context,
> such as _notAccessible.

The original problem was my naming conventions which included double
underscore for private identifiers (see my first post in this thread).
I know I have to switch but I'm missing the "Good Old Rules Of Mine".

> [...]


> Either way, the code could break, most likely with a diagnostic, but
> there's no guarantee that you'll get any warning. Namespaces are no help
> whatsoever in avoiding such problems.

As I said before in this thread: I did have bad problems with identifiers
without breaking any rule. I never had one because of leading underscors.
But I agree anyway and I'm trying to make a change.

Schobi


[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
[ about comp.lang.c++.moderated. First time posters: do this! ]

[ comp.std.c++ is moderated. To submit articles, try just posting with ]

Hendrik Schober

unread,
Nov 19, 1999, 3:00:00 AM11/19/99
to
Gabriel Dos_Reis <gdos...@korrigan.inria.fr> wrote:
> "Hendrik Schober" <h.sc...@nospam.callassoftware.com> writes:
>
> | Steve Clamage <stephen...@sun.com> wrote:
> | > Hendrik Schober wrote:
> | > > (class) namespaces. ... having a class like
> | > > class MyClass {
> | > > protected:
> | > > virtual void _plugInForDerivedClasses() = 0;
> | > > private:
> | > > int __notAccessible;
> | > > };
> | > If a standard header or the compiler itself defined a macro
> | > __notAccessible (which it is allowed to do, since that name
> | > is in the implementor's namespace), your class definition
> | > would be turned into trash.
> |
> | Huh? Macro in a namespace?
> | I see your point, though. I just didn't dream of anybody using
> | macro names which aren't capitalized.
>
> Can you say 'assert' ?

I can even type it ;-)
I was taking about identifiers that are not named by the standard.

Hendrik Schober

unread,
Nov 19, 1999, 3:00:00 AM11/19/99
to
James Kuyper Jr. <kuy...@wizard.net> wrote:
> Hendrik Schober wrote:
> > [...]
> > So what? To #define a macro '__notAccessible' is explicitly forbitten
by
> > the standard.
>
> Yes - but you were apparently arguing for removal of that rule.

No. Yes. Well...
I think you caught me. ;-)

I wished that macros were forbitten, other idendifiers weren't...
(And before anybody cries: I wished non-capitalized macros, especially
those with leading underscores were forbitten.)
To be more precise: I wished that implementers could name their
implementation specific identifiers what they want, as long as they
don't confict with identifiers within my namespaces (to which I'd add
the global namespace for that matter). That would give me the freedom
to name my identifiers as I want as long as they don't conflict with
standard identifiers ('assert', 'std::cout', or 'for').

Al Stevens

unread,
Nov 19, 1999, 3:00:00 AM11/19/99
to
Steve Clamage wrote in message <3829C4BA...@sun.com>...

> But the implementation is allowed to add its
>own macros that begin with "__" or "_<letter>", and you don't
>know what those are.

Perhaps that's the real problem. Perhaps that usage should not be permitted.
(More about that in another message in this thread.) Aren't library
developers mostly sold on the notion that C++ has better alternatives to all
the known uses of #define and wouldn't they avoid such macros anyway?

Not that I'm sold on that notion, of course...
---

Matt Austern

unread,
Nov 21, 1999, 3:00:00 AM11/21/99
to

"Al Stevens" <alst...@midifitz.com> writes:

> Steve Clamage wrote in message <3829C4BA...@sun.com>...
>
> > But the implementation is allowed to add its
> >own macros that begin with "__" or "_<letter>", and you don't
> >know what those are.
>
> Perhaps that's the real problem. Perhaps that usage should not be permitted.
> (More about that in another message in this thread.) Aren't library
> developers mostly sold on the notion that C++ has better alternatives to all
> the known uses of #define and wouldn't they avoid such macros anyway?

Mostly. There are a few places where macros are pretty hard to avoid,
though: conditional compilation, inclusion guards, workarounds for
different compilers each of which has different deficiencies. I don't
like macros, but I use them anyway.

[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
[ about comp.lang.c++.moderated. First time posters: do this! ]

[ comp.std.c++ is moderated. To submit articles, try just posting with ]

Al Stevens

unread,
Nov 22, 1999, 3:00:00 AM11/22/99
to
>None of your points above apply to preprocessor macro names. Such
>names should have a way of being used by the implementor with the
>guarantee that they won't collide with user names.

As I said elsewhere, "The standard macros are well-defined. We know what
they are, there aren't many of them, and I don't think any of them use the
underscore prefix, anyway, so those macros present no problem."

Presumably the library implementation, being a proper C++ library, would not
define macros other than those that the Standard specifies that it must
define, with or without the underscore prefix. At least that's the sense I
get when people deprecate the preprocessor as they do.

The underscore problem then is related to user-coded macros only, which we
may assume would not collide with system identifiers, which are nicely
tucked away in the std namespace and usually in class scope besides.

It seems to me that a more reasonable rule, one that would give users and
standard library developers more flexibility, would be to state that the
standard library shall not have macros with the underscore prefix and
neither shall the user. That would be a rule that seems like it would
protect everyone and that the compiler could actually enforce with a
diagnostic.

Jerry Coffin

unread,
Nov 22, 1999, 3:00:00 AM11/22/99
to
In article <T84Z3.9303$2J6.3...@newscene.newscene.com>,
alst...@midifitz.com says...

[ ... ]

> Perhaps that's the real problem. Perhaps that usage should not be permitted.
> (More about that in another message in this thread.) Aren't library
> developers mostly sold on the notion that C++ has better alternatives to all
> the known uses of #define and wouldn't they avoid such macros anyway?

Some things like assert, va_start, va_arg and va_end MUST be macros
(there are more, but those are the ones that occur to me right now).

C++ does have tighter controls over what things can be macros and what
can be functions than C does, but there are still quite a few places
that especially the C-like parts of a C++ standard library are likely
to use macros as well.

--
Later,
Jerry.

The universe is a figment of its own imagination.

C. M. Heard/VVNET, Inc.

unread,
Nov 22, 1999, 3:00:00 AM11/22/99
to
"Al Stevens" <alst...@midifitz.com> wrote:
> [ ... ] Aren't library developers mostly sold on the notion that C++

> has better alternatives to all the known uses of #define and wouldn't
> they avoid such macros anyway?

What about include guards for header files?

Mike
--
C. M. Heard/VVNET, Inc.
he...@vvnet.com

Herb Sutter

unread,
Nov 22, 1999, 3:00:00 AM11/22/99
to
On 22 Nov 99 00:47:02 GMT, "Al Stevens" <alst...@midifitz.com> wrote:
>As I said elsewhere, "The standard macros are well-defined. We know what
>they are, there aren't many of them, and I don't think any of them use the
>underscore prefix, anyway, so those macros present no problem."

>The underscore problem then is related to user-coded macros only, which we

No: __FILE__, __LINE__, etc.

>It seems to me that a more reasonable rule, one that would give users and
>standard library developers more flexibility, would be to state that the
>standard library shall not have macros with the underscore prefix and
>neither shall the user. That would be a rule that seems like it would
>protect everyone and that the compiler could actually enforce with a
>diagnostic.

How would denying some names to all people help protect against
collisions between implementer- and user-defined names? Much more
reasonable would be to partition names unequivocally between
implementers and users, for example by adopting for macros the same
rules as for global names:

17.4.3.1.2 Global names [lib.global.names]

1 Certain sets of names and function signatures are always reserved to
the implementation:
--Each name that contains a double underscore __) or begins with an
underscore followed by an uppercase letter (_lex.key_) is reserved
to the implementation for any use.
--Each name that begins with an underscore is reserved to the imple-
mentation for use as a name in the global namespace.22)

Although 17.4.3.1.1 talks about macros, it's not clear to me that
17.4.3.1.2/1 point 1 (double-underscore reservation, above) wouldn't
apply to macros too.

Herb

---
Herb Sutter (mailto:hsu...@peerdirect.com)

PeerDirect Inc. 2695 North Sheridan Way, Suite 150
www.peerdirect.com Mississauga Ontario Canada L5K 2N6
---

Al Stevens

unread,
Nov 22, 1999, 3:00:00 AM11/22/99
to
>What about include guards for header files?

#ifndef STD_CSTDIO_H
#define STD_CSTDIO_H

// ......

#endif

What about them?

James Kuyper Jr.

unread,
Nov 22, 1999, 3:00:00 AM11/22/99
to
Al Stevens wrote:
....

> It seems to me that a more reasonable rule, one that would give users and
> standard library developers more flexibility, would be to state that the
> standard library shall not have macros with the underscore prefix and
> neither shall the user. That would be a rule that seems like it would

Why prohibit the use of an identifier for everybody? The reason for the
current prohibitions are to reserve some identifiers for users, and
others for the implementation, in order to avoid name collisions.
However, what use is an identifier that no one can use?

Hendrik Schober

unread,
Nov 22, 1999, 3:00:00 AM11/22/99
to

Hendrik Schober <h.sc...@nospam.callassoftware.com> wrote:
>
> [...]


>
> {Yes. Macros don't respect scope. They're purely a text substitution
> before language rules even begin to be considered. -hps}

I got another idea, then.
Why not specify that standard macros must start with a prefix (like
'__STD'), just as the other identifiers are wrapped within namepsace
'std'?. Implementers of other libraries could probably protect their
macros with '__LIB'.
This would reduce the danger for the users to these two prefixes and
put the burden onto the library providers. (Am I to unfair to them?)

Schobi

[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
[ about comp.lang.c++.moderated. First time posters: do this! ]

[ comp.std.c++ is moderated. To submit articles, try just posting with ]

Al Stevens

unread,
Nov 22, 1999, 3:00:00 AM11/22/99
to

>How would denying some names to all people help protect against
>collisions between implementer- and user-defined names?

Here's how:

1. Library implementors could not assign macro names with underscore
prefixes. All library macros would be those that the standard prescribes.
(There might need to be a specific convention for standard library header
#defines that prevent multiple inclusion.)

2. Library implementors would use underscore prefixed names within the std
namespace and in class scope. This practice protects the names they need for
nonmacros, names not specified by the standard, because ...

3. Users also could not assign macro names with underscore prefixes. This
prevents user-defined macros from colliding with library implementer defined
names.

4. Users could also use underscore-prefixed names for other non-macro things
if they wanted to because the std namespace protects the non-macro names in
the standard library.

5. The preprocessor does not need to differentiate between library
implementors and users when enforcing this rule.

Matt Austern

unread,
Nov 23, 1999, 3:00:00 AM11/23/99
to

"Al Stevens" <alst...@midifitz.com> writes:

> >What about include guards for header files?
>
> #ifndef STD_CSTDIO_H
> #define STD_CSTDIO_H
>
> // ......
>
> #endif
>
> What about them?

I would expect a standard library implementor to use __STD_CSTDIO_H
instead. Users, after all, have a perfect right to use a name like
STD_CSTDIO_H themselves, either as a macro or as an ordinary
identifier.

James Kuyper

unread,
Nov 23, 1999, 3:00:00 AM11/23/99
to

Al Stevens wrote:
>
> >What about include guards for header files?
>
> #ifndef STD_CSTDIO_H
> #define STD_CSTDIO_H
>
> // ......
>
> #endif
>
> What about them?

You said "C++ has better alternatives to all the known uses of #define".
What's the alternative that covers this use?

Darin Adler

unread,
Nov 23, 1999, 3:00:00 AM11/23/99
to

Al Stevens wrote:

>> It seems to me that a more reasonable rule, one that would give users and
>> standard library developers more flexibility, would be to state that the
>> standard library shall not have macros with the underscore prefix and
>> neither shall the user. That would be a rule that seems like it would

>> protect everyone and that the compiler could actually enforce with a
>> diagnostic.

Herb Sutter <hsu...@peerdirect.com> wrote:

> How would denying some names to all people help protect against
> collisions between implementer- and user-defined names?

James Kuyper Jr. <kuy...@wizard.net> wrote:

> Why prohibit the use of an identifier for everybody? The reason for the
> current prohibitions are to reserve some identifiers for users, and
> others for the implementation, in order to avoid name collisions.
> However, what use is an identifier that no one can use?

I believe the suggestion is to prohibit the use of identifiers with an
underscore as a prefix as *macros* for everybody. This would presumably make
identifiers that begin with an underscore available in all namespaces for
non-macro uses.

Identifiers with double underscores would still be reserved for any use by
the implementation.

This suggestion presumes that if implementations need to define macros, they
would have to use macros with double underscores in their names. This might
pose a slight problem as compilers typically use the double underscore
identifiers and libraries restrict themselves to the single underscores.

A possible problem with this suggestion is that the C standard has similar
rules about which identifiers are reserved for the implementation, and it
might cause trouble to have more-restrictive rules for C++.

-- Darin

Darin Adler

unread,
Nov 23, 1999, 3:00:00 AM11/23/99
to

Herb Sutter <hsu...@peerdirect.com> wrote:

> Much more reasonable would be to partition names unequivocally between
> implementers and users, for example by adopting for macros the same rules as
> for global names:
>
> 17.4.3.1.2 Global names [lib.global.names]
>
> 1 Certain sets of names and function signatures are always reserved to
> the implementation:
> --Each name that contains a double underscore __) or begins with an
> underscore followed by an uppercase letter (_lex.key_) is reserved
> to the implementation for any use.
> --Each name that begins with an underscore is reserved to the imple-
> mentation for use as a name in the global namespace.22)
>
> Although 17.4.3.1.1 talks about macros, it's not clear to me that
> 17.4.3.1.2/1 point 1 (double-underscore reservation, above) wouldn't
> apply to macros too.

"Any use" includes macros. The rule Herb suggests is already what the
standard requires.

Al Stevens

unread,
Nov 23, 1999, 3:00:00 AM11/23/99
to

>However, what use is an identifier that no one can use?

Tricky, ain't it? I refer you to my response above to Herb. No one can use
such an identifier as a macro name but they can use it otherwise, and, as
you'll see in the steps I presented to answer the same question from Herb,
such a rule would have done the job very well. By now, though, it's probably
too late except for thoughts for the future.

Pete Becker

unread,
Nov 23, 1999, 3:00:00 AM11/23/99
to

Al Stevens wrote:
>
> >What about include guards for header files?
>
> #ifndef STD_CSTDIO_H
> #define STD_CSTDIO_H
>
> // ......
>
> #endif
>
> What about them?

If this code appears in system header files, it's dangerous because
users can define macros with this name:

#define STD_CSTDIO_H
#include <cstdio>

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

[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]

Al Stevens

unread,
Nov 23, 1999, 3:00:00 AM11/23/99
to
>Some things like assert, va_start, va_arg and va_end MUST be macros
>(there are more, but those are the ones that occur to me right now).

But those don't begin with underscores, so they are not part of the issue.

Francis Glassborow

unread,
Nov 23, 1999, 3:00:00 AM11/23/99
to
In article <M44Z3.9301$