underscore-prepended variable names
hektor...@my-deja.com
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
> 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
>
> Both Lippman+Lajoie ("C++ Primer") and Gamma et al ("Design Patterns:
> Elements of OO Software") use underscore-prepended member variables
> names, such as "_variableName".
>
> 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,
> 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
[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.)
> -- David R. Tribble, da...@tribble.com, http://www.david.tribble.com --
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
<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
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
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
"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
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
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
>
> 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.
>
> 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.
>
> 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
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
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.
>
> 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
>
> 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
> 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
"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
> 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
>
>
> 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
>> 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.
-- David R. Tribble, da...@tribble.com, http://david.tribble.com --
Hendrik Schober
> Still seems like none of these would affect identifiers within my
> insert a -- say -- '__vptr' member into my classes and the like.
> class MyClass {
> protected:
> virtual void _plugInForDerivedClasses() = 0;
> private:
> int __notAccessible;
> };
> would not be affected by the macro argument. Am I missing something?
>
> 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
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
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.
> > 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.
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
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
>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
>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
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
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;
> > };
> __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.
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.
> > > [...]
> > > standard. Perhaps there is a nuance I am missing? Wouldn't be the first
> > > time.
>
> > 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).
>
> (class) namespaces. I always thought it's because a compiler might
> insert a -- say -- '__vptr' member into my classes and the like.
> class MyClass {
> protected:
> virtual void _plugInForDerivedClasses() = 0;
> private:
> int __notAccessible;
> };
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
> > > class MyClass {
> > > protected:
> > > virtual void _plugInForDerivedClasses() = 0;
> > > private:
> > > int __notAccessible;
> > > };
> > __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.
>
> 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.
> > (class) namespaces. I always thought it's because a compiler might
> > insert a -- say -- '__vptr' member into my classes and the like.
> > class MyClass {
> > protected:
> > virtual void _plugInForDerivedClasses() = 0;
> > private:
> > int __notAccessible;
> > };
> >
> > 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
>
> 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
>
> Hendrik Schober wrote:
> ....
> > So what? To #define a macro '__notAccessible' is explicitly forbitten by
> > the standard.
>
> 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.
....
> 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
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
| 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
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
> "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
by
> > the standard.
>
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
> 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
"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
>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
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.
> [ ... ] 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
>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
#ifndef STD_CSTDIO_H
#define STD_CSTDIO_H
// ......
#endif
What about them?
James Kuyper Jr.
....
> 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
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
>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
"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
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
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
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
>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
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
>(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
<alst...@midifitz.com> writes
>The underscore problem then is related to user-coded macros only, which we
>tucked away in the std namespace and usually in class scope besides.
But there-in lies the major problem, there is no way of hiding internal
names in libraries from macros.
A second consideration is that compiler implementors of the Standard
Library often need ways of controlling their header files to handle such
problems as sharing with C compilers, providing system headers that are
required by other standards though they share a header name etc.
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
> 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'.
That rule, like the existing rule, cannot be enforced by the preprocessor
unless it gets smart enough to distinguish between standard headers and
user's code.
Tim Ottinger
wrote:
>How would denying some names to all people help protect against
>collisions between implementer- and user-defined names?
Indeed!
>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:
And more reasonable yet is to avoid warts altogether in favor of
namespaces, which do the same job even better. I would rather see
something like MFC::int64 than _int64, just from a point of view of
information content.
With namespaces, why do we even want an underscore rule.
My personal agenda would be heavy-handed, because I'd require
identifiers not to start with underbars at all, though this would
break lots of existing code. But there's not much sense in it anymore.
We have a *real* programming language now.
tim
James Kuyper Jr.
....
> 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.
It does: "any use".
C. M. Heard/VVNET, Inc.
>>What about include guards for header files?
>
>#ifndef STD_CSTDIO_H
>#define STD_CSTDIO_H
>
>// ......
>
>#endif
>
>What about them?
As things now stand, STD_CSTDIO_H is not reserved to the implementation.
That means it's legal for me to define it in my code (as a macro, or as
anything else). I'd not be pleased with an implementation that defined
it and broke my code.
Implementations do need to define macros for include guards (and other
purposes). From my perspective, it's much better to know in advance
what form those macro names can take, so that it's at least possible
to avoid name conflicts.
As it happens, I recently fixed all the header files in a
medium-sized project to make the include guards comply with
the no-underscore-followed-by-a-capital-letter rule. I do
agree that it would have been less work for me if the violations
been diagnosed by the preprocessor; however, it was not that
hard (using grep) to do the job myself.
Mike
--
C. M. Heard/VVNET, Inc.
he...@vvnet.com
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Stan Brown
>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."
Nine do in C, and nine do in C++. (Eight of the nine are the same.)
See the respective standards, or my lists of reserved identifiers at
http://www.mindspring.com/~brahms/c-predef.htm
and
http://www.mindspring.com/~brahms/cppredef.htm
--
Stan Brown, Oak Road Systems, Cleveland, Ohio, USA
http://www.mindspring.com/~brahms/
C++ FAQ Lite: http://www.cerfnet.com/~mpcline/c++-faq-lite/
the C++ standard: http://webstore.ansi.org/ansidocstore/default.asp
more FAQs: http://www.mindspring.com/~brahms/faqget.htm
---
James Kuyper
> 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
Later, Al Stevens wrote:
...
> 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.)
True - for example, the convention could be that the names must start
with STD_. This would, of course, require that user code not use any
identifier starting with STD_ for any purpose, since it might be a macro
defined by a standard header. In other words, you've changed from one
name space being reserved for all uses, to a different one. What's the
advantage? It would have to be a pretty hefty one, to justify breaking
all the existing standard library headers and user code that rely on the
current reserved name space.
...
> 5. The preprocessor does not need to differentiate between library
> implementors and users when enforcing this rule.
It needn't do that now. Implementations aren't required to enforce the
rule. Using a name in a context where it's reserved merely allows
undefined behavior; the implementation isn't required to diagnose
violations. Typical undefined behavior is that the user's definition
interferes with the validity or correct behavior of the implementation's
definition, or vice versa.
James Kuyper
...
> I got another idea, then.
Sounds like a good idea; in fact, it's such a good idea that it was
invented a decade or so ago, and put into the C standard, and then
inherited by the C++ standard. However, the people who had that idea
before you choose the prefixes '_A' through '_Z' and '__' for that
purpose, rather than '__STD'. Can you suggest any advantage to changing
the prefixes, which is sufficient to justify requiring a re-write of
most existing standard headers?
...
> 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?)
Yes - what you're doing in effect is telling them that their currently
reserved name space is too big, and they need to re-write all of their
headers to use a smaller name space, which in turn will require using
longer names.
Al Stevens
>instead.
Given the existing rules, so would I. Given a better rule, I might not.
Al Stevens
>You said "C++ has better alternatives to all the known uses of #define".
>What's the alternative that covers this use?
What I said was "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?" Please don't quote me out of context. I also
added, "Not that I'm sold on that notion, of course...", so I don't feel
particularly compelled to defend it.
Marc Lepage
>
> Al Stevens wrote:
> >
> > >What about include guards for header files?
> >
> > #ifndef STD_CSTDIO_H
> > #define STD_CSTDIO_H
> >
> > // ......
> >
> > #endif
> >
> > What about them?
>
> What's the alternative that covers this use?
This entire issue is hashed out in GotW #32.
"Preprocess Macros. With all the type-safe features in C++, why would you ever
use #define?"
--
Marc Lepage
Software Developer
Molecular Mining Corporation
http://www.molecularmining.com/
Al Stevens
>names in libraries from macros.
Yes there is. By conventioin, prefix those names with underscores and
protect them within namespaces; and have the compiler prohibit the use of
underscore-prefixed macro names.
>A second consideration is that compiler implementors of the Standard
>Library often need ways of controlling their header files to handle such
>problems as sharing with C compilers, providing system headers that are
>required by other standards though they share a header name etc.
Well, they don't really *need* that. Nothing says <cstdio> and <stdio.h> or
printf and std::printf have to be joined at the hip other than as a
convenience.
Al Stevens
>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>
As they can any other symbol the implementation chooses, rule or no rule (as
things are now).
[ 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 ]
David R Tribble
Tim Ottinger wrote:
>
> hsu...@peerdirect.com (Herb Sutter) wrote:
>> How would denying some names to all people help protect against
>> collisions between implementer- and user-defined names?
>> reasonable would be to partition names unequivocally between
>> implementers and users, for example by adopting for macros the same
>> rules as for global names:
>
> And more reasonable yet is to avoid warts altogether in favor of
> namespaces, which do the same job even better. I would rather see
> something like MFC::int64 than _int64, just from a point of view of
> information content.
>
> With namespaces, why do we even want an underscore rule.
>
> My personal agenda would be heavy-handed, because I'd require
> identifiers not to start with underbars at all, though this would
> break lots of existing code. But there's not much sense in it anymore.
> We have a *real* programming language now.
If you believe that namespaces really do eliminate the need for
reserved identifiers, then you should believe that any name invented
by users or implementors is valid, having underscores or not.
In other words, if namespaces really do solve all the name collision
problems, then it shouldn't matter whether your names begin with
underscores or not.
Unfortunately, namespaces, by themselvs, do not solve all of the
name collision problems. Especially for implementors attempting
to write library headers for multiple platforms.
-- David R. Tribble, da...@tribble.com, http://david.tribble.com --
James Kuyper Jr.
> >What's the alternative that covers this use?
>
> C++ has better alternatives to all the known uses of #define and wouldn't
> they avoid such macros anyway?" Please don't quote me out of context. I also
> added, "Not that I'm sold on that notion, of course...", so I don't feel
> particularly compelled to defend it.
Sorry, I missed that statement; it blended into your sig. However, you
also said "Perhaps that usage should not be permitted.", referring to
the use by implementations of macros with names from the reserved name
space. It's hard to justify prohibiting such use, unless there are
better alternatives to every use of #define. Such a prohibition would
mandate the use of those alternatives.
Hendrik Schober
James Kuyper <kuy...@wizard.net> wrote:
> [...]
> True - for example, the convention could be that the names must start
> with STD_. This would, of course, require that user code not use any
> identifier starting with STD_ for any purpose, since it might be a macro
> defined by a standard header. In other words, you've changed from one
> name space being reserved for all uses, to a different one. What's the
> advantage?
You shrink the implementor's namespace and expand the user's namespace.
> It would have to be a pretty hefty one, to justify breaking
> all the existing standard library headers and user code that rely on the
> current reserved name space.
It seems fairly easy to me to change existing headers using a tool.
Use '__STD_' instead of 'STD_' and no user code would break.
> [...]
Schobi
Al Stevens
Stan Brown wrote in message ...
>Nine do in C, and nine do in C++. (Eight of the nine are the same.)
Why, yes they do. CRS strikes again. Of course they have those names because
of the existing rule. Under a different (better) rule that was not bound to
tradition and legacies, they would have other names. Some of them might not
be macros.
James Kuyper
Hendrik Schober wrote:
>
> James Kuyper <kuy...@wizard.net> wrote:
> > [...]
> > True - for example, the convention could be that the names must start
> > with STD_. This would, of course, require that user code not use any
> > identifier starting with STD_ for any purpose, since it might be a macro
> > defined by a standard header. In other words, you've changed from one
> > name space being reserved for all uses, to a different one. What's the
> > advantage?
>
> You shrink the implementor's namespace and expand the user's namespace.
Is there really any significant need for that?
> > It would have to be a pretty hefty one, to justify breaking
> > all the existing standard library headers and user code that rely on the
> > current reserved name space.
>
> It seems fairly easy to me to change existing headers using a tool.
> Use '__STD_' instead of 'STD_' and no user code would break.
Changes which can be dealt with using automated tools are, of course,
better than ones that can't, but it's still a fairly significant cost,
for neglible benefit. Keep in mind that all kinds of documentation would
have to be updated to match the code, and that these changes would have
to be made to essentially every single piece of code implementing the
C++ standard library on virtually every platform world-wide. It would
also open up an incompatibility between the C and C++ standard
libraries, and between newer and older versions of the C++ library.
Francis Glassborow
In article <383B318F...@tribble.com>, David R Tribble
<da...@tribble.com> writes
>Unfortunately, namespaces, by themselvs, do not solve all of the
>name collision problems.
Not least because namespace names can collide:)
>
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
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Hendrik Schober
> Sounds like a good idea; in fact, it's such a good idea that it was
> invented a decade or so ago, and put into the C standard, and then
> inherited by the C++ standard. However, the people who had that idea
> before you choose the prefixes '_A' through '_Z' and '__' for that
> purpose, rather than '__STD'. Can you suggest any advantage to changing
> the prefixes,
You describe it yourself (see below): It shrinks their namespace and
expands mine. Nice for me. Harder for them.
> which is sufficient to justify requiring a re-write of
> most existing standard headers?
I don't feel like I know enough about this to decide what's "sufficient".
> > 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?)
>
> Yes - what you're doing in effect is telling them that their currently
> reserved name space is too big, and they need to re-write all of their
> headers to use a smaller name space, which in turn will require using
> longer names.
To me it's not that hard of a task to write a tool that scans all
the header files for #include guards and replaces them using the
simple scheme you laid out yourself (see top of article).
James Kuyper Jr.
....
> This entire issue is hashed out in GotW #32.
>
> "Preprocess Macros. With all the type-safe features in C++, why would you ever
> use #define?"
And how do I dereference this pointer? I looked in the GotW archives,
and 32 is so old that it's no longer being retained, there's just a
reference to a book I could buy. I searched for it in DejaNews, but
couldn't find any message for any GotW below 50.
Al Stevens
>name space being reserved for all uses, to a different one. What's the
>advantage?
The preprocessor can enforce the rule. The objective would be to define a
class of identifiers that cannot also be macro names to prevent the
collisions since macros do not respect namespaces. All of which assumes
macros have value and we need to keep the preprocessor, which I believe. I
already acknowledged that something would need to be done about header
protectors. If one complains that I haven't tried to solve that particular
problem in this discussion, I agree. If one insists such discussions also
address all the collateral issues it raises, then I'll simply say that since
the header protection idiom is virtually universal, the preprocessor could
have a specific directive to support it or specific different behavior for
multiply included headers (a la D&E pp 425) and leave the details for
another time.
>It needn't do that now. Implementations aren't required to enforce the
>rule.
You say that as if it was a good thing.
You seem to be arguing in favor of the status quo. I am not arguing against
it or suggesting that anything be changed now. When I asked why, with
namespaces, we required the underscore rule, the answer given was we need to
discourage user macros from colliding with standard names, which I accept.
(The only flaw in that argument is that we keep calling it a "rule." Since
it cannot be enforced with a diagnostic, it is more like a convention with
which the standard strongly urges compliance, its wording notwithstanding.)
I suggested an alternative approach to the underscore rule/convention that
would have worked--better, in my opinion--had it been chosen. Someone asked
how it could have worked. Realizing that its advantages were deceptively
opaque, I explained how. I also acknowledged that it is probably too late to
consider something like that. Simply asserting that the approach does not
work on its own merits would not invalidate the approach unless one also
substantially discredited those merits. Saying, however, that the approach
would inconvenience a large body of existing implementations agrees with my
assumption that the time has passed for this language to consider such
alternatives. That does not diminish the benefit of such academic
discussions, though,
Francis Glassborow
<mle...@molecularmining.com> writes
>"Preprocess Macros. With all the type-safe features in C++, why would you ever
>use #define?"
Because of shared libraries between C and C++ ?
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
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
James Kuyper
>
> >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>
>
> As they can any other symbol the implementation chooses, rule or no rule (as
> things are now).
Yes, and code which breaks the rules is allowed to have undefined
behavior, so such code is not a problem. That's the very reason why
breaking those rules has been specified as allowing undefined behavior.
Only code that obeys the rules is relevant for evaluating the
conformance of an implementation. An implentation that #defines
STD_CSTDIO_H can cause problems even for code which obeys the rules, and
that would make such an implementation non-conforming.
Conforming implementations currently avoid such problems when #defining
macros in standard headers, by using names from the name space reserved
to the implementation for all uses. A conforming implementation can do
this, since legal user code does not use identifiers with such names.
You've suggested, with regard to implementations #defining macros with
such names: "Perhaps that usage should not be permitted." If it's not to
be permitted, how could a conforming implementation implement include
guards for standard headers without breaking legal user code?
---
Pete Becker
>
> >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>
>
> As they can any other symbol the implementation chooses, rule or no rule (as
> things are now).
>
No. That's the point: include guards for standard headers should begin
with an underscore followed by an uppercase letter, or with two
underscores. Those names are reserved to the implementor. Any user code
that contains identifiers like that is illegal.
#define __STD_CSTDIO_H
#include <cstdio>
If this doens't work, it's the user's fault for using an identifier
that's reserved to the implementor. Granted, the compiler can't detect
this, but in practice this is not a problem. Just don't do it.
--
Pete Becker
Dinkumware, Ltd.
http://www.dinkumware.com
Al Stevens
>such names: "Perhaps that usage should not be permitted." If it's not to
>be permitted, how could a conforming implementation implement include
>guards for standard headers without breaking legal user code?
I answered that question in another message.
[ 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
>with an underscore followed by an uppercase letter, or with two
>underscores. Those names are reserved to the implementor. Any user code
>that contains identifiers like that is illegal.
>
>#define __STD_CSTDIO_H
>#include <cstdio>
You misunderstand. The discussion isn't about how it is but how it might
have been. "Of all sad words of tongue and pen, the saddest are these..." Or
something like that.
Herb Sutter
On 24 Nov 1999 00:27:46 -0500, Marc Lepage <mle...@molecularmining.com>
wrote:
>This entire issue is hashed out in GotW #32.
>
>use #define?"
Thanks for the reference.
The URL is www.peerdirect.com/resources/gotw032a.html.
Herb
---
Herb Sutter (mailto:hsu...@peerdirect.com)
PeerDirect Inc. 2655 North Sheridan Way, Suite 130
www.peerdirect.com Mississauga Ontario Canada L5K 2P8
John Potter
: Marc Lepage wrote:
: ....
: > This entire issue is hashed out in GotW #32.
: >
: > "Preprocess Macros. With all the type-safe features in C++, why would you ever
: > use #define?"
:
: And how do I dereference this pointer? I looked in the GotW archives,
: and 32 is so old that it's no longer being retained, there's just a
: reference to a book I could buy. I searched for it in DejaNews, but
: couldn't find any message for any GotW below 50.
Deja.com.
Select power search
subject: 32
forum: comp.lang.c++.moderated
dates: jan 1 1995 <blank>
If you want old stuff, you need to specify it. 44 matches.
John
---
Stan Brown
follow up in the newsgroup.]
kuy...@wizard.net (James Kuyper Jr.) wrote in comp.std.c++:
>Marc Lepage wrote:
>....
>> This entire issue is hashed out in GotW #32.
>> "Preprocess Macros. With all the type-safe features in C++, why would
>> you ever use #define?"
>
>And how do I dereference this pointer? I looked in the GotW archives,
>and 32 is so old that it's no longer being retained, there's just a
>reference to a book I could buy. I searched for it in DejaNews, but
>couldn't find any message for any GotW below 50.
http://216.149.30.162/resources/
Click on "#32", which is
http://216.149.30.162/resources/gotw032.html
Click on "Solution", which is
http://216.149.30.162/resources/gotw032a.html
What I found there doesn't look incomplete to me.
--
Stan Brown, Oak Road Systems, Cleveland, Ohio, USA
http://www.mindspring.com/~brahms/
C++ FAQ Lite: http://www.cerfnet.com/~mpcline/c++-faq-lite/
the C++ standard: http://webstore.ansi.org/ansidocstore/default.asp
more FAQs: http://www.mindspring.com/~brahms/faqget.htm
Herb Sutter
>and 32 is so old that it's no longer being retained, there's just a
>reference to a book I could buy.
Try www.peerdirect.com/resources/gotw032a.html. Since GotW #31-40 were
held over and are not in XC++, I've restored those solutions until MXC++
comes out in a year or two.
>I searched for it in DejaNews, but
>couldn't find any message for any GotW below 50.
Is it just me, or is Deja harder to search than before? You may need to
specify a date range explicitly to get beyond the "recent" archive...
maybe that's the problem.
{ That's it. Set the start date in power search. -mod/jep }
Herb
---
Herb Sutter (mailto:hsu...@peerdirect.com)
CTO, PeerDirect Inc. (http://www.peerdirect.com)
Chair, SCC CAC / ISO WG21 (SCC C++ standards committee)
Founding moderator, clc++m (news:comp.lang.c++.moderated)
[ 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
Al Stevens wrote:
>
> >No. That's the point: include guards for standard headers should begin
> >with an underscore followed by an uppercase letter, or with two
> >underscores. Those names are reserved to the implementor. Any user code
> >that contains identifiers like that is illegal.
> >
> >#define __STD_CSTDIO_H
> >#include <cstdio>
>
> You misunderstand. The discussion isn't about how it is but how it might
> have been. "Of all sad words of tongue and pen, the saddest are these..." Or
> something like that.
>
Yup, I finally figured that out. Of course, if we insisted on perfect
designs we'd spend all of our time designing and never finish any
products.
--
Pete Becker
Dinkumware, Ltd.
http://www.dinkumware.com
James Kuyper Jr.
> > Yes - what you're doing in effect is telling them that their currently
> > reserved name space is too big, and they need to re-write all of their
> > headers to use a smaller name space, which in turn will require using
> > longer names.
>
> To me it's not that hard of a task to write a tool that scans all
> the header files for #include guards and replaces them using the
> simple scheme you laid out yourself (see top of article).
Yes, but why make them do this? I don't see any benefit sufficient to
justify the effort.
It's not as if there was any significant shortage of names reserved to
users.
Al Stevens
>It's not as if there was any significant shortage of names reserved to
>users.
That's an oversimplification of the problem that namespaces and the
underscore rule address. Users can always change names when collisions
occur. It's when users try to integrate libraries and the users cannot
change the libraries' names that collisions represent a problem.
The underscore rule, if everyone chooses to observe it, looks out for the
standard library but offers little to protect the names of other libraries
from colliding macros defined by anybody--users or other libraries. All that
(other than standard) library implementers can do is use the single
underscore for names in their own namespace and hope that
everyone--including the standard library implementer--obeys the rule about
putting single underscore prefixed names in the global namespace. A
preprocessor-enforced rule that prohibits macros from beginning with
underscores, with, I suppose, an exception provided for those nine macros
that are already specified in the standard and with special provision for
header protectors, would change that hope to an assurance. Academically
speaking, of course. Nobody wants to break a lot of legacy code.
James Kuyper Jr.
Al Stevens wrote:
>
> >It's not as if there was any significant shortage of names reserved to
> >users.
>
> That's an oversimplification of the problem that namespaces and the
> underscore rule address. Users can always change names when collisions
> occur. It's when users try to integrate libraries and the users cannot
> change the libraries' names that collisions represent a problem.
>
> The underscore rule, if everyone chooses to observe it, looks out for the
> standard library but offers little to protect the names of other libraries
> from colliding macros defined by anybody--users or other libraries. All that
The standard is a contract governing the interaction between user code
and the implementations code. From the standard's point of view, writers
of libraries are users, indistinguishable from other users. When
different users cooperate (as for instance when an end user links to a
third-party library), deciding how they divide up the name space
reserved to users between them is necessarily covered by a different
contract. Namespaces, and especially namespace aliases, have made that
division easier, but I don't see any hope of making it trouble free.
I certainly don't see an advantage to shrinking the namespace assigned
to implementations.
The suggestions I've seen would add about 5 characters to the length of
typical implementation-defined macros, making the implementation's code
correspondingly less readable and harder to maintain. A small effect, to
be sure; but infinitely greater than any benefit I've seen suggested for
the change.
[ 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 ]
AllanW
In article <_Qo_3.595$F7.3...@newscene.newscene.com>,
"Al Stevens" <alst...@midifitz.com> wrote:
> James Kuyper wrote in message <383997D3...@wizard.net>...
> >You said "C++ has better alternatives to all the known uses
> >of #define". What's the alternative that covers this use?
>
> What I said was "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?"
> Please don't quote me out of context.
*ALL* quotes are out of context. Even if the entire article is
quoted, it's still not identically the same context as the
original quote. Naturally, the person doing the quoting bears
a responsibility to make the new context a true and fair
reminder of the original context, but doing this requires the
quoter to understand the original poster's intent.
I read both the original text (in it's original context) and
Mr. Kuyper's quote (in the revised context) and my FIRST
impression agreed with Mr. Kuyper's apparent understanding.
(After reading your rebuttal, I now realize that both of us
were mistaken.) This probably means that I misunderstood you
in exactly the same way that Mr. Kuyper did. My point is that
more than one reasonable person might have read what you wrote
and come away with the impression that Mr. Kuyper had. So,
unless you believed (and still believe) that Mr. Kuyper
deliberately misread what you wrote for the purpose of flaming
you, I would say that you overreacted.
> I also added, "Not that I'm sold on that notion, of course...",
> so I don't feel particularly compelled to defend it.
--
All...@my-deja.com is a "Spam Magnet," never read.
Please reply in newsgroups only, sorry.
Sent via Deja.com http://www.deja.com/
Before you buy.
AllanW
In article <PRo_3.597$F7.4...@newscene.newscene.com>,
"Al Stevens" <alst...@midifitz.com> wrote:
> >I would expect a standard library implementor to use
> > __STD_CSTDIO_H instead.
>
> Given the existing rules, so would I. Given a better rule,
> I might not.
What would make the rules better?
The existing rules reserve the name STD_CSTDIO_H for the
application developer, and they also reserve the name
__STD_CSTDIO_H for the implementation, including the
library. What's the problem that you think needs fixing?
Perhaps you think that the name without the leading
underscores is somehow "prettier" and therefore a library
author might wish to use it for internal purposes?
Remember that:
* Names used for include guards are not intended to be
used anywhere in the code except at the beginning of
the header files (and possibly at the end, in comments).
Therefore, there is little value in making it "pretty."
This might even be counter-productive, since it improves
the odds of collisions with names in application code.
* The library is re-used, and hopefully requires less
development time than the thousands (millions?) of
applications that use it.
* One goal of standardization (albeit a minor one) is
to make the language easier for "intermediate level"
programmers. These programmers might not even know
what a "name space" is. (I'm using the general term,
not the c++ namespace{} concept.) To say it another
way, even if they have naming standards they might
not recognize that some of it stems from requirements
of the programming language. Implementors are assumed
to be at a higher level, and they must (almost by
definition) refer to the standard frequently. Being
unaware of name requirements is not feasable.
Hendrik Schober
David R Tribble <da...@tribble.com> wrote:
> [...] 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.
> [...]
Well, if I rethink this...
There's my Compiler vendor which also provides a library.
In this there's a lot of underscored names (beside those which
belong to the std lib).
Are they breaking a rule, then? Shouldn't they use such identifiers?
How does this match with the rule, that provider specific language
extending key words should start with underscores?
Seems strange to me.
Schobi
James Kuyper Jr.
>
> >In other words, you've changed from one
> >name space being reserved for all uses, to a different one. What's the
> >advantage?
>
> The preprocessor can enforce the rule. The objective would be to define a
> class of identifiers that cannot also be macro names to prevent the
> collisions since macros do not respect namespaces. All of which assumes
> macros have value and we need to keep the preprocessor, which I believe. I
> already acknowledged that something would need to be done about header
> protectors. If one complains that I haven't tried to solve that particular
Yes - and any fix that comes close to being backward compatible will
involve defining some kind of reserved name space. Names in that name
space will present exactly the same enforceability problems as the
current reserved name space.
[Re: detecting illegal use of reserved names]
> >It needn't do that now. Implementations aren't required to enforce the
> >rule.
>
> You say that as if it was a good thing.
Yes - you're missing the point of the reservation. It was intended to
allow implementations to use symbols in standard headers without
worrying about them conflicting with user code, and vice versa. It
wasn't intended to require implementors to distinguish such symbols;
that's a whole lot more work. Like many problems, it's lot easier to
avoid than to automatically detect.
Distinguishing code #included from standard headers from user code is
feasible, but carries a cost. Basically, every instance of an identifier
would have to be tagged somehow to indicate it's source during phase 4,
and must retain that tag until sufficiently far into phase 7 to identify
whether or not it was used in a reserved context. The standard shouldn't
prohibit compilers that don't want to pay that cost.
James Kuyper Jr.
>
> [This followup was also e-mailed to the cited author for speed -- please
> follow up in the newsgroup.]
>
> kuy...@wizard.net (James Kuyper Jr.) wrote in comp.std.c++:
> >Marc Lepage wrote:
> >....
> >> This entire issue is hashed out in GotW #32.
> >> "Preprocess Macros. With all the type-safe features in C++, why would
> >> you ever use #define?"
> >
> >and 32 is so old that it's no longer being retained, there's just a
> >couldn't find any message for any GotW below 50.
>
> Click on "#32", which is
> http://216.149.30.162/resources/gotw032.html
> Click on "Solution", which is
> http://216.149.30.162/resources/gotw032a.html
>
> What I found there doesn't look incomplete to me.
Thanks. I don't remember exactly how I searched before, but it didn't
bring me to that page.
Getting back to my original point: that article confirms, as I
suggested, that include guards are one of several areas where C++ does
not currently have an alternative to pre-processor macros.
Darin Adler
> The underscore rule, if everyone chooses to observe it, looks out for the
> standard library but offers little to protect the names of other libraries
> from colliding macros defined by anybody--users or other libraries. All that
> (other than standard) library implementers can do is use the single
> underscore for names in their own namespace and hope that
> everyone--including the standard library implementer--obeys the rule about
> putting single underscore prefixed names in the global namespace.
For libraries other than the standard library, I recommend the rule of
naming all macros with all capital letters, and defining all other
identifiers with at least one lower-case letter. I recommend the same rule
for end-user code.
I recommend leaving the leading underscore to the standard library and
compiler.
-- Darin
---
David R Tribble
> 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.
That would preclude, or at least make it very risky, for implementors
to provide extensions (e.g., Microsoft's __declspec and __cdecl,
gcc's __restrict and __builtin_return, etc.) that fall quite nicely
into the current reserved namespace.
class Symbol
{
private:
static int __cdecl; // Declaration counter
...
};
Not all lexical names are identifiers.
-- David R. Tribble, da...@tribble.com, http://david.tribble.com --
AllanW
"Al Stevens" <alst...@midifitz.com> wrote:
>
> >It's not as if there was any significant shortage of names
> >reserved to users.
>
> That's an oversimplification of the problem that namespaces
> and the underscore rule address. Users can always change names
> when collisions occur. It's when users try to integrate
> libraries and the users cannot change the libraries' names
> that collisions represent a problem.
Aha! Now you finally begin to hint at the answer to the
question, "Why?"
Have you had a library collision? I have. For compile-time
collisions (such as preprocessors), there's an awkward but
workable solution: each source module in application code
can use either ONE of the two libraries, but not both.
This often forces the application programmer to create
"forwarding functions." Link collisions are not nearly
as easy to deal with, and sometimes impossible.
> The underscore rule, if everyone chooses to observe it, looks
> out for the standard library but offers little to protect the
> names of other libraries from colliding macros defined by
> anybody--users or other libraries. All that (other than
> standard) library implementers can do is use the single
> underscore for names in their own namespace and hope that
> everyone--including the standard library implementer--obeys
> the rule about putting single underscore prefixed names in
> the global namespace.
But this still doesn't solve the problem, does it? There's
nothing that forces ABC and DEF to avoid functions named func().
Namespaces will eventually make this type of thing very very
rare, but only if you have the latest versions and are willing
to adapt your code to use it.
> A preprocessor-enforced rule that prohibits macros from
> beginning with underscores, with, I suppose, an exception
> provided for those nine macros that are already specified
> in the standard and with special provision for header
> protectors, would change that hope to an assurance.
I don't see how. If we prevent the preprocessor from accepting
the name _FUNC, then the library will simply have to use FUNC.
This neither helps nor hinders the logical rename to something
like ABC_FUNC. In fact, it seems to me that it would force the
compiler to reject BOTH libraries, so that neither one would
work even if the other one wasn't used!
> Academically speaking, of course. Nobody wants to break a
> lot of legacy code.
Please focus on the problem that you REALLY want to fix. Explain
the problem in reasonable detail. Give examples of real libraries
with these problems, but don't assume we're familiar with them;
tell us some of the conflicting names. Then explain how this new
rule would fix it.
--
All...@my-deja.com is a "Spam Magnet," never read.
Please reply in newsgroups only, sorry.
Sent via Deja.com http://www.deja.com/
Before you buy.