sirwillard@my-dejanews.com writes:

>In article <7brv5m$3fu$1@engnews1.eng.sun.com>,
>  Stephen.Clamage@sun.com (Steve Clamage) wrote:
>>
>> AllanW@my-dejanews.com writes:
>>
>> >I would expect that additional symbols could be put into vendor-private
>> >namespaces. There are two obvious ways to do that.
>>
>> >The first would be to use namespaces other than std which are
>> >reserved for the implementor. Many of us will assume that namespaces
>> >which begin with an underscore or contain two underscores are
>> >reserved for the implementor. However, when I went to look this up,
>> >I could not find any such comment.
>>
>> 17.4.3.1.2 says that
>> - every name that contains a double underscore or begins with an
>>   underscore and an uppercase letter is reserved to the
>>   implementation for any use.
>> - every name that begins with an underscore is reserved to the
>>   implementation for use as a name in the global namespace and
>>   in namespace std.
>>
>> An implemenation can therefore safely create a special namespace
>> with any name beginning with an underscore, or that contains
>> a double underscore.

>Read the first part again more carefully.  Names beginning with an underscore
>followed by an uppercase letter or containing double underscores is reserved
>_for any use_. This is not restricted to namespaces and may include macros.
>It's the macros which could give you problems, even within your own
>namespaces.

I believe the discussion was about namespaces a C++ implementer
(vendor) could create without stepping on the names a compiler
client was entitled to use. That was the question I answered.

The implementation is presumably in control of itself. It can
choose to use the names in question for any use -- macro names
or namespace names in particular. Implementation clients, including
third-party library suppliers, are not allowed to use those names.

Any name collisions would be the result of carelessness on the
part of the C++ implementer, or inappropriate use of reserved
names by clients.

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

In article <8JfC2.4098$F63.8401@newscene.newscene.com>,
  "Al Stevens" <alstevens@midifitz.com> wrote:
> Style and propriety aside, you should be able to safely use the underscore
> prefix for data members because members are in the class's namespace and
> collisions are unlikely. However, the compiler vendor might have used your
> member identifier as a macro. You would usually get some kind of diagnostic,
> but sometimes you would not. The preprocessor strikes again.

True. But it's not that hard to live within this rule.

> The standard says what we programmers should do--avoid underscore/underscore
> and underscore/uppercase--but I do not find where it tells the compiler
> vendor that they absolutely must use the underscore/underscore or
> underscore/uppercase prefix for identifiers that are not a part of the
> published interface but that are declared in namespaces that are normally
> visible to the using program. This is an interesting anomaly in view of the
> first sentence of the document: "This International Standard specifies
> requirements for processors of the C++ programming language." Perhaps the
> absense of such a requirement reflects a desire to avoid breaking existing
> code although I don't see why. Virtually every standard library is
> necessarily a new development which can be made to adhere to the new rules.

The second sentence covers this. "The first such requirement is that
they implement the language, and so this International Standard also
defines C++." By my interpretation of "implement the language," I
believe that the compiler must correctly translate valid C++ source
code into a program that executes correctly.

Now consider a hypothetical compiler that pollutes namespace std with
symbols that do not start with an underscore. It will fail to compile
correct C++ programs which happen to include the
    using namespace std;
directive and also happen to declare those same symbols in global
namespace.

Such a compiler would be non-conforming.

> The document says the notation is reserved for C++ implementations and
> standard libraries, but it's really only a guideline because it is not
> enforced. Vendors are permitted to get in our way if they choose to. They
> are also not required to issue a diagnostic if we get in their way and
> violate the rule. This relaxation enables them to compile their own library
> header files without needing pragmas to turn off warnings.

I would expect that additional symbols could be put into vendor-private
namespaces. There are two obvious ways to do that.

The first would be to use namespaces other than std which are
reserved for the implementor. Many of us will assume that namespaces
which begin with an underscore or contain two underscores are
reserved for the implementor. However, when I went to look this up,
I could not find any such comment.

    Are any namespace names reserved for the implementor?

The second would be to use namespaces that are nested within std.

    namespace std {
      namespace ldmath {
        long double sin(long double);
        long double cos(long double);
        long double tan(long double);
        // ...
      }
    }

Users are not supposed to declare anything in namespace std. And
yet, the declaration
    using namespace std;
will not bring the long-double versions of sin, cos, etc. into
scope. To do that, the user would have to add
    using namespace std::ldmath;
which could hardly be an accident.

----
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

AllanW@my-dejanews.com writes:

>I would expect that additional symbols could be put into vendor-private
>namespaces. There are two obvious ways to do that.

>The first would be to use namespaces other than std which are
>reserved for the implementor. Many of us will assume that namespaces
>which begin with an underscore or contain two underscores are
>reserved for the implementor. However, when I went to look this up,
>I could not find any such comment.

17.4.3.1.2 says that
- every name that contains a double underscore or begins with an
  underscore and an uppercase letter is reserved to the
  implementation for any use.
- every name that begins with an underscore is reserved to the
  implementation for use as a name in the global namespace and
  in namespace std.

An implemenation can therefore safely create a special namespace
with any name beginning with an underscore, or that contains
a double underscore.

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


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

In article <7brv5m$3fu$1@engnews1.eng.sun.com>,
  Stephen.Clamage@sun.com (Steve Clamage) wrote:
>
> AllanW@my-dejanews.com writes:
>
> >I would expect that additional symbols could be put into vendor-private
> >namespaces. There are two obvious ways to do that.
>
> >The first would be to use namespaces other than std which are
> >reserved for the implementor. Many of us will assume that namespaces
> >which begin with an underscore or contain two underscores are
> >reserved for the implementor. However, when I went to look this up,
> >I could not find any such comment.
>
> 17.4.3.1.2 says that
> - every name that contains a double underscore or begins with an
>   underscore and an uppercase letter is reserved to the
>   implementation for any use.
> - every name that begins with an underscore is reserved to the
>   implementation for use as a name in the global namespace and
>   in namespace std.
>
> An implemenation can therefore safely create a special namespace
> with any name beginning with an underscore, or that contains
> a double underscore.

Read the first part again more carefully.  Names beginning with an underscore
followed by an uppercase letter or containing double underscores is reserved
_for any use_. This is not restricted to namespaces and may include macros.
It's the macros which could give you problems, even within your own
namespaces.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own


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

Style and propriety aside, you should be able to safely use the underscore
prefix for data members because members are in the class's namespace and
collisions are unlikely. However, the compiler vendor might have used your
member identifier as a macro. You would usually get some kind of diagnostic,
but sometimes you would not. The preprocessor strikes again.

The standard says what we programmers should do--avoid underscore/underscore
and underscore/uppercase--but I do not find where it tells the compiler
vendor that they absolutely must use the underscore/underscore or
underscore/uppercase prefix for identifiers that are not a part of the
published interface but that are declared in namespaces that are normally
visible to the using program. This is an interesting anomaly in view of the
first sentence of the document: "This International Standard specifies
requirements for processors of the C++ programming language." Perhaps the
absense of such a requirement reflects a desire to avoid breaking existing
code although I don't see why. Virtually every standard library is
necessarily a new development which can be made to adhere to the new rules.

The document says the notation is reserved for C++ implementations and
standard libraries, but it's really only a guideline because it is not
enforced. Vendors are permitted to get in our way if they choose to. They
are also not required to issue a diagnostic if we get in their way and
violate the rule. This relaxation enables them to compile their own library
header files without needing pragmas to turn off warnings.

 [Moderator's note: Al Stevens also included a paragraph giving his
 personal views on the style question, but I edited that one out,
 since it is not really appropriate for this group.  Comments on
 style issues should go to comp.lang.c++(.moderated), please.
 -moderator (fjh).]

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

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

>The standard says what we programmers should do--avoid underscore/underscore
>and underscore/uppercase--but I do not find where it tells the compiler
>vendor that they absolutely must use the underscore/underscore or
>underscore/uppercase prefix for identifiers that are not a part of the
>published interface but that are declared in namespaces that are normally
>visible to the using program.

The restriction on implementations is implicit. The standard
describes the lexical form of identifiers, and the syntax and
semantics of various uses of identifiers. It describes the sets of
identifiers that are reserved to the implementation, which means
that no others are reserved. The implementation is obligated to
provide the observable behavior of the abstract machine defined by
the standard.

Put all those together, and I don't think an implementation can
claim conformance if it predefines a non-reserved identifier.

For example, the standard says I can write this program
    #include <iostream>
    int main()
    {
        enum { near, far, unix, SYMANTEC };
        std::cout << near << far << unix << SYMANTEC << std::endl;
    }
and expect the output
    0123

If, in the implementation, any of my identifiers were keywords or
predefined macros, the code probably would not have the right
behavior, if it compiled at all.

That said, compilers don't exist in a vacuum, but must work on some
platform. Typically they must also comply with other standards. For
example, POSIX and XOPEN require that additional entities with names
that are not reserved to a C++ implementation appear in some of the
C standard headers. A C++ implementation therefore cannot
simultaneously strictly comply with both C++ and XOPEN.

The usual solution is to have a compiler flag that turns off
everything that does not conform to the standard, used to pass C++
test suites or to ensure portable code, and other flags that allow
you to compile programs (or pass test suites) for the supported
platforms.

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


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

Al Stevens wrote:
...
> The standard says what we programmers should do--avoid underscore/underscore
> and underscore/uppercase--but I do not find where it tells the compiler
> vendor that they absolutely must use the underscore/underscore or
> underscore/uppercase prefix for identifiers that are not a part of the
> published interface but that are declared in namespaces that are normally
> visible to the using program. This is an interesting anomaly in view of the

Conforming programs can freely use any identifier that is not reserved
in the context in which it is used. Conforming implementations must
correctly translate such code (modulo the ridiculously broad
implementation-limits exemption). Therefore, a conforming implementation
would have a hard time using such identifiers. If, by some kind of
compiler magic, it finds a way to do so, then there's no problem.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Stan Brown wrote:
>
> In this next-to-last year of the millennium, Tony+uaa@memwizard.com
> (Tony) wrote in article <7b9fn5$402$1@news.ncal.verio.com> in
> comp.std.c++:
> >I'd like to use a consistent naming convention to distinguish my member
> >variables from local variables. I've been using an underscore as the first
> >character of the name, i.e. _valve3, to indicate that it was a member
> >variable, but page 81 of Stroustrup's C++ Programming Language 3rd Ed. says
> >the following:
> >
> >"Names starting with an underscore are reserved for special facilities in
> >the implementation and the run-time environment, so such names should not be
> >used in application programs."
> >
> >It was my understanding that only names starting with an underscore followed
> >by an uppercase letter were reserved (which isn't a problem because my
> >variables always start with a lowercase letter),
>
> Stroustrup is correct according to subclause 17.4.3.1.2 of the standard.
> (No surprise there! [*]) However, when I asked the very same question a
> few weeks ago, response was that there are compilers that do use
> underscore followed by lower case for their own purposes, so for safety's
> sake you should stay away from it.

The section of the standard you cited says that such names are reserved
to the implementation, in the global namespace. The sentence from
Stroustrup that Tony quoted says that such names are reserved for
sepcial facilities in the implementation and the run-time environment.
The response you got says that some implementations (most, I would
assume) take advantage of the permissions granted by that section. So
why do you say "however"? The word implies that there's some kind of
inconsistency.


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

I'd like to use a consistent naming convention to distinguish my member
variables from local variables. I've been using an underscore as the first
character of the name, i.e. _valve3, to indicate that it was a member
variable, but page 81 of Stroustrup's C++ Programming Language 3rd Ed. says
the following:

"Names starting with an underscore are reserved for special facilities in
the implementation and the run-time environment, so such names should not be
used in application programs."

It was my understanding that only names starting with an underscore followed
by an uppercase letter were reserved (which isn't a problem because my
variables always start with a lowercase letter), so I was surprised to read
this. It may be that the restriction only applies to underscore followed by
uppercase, strictly speaking, but Stroustrup is saying names shouldn't start
with an underscore at all because so many implementations ignore the
upper-/lower-case distinction.

I was looking for a nice alternative. Some people use a trailing underscore,
but that seems too easy to overlook. Others (following Microsoft's lead) use
a leading "m_", as in "m_valve3". That's a little bit "heavyweight" for my
taste.

I realize that this is, of course, just a matter of personal preference, but
I just noticed that Stanley Lippman and Josee Lajoie use my style in their
new edition (3rd) of C++ Primer. These two seem to know their stuff, and it
doesn't seem to bother them to use the leading underscore on all their
member variables.

Most of my experience has been limited to just a couple of compilers, so I
don't have any way of judging the danger. If I use a leading
underscore+lowercase naming convention, am I setting myself up for all kinds
of unportability nightmares, or is it so safe that it's not worth worrying
about?

Also, if there's a good alternative to this naming convention that people
like even better, I'd love to hear it.

Any advice?

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

In article <7b9fn5$402$1@news.ncal.verio.com>, Tony
<Tony+uaa@memwizard.com> writes
>I was looking for a nice alternative. Some people use a trailing underscore,
>but that seems too easy to overlook. Others (following Microsoft's lead) use
>a leading "m_", as in "m_valve3". That's a little bit "heavyweight" for my
>taste.

the trouble from my perspective with all the prepend mechanisms is
exactly that they are obtrusive.  I much prefer appending something.
This may be a matter of style but...  Actually what I would much prefer
would be programming editors that supported colour coded scopes so that
you could see conflicts immediately.

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

Tony wrote:
....
> It was my understanding that only names starting with an underscore followed
> by an uppercase letter were reserved (which isn't a problem because my

There are several different reservations:

17.4.3.1.2:
"Each name that contains a double underscore (_ _) or begins with an
underscore followed by an upper-case letter (2.11) is reserved to the
implementation for any use."

This is the most dangerous one, since it includes macros. You can't
count on any symbol of that type not being #defined in one of the
standard headers.

17.4.3.1.3:
"Each name that begins with an underscore is reserved to the
implementation for use as a name in the global namespace."

You can ignore this for names defined within your own namespace.

"Each name having two consecutive underscores (2.11) is reserved to the
implementation for use as a name with both exterm 'C' and extern 'C++'
linkage"

You can ignore this restriction only for names with some other linkage,
for instance if you're compiler supports a 'fortran' or 'pascal'
linkage.

....
> I was looking for a nice alternative. Some people use a trailing underscore,
> but that seems too easy to overlook. Others (following Microsoft's lead) use
> a leading "m_", as in "m_valve3". That's a little bit "heavyweight" for my
> taste.

I tried that for a while, but I found it clumsy. I haven't come up with
a good alternative yet.

> I realize that this is, of course, just a matter of personal preference, but
> I just noticed that Stanley Lippman and Josee Lajoie use my style in their
> new edition (3rd) of C++ Primer. These two seem to know their stuff, and it
> doesn't seem to bother them to use the leading underscore on all their
> member variables.

There are a lot of texts out there containing defective code such as
"void main()". That doesn't mean it's a good idea.

> Most of my experience has been limited to just a couple of compilers, so I
> don't have any way of judging the danger. If I use a leading
> underscore+lowercase naming convention, am I setting myself up for all kinds
> of unportability nightmares, or is it so safe that it's not worth worrying
> about?

The simpler the name, the more likely it is that it is accidentally the
same as one the implementation's already using. If you insist on taking
the risk, I recommend using long names.


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

In this next-to-last year of the millennium, Tony+uaa@memwizard.com
(Tony) wrote in article <7b9fn5$402$1@news.ncal.verio.com> in
comp.std.c++:
>I'd like to use a consistent naming convention to distinguish my member
>variables from local variables. I've been using an underscore as the first
>character of the name, i.e. _valve3, to indicate that it was a member
>variable, but page 81 of Stroustrup's C++ Programming Language 3rd Ed. says
>the following:
>
>"Names starting with an underscore are reserved for special facilities in
>the implementation and the run-time environment, so such names should not be
>used in application programs."
>
>It was my understanding that only names starting with an underscore followed
>by an uppercase letter were reserved (which isn't a problem because my
>variables always start with a lowercase letter),

Stroustrup is correct according to subclause 17.4.3.1.2 of the standard.
(No surprise there! [*]) However, when I asked the very same question a
few weeks ago, response was that there are compilers that do use
underscore followed by lower case for their own purposes, so for safety's
sake you should stay away from it.

[*] If you're in the global namespace, or ::std, anything with a leading
underscore is reserved.

Also note that double underscore anywhere in an identifier is reserved.

>Also, if there's a good alternative to this naming convention that people
>like even better, I'd love to hear it.

Check dejanews for comp.lang.c++.moderated. This topic has been discussed
quite a lot.

 [Moderator's note: Stan Brown also included some remarks about
 his personal opinion on the matter, but this question is not
 really appropriate for this group, so I edited those out.  We
 have also rejected a few articles by other people for similar
 reasons.  The question immediately above is a programming style
 question, not a standards question, so please post your answers
 to that one to comp.lang.c++.moderated rather than comp.std.c++.
 Thanks.  (P.S. My apologies for not including a notice like
 this one in the original article that started this thread.)
 -moderator (fjh).]

--
Stan Brown, Oak Road Systems, Cleveland, Ohio, USA
                                    http://www.mindspring.com/~brahms/
My reply address is correct as is. The courtesy of providing a correct
reply address is more important to me than time spent deleting spam.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]