Andrew Koenig wrote:

[...]

> Well, I don't know what the situation is for C9X, but for C89, you will
> definitely not eliminate "that problem" by keeping all your identifiers
> shorter than 32 characters.  The reason is that C89 requires a compiler
> to accept only one single program that meets all the length requirements;
> compilers are permitted to reject any other programs they like.

Hmmm... the following program surely meets the requirements:

main(){}

Sure, I didn't define *any* identifiers there except main, but
of course the requirement that no identifier of more than 32
characters was defined is fulfilled. Therefore a compiler with an
*arbitrary* limit is conforming, as it correctly compiles all
program which are below that limit, and if that limit is below
the C89 limit, they all are conforming, and so the demand that
one conforming program can get compiled is satisfied.

Indeed, there's a conforming C compiler which everyone can write.
The resource limits are:

- At most one translation unit
- At most one line per translation unit
- At most 8 characters per line

Since every conforming program must have at least the main function,
and the shortest way to define that is the line above, and every
extra character will exceed the resource limits, the compiler will
be completely conforming.

The implementation of the compiler is easy:
- Read the file
- If the file has more than one line, or the line has more than
  8 characters, write "resource limits exceeded"
- If the line doesn't contain exactly "main(){}" write
  "error in program"
- Otherwise copy a pre-compiled version of the trivial program
  to the output file

Did anyone say that writing compilers is difficult? ;-)

[...]


[ 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 <35B4819A.D6A34B67@physik.tu-muenchen.de>,
Christopher Eltschka  <celtschk@physik.tu-muenchen.de> wrote:

> Andrew Koenig wrote:

> > Well, I don't know what the situation is for C9X, but for C89, you will
> > definitely not eliminate "that problem" by keeping all your identifiers
> > shorter than 32 characters.  The reason is that C89 requires a compiler
> > to accept only one single program that meets all the length requirements;
> > compilers are permitted to reject any other programs they like.

> Hmmm... the following program surely meets the requirements:

> main(){}

I guess that what I said is ambiguous.

C89 has a bunch of capacity requirements, and requires every conforming
implementation to compile one single program that hits all the limits at once.
That is, the requirement is stated in terms of =, not <=.

main(){} does not meet the requirements in that sense, because it is smaller
than the limits.
--
    --Andrew Koenig
      ark@research.att.com
      http://www.research.att.com/info/ark



[ 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              ]

ark@research.att.com (Andrew Koenig) writes:
 >Fergus Henderson <fjh@cs.mu.OZ.AU> wrote:
 >>Andrew Koenig writes:
 >>>Implementations are
 >>>permitted to fail to execute correct programs if the programs exceed the
 >>>implementations' capacity limitations.  The standard does say that.
 >
 >> No, the standard doesn't say that -- it says the following:
 >
 >>  | 1.4 - Implementation compliance [intro.compliance]
 >> ...
 >>  |    -2- Although this International Standard states only requirements on
 >>  |    C++ implementations, those requirements are often easier to understand
 >>  |    if they are phrased as requirements on programs, parts of programs, or
 >>  |    execution of programs. Such requirements have the following meaning:
 >>  |      * If a program contains no violations of the rules in this
 >>  |        International Standard, a conforming implementation shall, within
 >>  |        its resource limits, accept and correctly execute that program.
 >
 >> To the best of my knowledge, the standard does not place any
 >> requirements on implementations with regard to programs that contain no
 >> diagnosable violations of the rules in the standard but which exceed
 >> the resource limits of the implementation.
 >
 >I think we just said the same thing.  Am I missing something?

When I said "the standard doesn't say that", I was referring to the
following statements of yours, which you omitted from the quoted
context:

 >>>>>If a C++ compiler has a limit of
 >>>>>only 20 significant characters for external identifiers, then the
 >>>>>program will fail to compile or link because a capacity limitation
 >>>>>has been exceeded.

 >>>It doesn't say that they are allowed to transmute the programs into
 >>>other programs.  Any implementation that does so is nonconforming.

Regarding the first statement, I don't see any statement in the standard
that such programs will fail to compile or link; they might just do
the wrong thing at runtime.  Regarding the second statement,
the standard doesn't impose any requirements on implementations
regarding such programs; the implementation is free to "transmute
the programs into other programs" if it wants to, just as it is
free to include a builtin mail reader.

--
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3        |     -- the last words of T. S. Garp.
---
[ 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              ]

Andrew Koenig wrote:
>
> In article <35AFB5EE.2781@wizard.net>, James Kuyper  <kuyper@wizard.net> wrote:
> > Andrew Koenig wrote:
>
> > The same requirement exists in C9X, section 5.2.4. I thought that C89
> > was written in terms of "minimum maxima", rather than the "one program"
> > rule? I was annoyed when I found out about the "one program" rule in C9X
> > - I thought it was a watering down of the requirements laid out by C89.
> > You can imagine how I felt when I discovered that C++ didn't even have
> > lower limits of any kind (not even 0!), just "recommended" values.
...
> One reason that C++ does not have any required lower bounds is that,
> believe it or not, some vendors treat lower bounds as upper bounds,
> as a matter of policy.  The idea is this:  If you write a program
> that exceeds the lower bound, that program is not guaranteed to run
> everywhere, so the compiler is doing you a valuable service by
> rejecting it.  I know of one compiler already out there that has such
> a policy, and one of our members said that his company did the same
> thing, and that if we imposed minima, they would enforce them.

I sympathise with that point of view; if the standard did assign lower
limits on the maxima, I would use them wherever possible as upper limits
in my own code. Providing larger limits should be a QoI issue; taking
advantage of higher limits should be a carefully considered decision,
not an accident.

> That was enough to kill that particular discussion right there.
>
> As I said... You tell me what requirements you'd like to have seen,
> and I can probably tell you why the committee considered those
> requirements and decided against adopting them.  That particular
> discussion was amazingly involved.

A minimum value of 1 for any of the limits could not be taken as an
upper bound by anyone seriously planning to sell their implementation,
and it would at least make me feel happier. Inserting the adjective
'positive' in some appropriate place would do the job.


[ 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              ]

Andrew Koenig wrote:
>
> In article <35AF71D7.1CFB@wizard.net>, James Kuyper  <kuyper@wizard.net> wrote:
> > Andrew Koenig wrote:
>
> > > I don't believe it.  I am quite confident that if I write a large enough
> > > program, any C9X compiler will eventually run out of resources and
> > > be unable to compile that program, even if every identifier in the
> > > program is shorter than 32 characters.
>
> > I did specify "that problem"; the problem of exceeding the compiler's
> > maximum length for identifiers.
>
> Well, I don't know what the situation is for C9X, but for C89, you will
> definitely not eliminate "that problem" by keeping all your identifiers
> shorter than 32 characters.  The reason is that C89 requires a compiler
> to accept only one single program that meets all the length requirements;

The same requirement exists in C9X, section 5.2.4. I thought that C89
was written in terms of "minimum maxima", rather than the "one program"
rule? I was annoyed when I found out about the "one program" rule in C9X
- I thought it was a watering down of the requirements laid out by C89.
You can imagine how I felt when I discovered that C++ didn't even have
lower limits of any kind (not even 0!), just "recommended" values.

In any event, C9X section 6.1.2 "Identifiers", paragraph 6 adds the
stronger requirement that:

| The implementation shall treat at least the first 63 characters of an
| internal name (a macro name or an identifier that does not have
| external linkage) as significant. The implementation may further
| restrict the significance of an external name (an identifier that has
| external linkage) to 31 characters. In both external and internal
| names, lower-case and upper-case letters are different. The number of
| significant characters in an identifier is implementation-defined.

In appendix K, section 3.3, the implementation-defined nature of these
limits is restricted to identifiers longer than 63 and 31 characters,
respectively.

Are you sure similar wording didn't exist in the C89 standard?
---
[ 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              ]

ark@research.att.com (Andrew Koenig) writes:

>Fergus Henderson <fjh@cs.mu.OZ.AU> wrote:
>
>> >The statement above is incorrect.  If a C++ compiler has a limit of
>> >only 20 significant characters for external identifiers, then the
>> >program will fail to compile or link because a capacity limitation
>> >has been exceeded.
>
>> I can't find anything in the standard that guarantees that.
>
>You don't have to -- all you have to do is find some place in the
>standard that grants license to do anything else.

The standard specifies what implementations must do; it does not
specify what they must not do.  For example, the standard does
not say that implementations are allowed to make the coffee,
but that doesn't mean that an implementation that makes the coffee
would not be conforming.

>Implementations are
>permitted to fail to execute correct programs if the programs exceed the
>implementations' capacity limitations.  The standard does say that.

No, the standard doesn't say that -- it says the following:

 | 1.4 - Implementation compliance [intro.compliance]
...
 |    -2- Although this International Standard states only requirements on
 |    C++ implementations, those requirements are often easier to understand
 |    if they are phrased as requirements on programs, parts of programs, or
 |    execution of programs. Such requirements have the following meaning:
 |      * If a program contains no violations of the rules in this
 |        International Standard, a conforming implementation shall, within
 |        its resource limits, accept and correctly execute that program.

To the best of my knowledge, the standard does not place any
requirements on implementations with regard to programs that contain no
diagnosable violations of the rules in the standard but which exceed
the resource limits of the implementation.

>> Furthermore, even if the standard did guarantee that, I suspect that
>> there would be implementations that claimed to conform but which did
>> not satisfy that guarantee.  I have had practical experience of a
>> supposedly conforming C implementation which had an implementation
>> limit for a quantity which was fixed at link time but which did not
>> issue any diagnostic when that limit was exceeded.
>
>Indeed, there will always be broken implementations.  So?

So if someone claims that one standard is in some sense better than
another, or is "a substantial improvement" over another, or that one
language is in some sense better than another, then any attempt to
justify such such claims should take into account the likelihood of
broken implementations.

--
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3        |     -- the last words of T. S. Garp.


[ 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 <01bdadce$8d10d240$8a1ec2d0@porky>,
  "P.J. Plauger" <pjp@dinkumware.com> wrote:
> J. Kanze <kanze@gabi-soft.fr> wrote in article
<m390lzpdur.fsf@gabi-soft.fr>...
> > I don't know personally if the C committee had a charter, but they
> > certainly went beyond codifying existing usage -- there were no C
> > compilers implementing prototypes when they were adopted into the
> > standard, for example, and none supporting the # and the ## operators in
> > the preprocessor.
>
> We actually spent much of our first technical meeting, in September 1983,
> drafting what amounts to a charter document. It placed heavy emphasis on
> codifying existing practice and preserving working code. Believe it or not,
> essentially everything we added to Standard C was based on *some* prior
> art, even if it wasn't always widespread.
>
> For example, I had written a commercial C compiler in 1975-76, while at
> Yourdon inc., that let you declare (and check, and coerce) the types of
> function arguments. I believe we also had the early experience with C++
> as an important proof of concept for function prototypes. We also knew
> that token pasting and stringinzing in macro definitions were both useful
> functions, though the actual notation of ## and # were pure invention.
> And so on.

Please don't read more into what I said that what I actually said: I
have very high regard for the C standard, and the work done by the C
standardization committee.  My only point was that there were innovations
with regards to what was then existing practice in C compilers, and that
this was not necessarily bad.

I do think that there is a distinction between innovating by adopting
proven concepts from other languages (C++ for function prototypes), or
developping a new syntax for a feature implemented with a variety of
different syntaxes (token pasting), and blatent invention.

--
James Kanze    +33 (0)1 39 23 84 71    mailto: kanze@gabi-soft.fr
        +49 (0)69 66 45 33 10    mailto: jkanze@otelo.ibmmail.com
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient   e objet --
              -- Beratung in objektorientierter Datenverarbeitung

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum
---
[ 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              ]

Andrew Koenig wrote:
>
> In article <35AA25C4.2781@wizard.net>, James Kuyper  <kuyper@wizard.net> wrote:
>
> > C9x specifies that at least the first 63 characters of an internal
> > identifiers, must be significant, and the first 31 characters on
> > external ones. C++ "does not place a translation limit on significant
> > characters for external identifiers", but recommends a minimum value of
> > 1024 for both limits. Since this is only a recommendation, the actual
> > value could be as low as 1 (or even 0) in conforming implementation, as
> > long as the identifiers in the standard library were treated as special
> > cases.
> > Therefore, your code is actually safer in C than in C++.
>
> This statement is not true.
>
> C requires that the first 63 characters of an internal identifier
> must be significant, and the first 31 characters of an external identifier.
>
> C++ requires that all characters of all identifiers be significant.

Citation please? It's not that I doubt you, it's just that the standard
is so big it's sometimes hard to find things.

>
> Both languages are allowed to reject any program that exceeds
> their capacity limitations, be those limitations reasonable or not.
>
> C therefore offers the hazard that someone might write a program with
> two identifiers that differ in the 65th character, and that one
> implementation might treat those two identifers as the same and
> another one as different.  C++ has no corresponding hazard.
>
> If you still believe that C is safer in this regard than C++,
> can you give an example of a hazard in C++ that is not in C?

If you are correct in your statement above, then the only hazard is that
the program might fail to compile under C++, which is actually an
improvement over executing incorrectly. The problem is that there is
absolutely no way to choose identifiers names short enough to be
guaranteed portable to all C++ implementations. There is a way to do so
with C9X implementations.
---
[ 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              ]

James Kuyper (kuyper@wizard.net) wrote:
: The problem is that there is
: absolutely no way to choose identifiers names short enough to be
: guaranteed portable to all C++ implementations. There is a way to do so
: with C9X implementations.

In the presence of name mangling, this is pretty much impossible to
specify. Unless one wants to specify the maximum number of characters
every possible subcomponent of a mangled name is allowed to produce. I
don't want to see that in the standard.

One could say that the minimum number of significant characters in an
identifier must be supported regardless of the size of the mangled
name. However that defeats the purpose of the whole caveat in the standard
which is to support legacy linkers on certain platforms. (Because the
linker must either be able to deal with the possibly incredibly long
mangled name or have special support for C++ type information associated
with identifiers.)

Bottom line: C++ will exert a lot of pressure for inferior linkers to be
rewritten.

-Z-
---
[ 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              ]

ark@research.att.com (Andrew Koenig) writes:

>David R Tribble  <dtribble@technologist.com> wrote:
>
>> If a C++ compiler has a limit of only 20 significant characters
>> for external identifiers, then the two identifiers above will
>> have the same name as far as the linker is concerned.  The
>> compiler is conforming, since C++ does not mandate a minimum
>> identifier length (it only recommends a minimum).
>
>The statement above is incorrect.  If a C++ compiler has a limit of
>only 20 significant characters for external identifiers, then the
>program will fail to compile or link because a capacity limitation
>has been exceeded.

I can't find anything in the standard that guarantees that.

Furthermore, even if the standard did guarantee that, I suspect that
there would be implementations that claimed to conform but which did
not satisfy that guarantee.  I have had practical experience of a
supposedly conforming C implementation which had an implementation
limit for a quantity which was fixed at link time but which did not
issue any diagnostic when that limit was exceeded.

--
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3        |     -- the last words of T. S. Garp.


[ 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              ]

James Kuyper <kuyper@wizard.net> writes:

> Citation please? It's not that I doubt you, it's just that the standard
> is so big it's sometimes hard to find things.

1.10 [lex.name]/1 says

>> ... All characters are significant.20)

and footnote 20 says

>> 20) On systems in which linkers cannot accept extended characters,
>>     an encoding of the universal=ADcharacter=ADname may be used in
>>     forming valid external identifiers. For example, some otherwise
>>     unused character or sequence of characters may be used to
>>     encode the \u in a universal=ADcharacter=ADname. Extended
>>     characters may produce a long external identifier, but C + +
>>     does not place a translation limit on significant characters
>>     for external identifiers. In C + +, upper=AD and lower=ADcase
>>     letters are considered different for all identifiers, including
>>     external identifiers.

Hope this helps,
Martin
---
[ 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 <35AB787F.2781@wizard.net>,
  James Kuyper <kuyper@wizard.net> wrote:
> Andrew Koenig wrote:
> >
> > In article <35AA25C4.2781@wizard.net>, James Kuyper  <kuyper@wizard.net>
wrote:
> >
> > > C9x specifies that at least the first 63 characters of an internal
> > > identifiers, must be significant, and the first 31 characters on
> > > external ones. C++ "does not place a translation limit on significant
> > > characters for external identifiers", but recommends a minimum value of
> > > 1024 for both limits. Since this is only a recommendation, the actual
> > > value could be as low as 1 (or even 0) in conforming implementation, as
> > > long as the identifiers in the standard library were treated as special
> > > cases.
> > > Therefore, your code is actually safer in C than in C++.
> >
> > This statement is not true.
> >
> > C requires that the first 63 characters of an internal identifier
> > must be significant, and the first 31 characters of an external identifier.
> >
> > C++ requires that all characters of all identifiers be significant.
>
> Citation please? It's not that I doubt you, it's just that the standard
> is so big it's sometimes hard to find things.
>
> >
> > Both languages are allowed to reject any program that exceeds
> > their capacity limitations, be those limitations reasonable or not.
> >
> > C therefore offers the hazard that someone might write a program with
> > two identifiers that differ in the 65th character, and that one
> > implementation might treat those two identifers as the same and
> > another one as different.  C++ has no corresponding hazard.
> >
> > If you still believe that C is safer in this regard than C++,
> > can you give an example of a hazard in C++ that is not in C?
>
> If you are correct in your statement above, then the only hazard is that
> the program might fail to compile under C++, which is actually an
> improvement over executing incorrectly. The problem is that there is
> absolutely no way to choose identifiers names short enough to be
> guaranteed portable to all C++ implementations. There is a way to do so
> with C9X implementations.

There may be no way to do so, in the degenerate case.  Someone on
this thread suggested that compiler vendors could specify that the
longest identifier, other than those specified in the C++ standard,
could be zero characters.  But that is wrong.  I'm certain that
someone here can explain why better than I can, but here's my stab
at it:
    atexit(void (*f)(void))
In order to call atexit(), you must be able to supply the address
of a user-defined function taking no arguments and returning no
value.  In order to define such a function, you have to give it a
name.  That name must have at least one character.

Limiting identifiers to ONE character, OTOH, might be legal.  Still,
I think we all agree that this compiler vendor wouldn't sell more
than two copies -- probably to mommy and daddy...  Nevertheless, it
is at least possible to write productive programs with this.
(Anyone here remember the original Dartmouth BASIC?  No?  Well,
never mind...)  My point is, it IS possible, though draconian,
to choose identifier names short enough to be guaranteed portable
to all C++ implementations.  Of course, you can only have 52
functions plus classes (A-Z and a-z)...

But let's get practical for a moment.  The C++ standard defines
many, many symbols.  I did a quick scan of the November 1996 draft
and found
    bidirectional_iterator_tag   and
    random_access_iterator_tag
which tie for longest at 26 characters each.  This is after a
quick CASUAL scan; there may be longer identifiers somewhere.

I believe that the compiler is allowed to treat these standard
identifiers specially, and that having a 26-character identifier
in the standard library doesn't require the compiler to allow
user-specified identifiers this long.  (It's in the spec somewhere,
but I'm not sure where...)

BUT: Imainge the level of work required to have the tokenizer
detect these special identifiers, labelling them as
builtin-identifiers, similar but distinct from user-identifiers.
Almost every rule for these two identifier types would be the
same, except for the length of the printable symbol, and perhaps
the builtin-identifiers wouldn't have to be defined before first
use.  (After all, if you've already got a special token type for
them, you already know what they are.)

Compare that with the work required to change the maximum
identifier length to 26 or more.  This implies a variable-length
symbol table, so that the identifier "abcdefghijklmnopqrstuvwxyz"
is legal but the identifier "x" doesn't take up too much space.

The work sounds about equal, doesn't it?  And yet the second
version would be vastly more useful to your users
(programmer-friendly, I suppose you could call it).

What I'm saying is that even though compiler vendors can make
two-character identifiers illegal, there is absolutely no reason
for them to do so.  I think that any programmer that assumes that
most C++ compilers will support 26-character identifiers will not
run into any large amount of trouble.  There may be some mutant
system somewhere that she will not be able to support, but that
will be the exception, not the rule.

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum
---
[ 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 wrote:
...
> There may be no way to do so, in the degenerate case.  Someone on
> this thread suggested that compiler vendors could specify that the
> longest identifier, other than those specified in the C++ standard,
> could be zero characters.  But that is wrong.  I'm certain that
> someone here can explain why better than I can, but here's my stab
> at it:
>     atexit(void (*f)(void))
> In order to call atexit(), you must be able to supply the address
> of a user-defined function taking no arguments and returning no
> value.  In order to define such a function, you have to give it a
> name.  That name must have at least one character.

It doesn't say anywhere in the standard that you have to be able to make
a useful call to atexit(); it merely specifies some aspects of what must
happen if such a call is successfully translated.

The C++ standard specifies a large number of numerical limits, along
with recommended values for them, but places few requirements on those
values. In most cases, non-positive values describe an implementation
that would be useless, but which could be technically conforming. I
would appreciate at a minimum a requirement that those limits be
positive.

...
> But let's get practical for a moment.  The C++ standard defines

Sure, an implementation with very small limits would be impractical. The
problem is that there are no hard-and-fast rules that I can use to
quantify it. With C9X code, if I keep all my names shorter than 32
characters, I eliminate all possibility of that problem. With C++, there
is no number that eliminates that problem; the problem simply gets less
and less likely to occur, the shorter the name. Where do I draw the
line? More to the point, why didn't the committee draw the line for me?
---
[ 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 <35AE3E1A.167E@wizard.net>, James Kuyper  <kuyper@wizard.net> wrote:

> Sure, an implementation with very small limits would be impractical. The
> problem is that there are no hard-and-fast rules that I can use to
> quantify it. With C9X code, if I keep all my names shorter than 32
> characters, I eliminate all possibility of that problem.

I don't believe it.  I am quite confident that if I write a large enough
program, any C9X compiler will eventually run out of resources and
be unable to compile that program, even if every identifier in the
program is shorter than 32 characters.
--
    --Andrew Koenig
      ark@research.att.com
      http://www.research.att.com/info/ark



[ 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              ]

Andrew Koenig (ark@research.att.com) wrote:
: This strategy left open the possibility of hash collisions, but we
: never had one reported to us.  Moreover, I can think of strategies
: that would reduce the probability of hash collision to zero, should
: it be necessary to do so.

Is it ok for the compiler/linker combination to "transmute" your
program if the probability is low enough? Perhaps "conforming" isn't a
boolean, but a float between 1.0f and 0.0f :-)

-Z-


[ 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              ]

Andrew Koenig wrote:
>> C requires that the first 63 characters of an internal identifier
>> must be significant, and the first 31 characters of an external
>> identifier.
>> C++ requires that all characters of all identifiers be significant.
>>
>> Both languages are allowed to reject any program that exceeds
>> their capacity limitations, be those limitations reasonable or not.
>>
>> C therefore offers the hazard that someone might write a program
>> with
>> two identifiers that differ in the 65th character, and that one
>> implementation might treat those two identifers as the same and
>> another one as different.  C++ has no corresponding hazard.

James Kuyper wrote:
> If you are correct in your statement above, then the only hazard is
> that
> the program might fail to compile under C++, which is actually an
> improvement over executing incorrectly. The problem is that there is
> absolutely no way to choose identifiers names short enough to be
> guaranteed portable to all C++ implementations. There is a way to do
> so with C9X implementations.

So why not, in addition to the recommendation of 1024 characters,
go ahead and add a requirement in the standard for a reasonable
minimum limit?  Like 31, for example, which already has a precedent
in C89, or 63, which corresponds to C9X?

Why does the standard not have such a minimum requirement?

I believe it was P J Plauger who discussed the rationale behind
requiring a minimum uniqueness length on identifiers some time
ago, during the C89 standardization process.  He felt that stating
that "any length is acceptable" forced compiler writers to choose
large but arbitrary limits that then some clever programmer (or
validation test suite) would attempt to exceed.  He felt, IIRC,
that making a reasonably large minimum as part of the language
spec would do more in the long run to guarantee portability than
attempting to allow "any" (or "every") size.

It's not clear to me if the 1024-character limit refers to the
total length of a qualified name or just the length of an
individual identifier.  Assuming a compiler that allows
identifiers up to 1024 characters and up to 256 levels of
nested class declarations, I could code a program that resulted
in a name of the form:
    namesp::Class::Class::Class::.....::identifier
that was 264,192 characters long (not counting the '::' tokens).

Personally, I feel that 31 characters is enough for me.
Especially now that I have class name scopes and namespaces.

-- David R. Tribble, dtribble@technologist.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              ]

Andrew Koenig wrote:
>
> In article <35AE3E1A.167E@wizard.net>, James Kuyper  <kuyper@wizard.net> wrote:
>
> > Sure, an implementation with very small limits would be impractical. The
> > problem is that there are no hard-and-fast rules that I can use to
> > quantify it. With C9X code, if I keep all my names shorter than 32
> > characters, I eliminate all possibility of that problem.
                                               ^^^^^^^^^^^^
>
> I don't believe it.  I am quite confident that if I write a large enough
> program, any C9X compiler will eventually run out of resources and
> be unable to compile that program, even if every identifier in the
> program is shorter than 32 characters.

I did specify "that problem"; the problem of exceeding the compiler's
maximum length for identifiers. I didn't say that it would eliminate the
possibility of "all problems". For one thing, I might have a defect in
my code, or a nuclear bomb might destroy the city before the compiler
finishes. Let's just tackle one problem at a time.


[ 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 <35AD4A98.12B@noSPAM.central.beasys.com>,
David R Tribble  <dtribble@technologist.com> wrote:

> So why not, in addition to the recommendation of 1024 characters,
> go ahead and add a requirement in the standard for a reasonable
> minimum limit?  Like 31, for example, which already has a precedent
> in C89, or 63, which corresponds to C9X?

> Why does the standard not have such a minimum requirement?

I was present at most of the committee's discussions on this
issue, and I will be glad to answer your question if you will
ask it a little more clearly.

Specifically, what do you mean by `a minimum rquirement?'
A minimum requirement for what?

Do you mean that you want to know why the standard does not
require an implementation to accept every program that has
no identifiers longer than N characters?  If so, we decided
that such a requirement is unreasonable, because the program
might be so large that there is not enough memory to compile it,
even though every identifier is relatively short, and we did not
want to require implementations to be able to say, correctly,
in all cases, which of their capacity limitations was exceeded.

Do you mean that you want to require that implementations not
be permitted to treat two identifiers as the same, merely because
their first N characters are the same?  There is already such
a requirement: C++ implementations are required to treat every
character of an identifier as significant.

If you don't mean either of these questions, I would greatly
appreciate it if you would clarify just what you do mean.
--
    --Andrew Koenig
      ark@research.att.com
      http://www.research.att.com/info/ark



[ 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 <35AF71D7.1CFB@wizard.net>, James Kuyper  <kuyper@wizard.net> wrote:
> Andrew Koenig wrote:

> > I don't believe it.  I am quite confident that if I write a large enough
> > program, any C9X compiler will eventually run out of resources and
> > be unable to compile that program, even if every identifier in the
> > program is shorter than 32 characters.

> I did specify "that problem"; the problem of exceeding the compiler's
> maximum length for identifiers.

Well, I don't know what the situation is for C9X, but for C89, you will
definitely not eliminate "that problem" by keeping all your identifiers
shorter than 32 characters.  The reason is that C89 requires a compiler
to accept only one single program that meets all the length requirements;
compilers are permitted to reject any other programs they like.

If the situation is different with C9X, I'd appreciate knowing what it is.
I'm sure I'll learn about it when I go to the C standards meeting in
October, but I wouldn't mind knowing earlier.
--
    --Andrew Koenig
      ark@research.att.com
      http://www.research.att.com/info/ark



[ 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 <zalmanEw7uro.4E4@netcom.com>,
Zalman Stern <zalman@netcom.com> wrote:

> Is it ok for the compiler/linker combination to "transmute" your
> program if the probability is low enough?

Sure -- it happens all the time.  Such events are usually
called ``compiler bugs.''
--
    --Andrew Koenig
      ark@research.att.com
      http://www.research.att.com/info/ark



[ 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              ]

David R Tribble <david.tribble@noSPAM.central.beasys.com> wrote in article <35AD4A98.12B@noSPAM.central.beasys.com>...
> Why does the standard not have such a minimum requirement?
>
> I believe it was P J Plauger who discussed the rationale behind
> requiring a minimum uniqueness length on identifiers some time
> ago, during the C89 standardization process.  He felt that stating
> that "any length is acceptable" forced compiler writers to choose
> large but arbitrary limits that then some clever programmer (or
> validation test suite) would attempt to exceed.  He felt, IIRC,
> that making a reasonably large minimum as part of the language
> spec would do more in the long run to guarantee portability than
> attempting to allow "any" (or "every") size.

Yep, you RC. I harangued the C committee until it adopted a minimum
required length, for just the reasons you state. I was in Australia when
the C++ committee came down the opposite way. (Not that my presence
would have likely made much difference, given my subsequent string of
failures in trying to persuade the C++ committee on any number of other
topics.)

I find it amusing that several threads in the past few weeks have revisited
this delicate notion of mandated limits. We self deprecatingly labeled as
``rubber teeth'' the requirement on translation limits that ended up in the
C Standard. Most of us felt it was a political compromise better than
no limits at all. I objected to the introduction of complexity requirements
in the STL specs -- particularly any with the copout term ``amortized'' --
because they are so easily evaded in practice, if not in theory. And I
agree that unlimited significance in identifiers (with a ``suggested'' lower
bound on how to round down infinity) is more a statement of faith than
an absolute guarantee of anything.

The fact is that any clever implementor can subvert the intent of a
language standard and still nominally conform. ``Minimum maxima'',
complexity requirements, and other suggestions to implementors merely
give useful ammunition to reviewers and validators who wish to curb the
worst excesses of lazy implementors. (Yes, they do exist. I get tired and
inattentive myself, altogether too often.)

It ain't worth waging a holy war over whether the C++ Standard is airtight
or not. It ain't. But it at least holds water. I'll let you have your 1024 letter
identifiers if you'll let me have an occasional #ifdef __ecplusplus...

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.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              ]

J. Kanze wrote:
>
> ark@research.att.com (Andrew Koenig) writes:
>
> |>  In article <6mbg34$sff$1@nnrp1.dejanews.com>,
> |>   <jkanze@otelo.ibmmail.com> wrote:
> |>
> |>  > To make that clearer: the following program is required to compile on
> |>  > all conforming implementations, but could conceivably give a different
> |>  > answer (2) on some:
> |>
> |>  >     #include <iostream>
> |>
> |>  >     int             a1 = 1 ;
> |>  >     int
> |>  >     main()
> |>  >     {
> |>  >         int             a2 = 2 ;
> |>  >         std::cout << a1 << '\n' ;
> |>  >         return 0 ;
> |>  >     }
> |>
> |>  Not true.  The C++ standard explicitly says that all characters of an
> |>  identifier are significant, so a conforming implementation is not
> |>  permitted to decide that a1 and a2 are really the same identifier.
>
> OK.  I didn't check, but was under the impression that the C++ standard
> did the same thing as the C standard, and ignored extra characters.  I'm
> happy to hear of this change.

C9x specifies that at least the first 63 characters of an internal
identifiers, must be significant, and the first 31 characters on
external ones. C++ "does not place a translation limit on significant
characters for external identifiers", but recommends a minimum value of
1024 for both limits. Since this is only a recommendation, the actual
value could be as low as 1 (or even 0) in conforming implementation, as
long as the identifiers in the standard library were treated as special
cases.
Therefore, your code is actually safer in C than in C++.
---
[ 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              ]

>> The C++ standard explicitly says that all characters of an
>> identifier are significant, so a conforming implementation is not
>> permitted to decide that a1 and a2 are really the same identifier.

> OK. I didn't check, but was under the impression that the C++ standard
> did the same thing as the C standard, and ignored extra characters.
> I'm happy to hear of this change.

While the C89 standard mandated no more than 6 significant characters
for external identifiers (and 31 for internal names), the upcoming
C9X draft mandates a minimum of 31 characters for externs (and 63
for internal names).

I tested a few of our systems on hand and found that the following
systems currently distinguish internal C identifiers that differ
only past the 65th character (presumably more):

    DEC Alpha OSF-1 V4.0
    IBM AIX 2.4
    Sun SunOS 5.5.1
    HP HP-UX 10.20
    Microsoft VC++ 5.0

So it seems that most Unix and Win32 systems suppport fairly large
identifiers.  I'm curious what limitations exist on other (more
primitive) systems.

-- David R. Tribble, dtribble@technologist.com --
-- C++, the PL/1 of the 90s.
---
[ 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              ]

James Kuyper  <kuyper@wizard.net> wrote:
>> C9x specifies that at least the first 63 characters of an internal
>> identifiers, must be significant, and the first 31 characters on
>> external ones. C++ "does not place a translation limit on significant
>> characters for external identifiers", but recommends a minimum value
>> of 1024 for both limits. Since this is only a recommendation, the
>> actual value could be as low as 1 (or even 0) in conforming
>> implementation, as long as the identifiers in the standard library
>> were treated as special cases.
>> Therefore, your code is actually safer in C than in C++.

Andrew Koenig wrote:
> This statement is not true.
> C requires that the first 63 characters of an internal identifier
> must be significant, and the first 31 characters of an external
> identifier.
> C++ requires that all characters of all identifiers be significant.
> ...
> C therefore offers the hazard that someone might write a program with
> two identifiers that differ in the 65th character, and that one
> implementation might treat those two identifers as the same and
> another one as different.  C++ has no corresponding hazard.
>
> If you still believe that C is safer in this regard than C++,
> can you give an example of a hazard in C++ that is not in C?

Okay, here:

    /* one.c */

    int         x2345678901234567890A = 123;  // Note 'A' suffix


    /* two.c */

    extern int  x2345678901234567890B;        // Note 'B' suffix

    int main()
    {
        int  i;

        i = x2345678901234567890B;
        return 0;
    }


    # Compile and link
    $ CC -o prog1 one.c two.c   # C++, this may link
    $ cc -o prog2 one.c two.c   # C9X, this won't link

If a C++ compiler has a limit of only 20 significant characters
for external identifiers, then the two identifiers above will
have the same name as far as the linker is concerned.  The
compiler is conforming, since C++ does not mandate a minimum
identifier length (it only recommends a minimum).

A C compiler, on the other hand, will produce code that won't
link, because C9X mandates a minimum of 31 significant characters
in extern names.

To be fair to Andy, though, this example will compile under C9X
but not under C++:

    /* three.c */

    int  x2345678901234567890123456789012345678901234567890\
    1234567890123A = 1;   // Note 'A' suffix

    int  x2345678901234567890123456789012345678901234567890\
    1234567890123B = 2;   // Note 'B' suffix

    int main()
    {
        return 0;
    }


    $ CC -o prog3 three.c  # C++, won't compile
    $ cc -o prog4 three.c  # C9X, may compile


-- David R. Tribble, dtribble@technologist.com --
-- C++, the PL/1 of the 90s.


[ 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              ]

David R Tribble <david.tribble@noSPAM.central.beasys.com> writes:

> >> The C++ standard explicitly says that all characters of an
> >> identifier are significant, so a conforming implementation is not
> >> permitted to decide that a1 and a2 are really the same identifier.
>
> > OK. I didn't check, but was under the impression that the C++ standard
> > did the same thing as the C standard, and ignored extra characters.
> > I'm happy to hear of this change.
>
> While the C89 standard mandated no more than 6 significant characters
> for external identifiers (and 31 for internal names), the upcoming
> C9X draft mandates a minimum of 31 characters for externs (and 63
> for internal names).
>
> I tested a few of our systems on hand and found that the following
> systems currently distinguish internal C identifiers that differ
> only past the 65th character (presumably more):
>
>     DEC Alpha OSF-1 V4.0
>     IBM AIX 2.4
>     Sun SunOS 5.5.1
>     HP HP-UX 10.20
>     Microsoft VC++ 5.0
>
> So it seems that most Unix and Win32 systems suppport fairly large
> identifiers.  I'm curious what limitations exist on other (more
> primitive) systems.

They all need to to support the type encoding in the identifier C++
compilers usually do. I guess the spread of C++ was enough to stomp
out most systems that don't do this. The identifiers generated by
many C++ compilers are often enormous (I've seen >256 chars in some
cases)

[ mod note: I've seen in excess of 1500 characters. -sdc ]

The alternative of encoding types separately for external identifiers
instead of mangling the names usually requires a object format
redesign/major extension (compared to traditional unix-style linkers
at least), and when people do this they seldom introduce arbitary
limits again - because it would just be stupid to do that in the
90ies.

-Andi


[ 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              ]

>Granting every one of your points, what exactly are these "mainstream
>programmers" supposed to be contributing, given as you say that they're used
>to "using the tools that are given them" and have no particular interest in
>the language as such?


Perhaps I don't understand the question. Contributing to whom and why are
they supposed to be doing that?



[ 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              ]

"Greg Colvin" <spam@me.not> writes:

|>  Al Stevens <alstevens@midifitz.com> wrote in article
|>  <DEvi1.20575$08.4858311@newscene.newscene.com>...
|>  > >First, there are never any "cut and dried" requirements when standardizing
|>  > >a language.
|>  >
|>  > Never say never. The C committee had a clearly defined charter as to what
|>  > they were to do, which was essentially to codify existing usage and resolve
|>  > the ambiguities found across existing implementations. I call that pretty
|>  > cut and dried.
|>
|>  I hear this a lot, but it is not a fair or accurate characterization of
|>  the C++ committee's charter.

I'm not sure that the C++ committee ever had a charter.  In the initial
documents for founding the committee, there IS reference to considering
important extensions, with explicite mention of templates, exceptions
and garbage collection.  This reference, however, is in some of the
initial correspondance, and is in no way a charter.

I don't know personally if the C committee had a charter, but they
certainly went beyond codifying existing usage -- there were no C
compilers implementing prototypes when they were adopted into the
standard, for example, and none supporting the # and the ## operators in
the preprocessor.

--
James Kanze    +33 (0)1 39 23 84 71    mailto: kanze@gabi-soft.fr
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient   e objet --
              -- Beratung in objektorientierter Datenverarbeitung


[ 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              ]

ark@research.att.com (Andrew Koenig) writes:

|>  In article <6mbg34$sff$1@nnrp1.dejanews.com>,
|>   <jkanze@otelo.ibmmail.com> wrote:
|>
|>  > To make that clearer: the following program is required to compile on
|>  > all conforming implementations, but could conceivably give a different
|>  > answer (2) on some:
|>
|>  >     #include <iostream>
|>
|>  >     int             a1 = 1 ;
|>  >     int
|>  >     main()
|>  >     {
|>  >         int             a2 = 2 ;
|>  >         std::cout << a1 << '\n' ;
|>  >         return 0 ;
|>  >     }
|>
|>  Not true.  The C++ standard explicitly says that all characters of an
|>  identifier are significant, so a conforming implementation is not
|>  permitted to decide that a1 and a2 are really the same identifier.

OK.  I didn't check, but was under the impression that the C++ standard
did the same thing as the C standard, and ignored extra characters.  I'm
happy to hear of this change.

--
James Kanze    +33 (0)1 39 23 84 71    mailto: kanze@gabi-soft.fr
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient   e objet --
              -- Beratung in objektorientierter Datenverarbeitung


[ 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              ]

J. Kanze <kanze@gabi-soft.fr> wrote in article <m390lzpdur.fsf@gabi-soft.fr>...
> I don't know personally if the C committee had a charter, but they
> certainly went beyond codifying existing usage -- there were no C
> compilers implementing prototypes when they were adopted into the
> standard, for example, and none supporting the # and the ## operators in
> the preprocessor.

We actually spent much of our first technical meeting, in September 1983,
drafting what amounts to a charter document. It placed heavy emphasis on
codifying existing practice and preserving working code. Believe it or not,
essentially everything we added to Standard C was based on *some* prior
art, even if it wasn't always widespread.

For example, I had written a commercial C compiler in 1975-76, while at
Yourdon inc., that let you declare (and check, and coerce) the types of
function arguments. I believe we also had the early experience with C++
as an important proof of concept for function prototypes. We also knew
that token pasting and stringinzing in macro definitions were both useful
functions, though the actual notation of ## and # were pure invention.
And so on.

In any event, I believe it is fair to say that the C committee had a clear
charter and took it seriously. As a result, we largely defined what is now
Standard C with our first Public Review document, published in April 1985.
The library got stuff added thereafter, but always in a form that could be
implemented trivially for those who didn't care for the new features.

I leave it to others to make odious comparisons.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.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              ]

Stephen Vavasis <vavasis@CS.Cornell.EDU> writes:

>David R Tribble wrote:

>>
>> Lord, is this legal?  And meaningful?  In my mind, it's like writing:
>>     extern "C" static void f(int) { }

>Although I am no standards expert, I think that extern "C" { static ...}
>is legal and useful (I've used it!).

Yes. The construct
 extern "C"
introduces language linkage, but has two different effects regarding
whether the name linkage is also external.

1. If you use the linkage specifier directly as part of a declaration,
as in
 extern "C" void f(int);
it means that f has "C" linkage and also has external linkage.

2. If you use the linkage specifier with braces, it specifies only
language linkage and says nothing about whether the name has
external linkage. Example:
 extern "C" {
  void f1(int);        // external linkage
  static void f2(int); // internal linkage
 }
Both f1 and f2 have C linkage. f1 has external linkage because
it appears at namespace scope and is not marked static, not
because of the language linkage directive.

--
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              ]

On 26 Jun 98 02:48:03 GMT, David R Tribble
<david.tribble@noSPAM.central.beasys.com> wrote:

>Since I abhor free variables and functions (static or otherwise),
>I don't have this problem.  All of my "local definitions" are thus
>members of one or more classes (usually declared locally in the
>source file at hand), and so they are ipso facto grouped togther
>into a single "namespace" (i.e., the class name).  And I don't
>suffer from "per-definition clutter".

But your class has external linkage, unless you place it in an unnamed
namespace.

(I'm assuming there's a genuine need for classes, functions, or
variables local to a translation unit, and arguing from that basis.
Myself, I occasionally need to define such classes and functions for
use with templates.)

>I think the new anonymous namespace is useful, but I'm not sure
>getting rid of file-scope 'static' is wise.  I agree that the
>fewer the meanings the better, but of the three meanings we have
>in C++ for 'static', two of those came from C, and will continue
>to be in C for quite a few years yet.  (This could be taken as
>an argument for adding anonymous namespaces to C, though.)

Deprecated though it may be, I have a hard time imagining C++ without
file-scope static. I certainly don't see any harm in keeping it, as
is, and if I gave any other impression, I didn't mean to. I was mainly
objecting to Al's suggested "static class" syntax, since unnamed
namespaces provide a grouping mechanism, and since I believe it's
never too late to avoid making new use of a keyword that was somewhat
unfortunately overloaded for both linkage and storage class purposes.
Moreover, I could just see people writing:

 static struct X {} static x;

and how would one formulate a rule so the meaning of the following
doesn't change?

 static struct X {} x;

It seems "static struct" is even uglier than I first thought.

--
Doug Harrison
dHarrison@worldnet.att.net
---
[ 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              ]

>The first committee draft (CD1) was released in April 1995. Namespaces
>(and STL, exceptions, RTTI, dynamic_cast) have been available on shipping
>commercial compilers since at least November 1995, in the most popular
>compiler on Windows (MSVC).

MSVC is not a good example with which to make your point. The application of
the std namespace did not occur until VC++ 5.0, which was released later, in
1997, I think. Even with 5.0, I would speculate that most Windows
programmers are relatively unaffected by std and the namespace feature
because they don't use many standard classes; they continue to use the MFC
container, I/O, string, and UI classes, which have been around for a while
and which are in the global namespace, and which the API expects. I don't
predict that MFC will change any time soon to use namespaces. Namespaces
will touch Windows programmers when 3rd-party libraries add them.

>Hence my original point: It is incorrect at best to claim that the changes
>made in committee were not visible to most users until after the standard
>was passed

Visible, yes, to those who go looking. But the impact of the namespace
change, although implemented in some compilers, will likely not be felt by
most users until they are required to use it as a consequence of upgrading
to libraries that use it.
---
[ 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 in message ...

Perhaps you
>have no sympathy for these programmers or no respect because of what you
>might view as professional atrophy, but they are, I believe, in the majority
>and deserve to be represented. I don't have any surveys or empirical
>evidence to back up that belief, so you can challenge it if you want. I'll
>have no response other than to say that in all the years I've been
>programming, at all the different places I've worked, those are the kinds of
>programmers I typically find on projects, the mainstream programmers who are
>cranking out code for a living, using the tools that are given to them.


Granting every one of your points, what exactly are these "mainstream
programmers" supposed to be contributing, given as you say that they're used
to "using the tools that are given them" and have no particular interest in
the language as such?

--
Regards,
Daniel Parker danielp@no_spam.anabasis.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              ]

On 27 Jun 98 11:08:19 GMT, enrightm@acm.org (Mike Enright) wrote:

>Some of the MFC tools try very hard to supply the 'C' for you, and
>(AND!) trim the 'C' from the filename. So you can't name something
>Cool, and have it go in "cool.h". It is either called CCool or it goes
>to the "ool.h" file. Blech.

In VC5's ClassWizard, you can choose the names you want, though you
will have to edit the filenames by hand (while still in the
ClassWizard dialog) if your class name begins with 'C', because like
you said, VC drops a leading 'C' from the filenames it suggests. You
can also change the AppWizard-generated classes and filenames, but
I've never bothered with that.

--
Doug Harrison
dHarrison@worldnet.att.net
---
[ 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              ]

Martin v. Loewis wrote:

> > In fact, I believe that:
> >     "internal linkage" = "anonymous namespace".
>
> For most purposes, yes. There are some subtle differences. For
> example,
>
> namespace{
>   extern "C" void f(int){}
> }
>
> gives you a C function f with external linkage, so specifying such a
> function in a different translation unit is an error, although I'm not
> sure whether diagnostic is required.

AllanW@my-dejanews.com wrote:

> In article <35930DA7.43637A1C@nospam.multigen.com>,
>   marcus@multigen.com wrote:
> >
> > Yes, but a header file can always be nested inside a namespace, prior to
> > inclusion in the current compilation unit. So things that a header file
> > declares at global scope can be nested within some other namespace.

[munch]

> This is clearly a mistake.  Don't worry if the compiler doesn't report it
> right away -- it will report it soon enough, as soon as someone tries to
> call vendor::foo() instead of bar::vendor::foo() (or, if they are unlucky
> enough to have a call to bar::vendor::foo(), the problem will be reported
> at link-time.)

After thinking about it, I would say that including files while within a
namespace is bad practice in general. You can never be sure that all compilation
units, that reference that header file, will link correctly. Each compilation
unit would have to declare the same namespace hierarchy for each header file in
order to generate the same external names.

It's simpler to include header files only while in the global namespace. This
also insures that each header file has the ability to declare names in the global
namespace as well.

Regards.

--
+ Marcus Barnes, Technical Staff        mailto:marcus@multigen.com +
+ Multigen Inc.                         http://www.multigen.com    +
+ 550 S. Winchester Blvd.               phoneto:1-408-556-2654     +
+ Suite 500 San Jose CA 95128           faxto:1-408-261-4103       +





[ 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              ]

>>They do not get to see the things that
>>impact their work until after the standardization is completed.
>
>This comment is untrue and easily refuted.

The comment is true although perhaps badly worded. I'm sorry; I did not mean
to imply that the opportunity to see and participate in the process and
review the product was being withheld from anyone. I was talking about a
class of programmer. Believe it or not, there are a lot of programmers who,
unlike us, do not live, eat, breathe, and sleep C++ and the standardization
process. They go to work, write their code, go home, and have a life. They
don't religiously read the magazines we write in; they pick up a programming
book only when they need to know something to get a job done; they don't
attend programming conferences unless their bosses make them go; they don't
post to groups such as this one. Many of them do not even know that a
standardization process is underway, or if they do, figure it is going on
somewhere out there in the ether and doesn't involve them. They have enough
to worry about with today's technology without dealing with things that are
going on somewhere else that will change tomorrow's technology. Perhaps you
have no sympathy for these programmers or no respect because of what you
might view as professional atrophy, but they are, I believe, in the majority
and deserve to be represented. I don't have any surveys or empirical
evidence to back up that belief, so you can challenge it if you want. I'll
have no response other than to say that in all the years I've been
programming, at all the different places I've worked, those are the kinds of
programmers I typically find on projects, the mainstream programmers who are
cranking out code for a living, using the tools that are given to them.





[ 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              ]

|Besides the public comment periods, people had another way to see what was
|coming: The C++ standard was tracked very closely by compiler and library
|vendors. Most major language and library features were already available
|in commercial products long before the standard was finalized.

While that's mostly true, there's an obvious (to me) exception:  the
feature that started this thread.  Despite being introduced in, what
1993?, none of the compilers I use support namespaces.
--
To reply by mail, please remove "mail." from my address -- but please
send e-mail or post, not both


[ 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              ]

David R Tribble <david.tribble@noSPAM.central.beasys.com> writes:
>> In fact, I believe that:
>>     "internal linkage" = "anonymous namespace".

Martin v. Loewis wrote:
> For most purposes, yes. There are some subtle differences. For
> example,
>
> namespace{
>   extern "C" void f(int){}
> }
>
> gives you a C function f with external linkage, so specifying such a
> function in a different translation unit is an error, although I'm not
> sure whether diagnostic is required.

Lord, is this legal?  And meaningful?  In my mind, it's like writing:
    extern "C" static void f(int) { }

I thought I understood that names in the anonymous namespace were
only accessible within the same file, having internal linkage
(just like static names).  But here you're saying that f() has
external linkage.  But you're also saying that I can't access f()
from another file.  This seems contradictory to me.  What would the
definition for f() (in the same file) look like anyway?

How is this legal?  What am I missing?

-- David R. Tribble, dtribble@technologist.com --
-- C++, the PL/1 of the 90s.


[ 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              ]

David R Tribble <david.tribble@noSPAM.central.beasys.com> writes:

> > namespace{
> >   extern "C" void f(int){}
> > }
> Lord, is this legal?  And meaningful?

The foot note to 7.3.1.1 says

>> 82) Although entities in an unnamed namespace might have external
>>     linkage, they are effectively qualified by a name unique to
>>     their translation unit and therefore can never be seen from any
>>     other translation unit.

So it is certainly not

>     extern "C" static void f(int) { }

[f has external linkage]
> But you're also saying that I can't access f() from another file.
> This seems contradictory to me.

I think this was wrong. 7.5/6 says

>> At most one function with a particular name can have C language
>> linkage. Two declarations for a function with C language linkage
>> with the same function name (ignoring the namespace names that
>> qualify it) that appear in different namespace scopes refer to the
>> same function. Two declarations for an object with C language
>> linkage with the same name (ignoring the namespace names that
>> qualify it) that appear in different namespace scopes refer to the
>> same object.

So in another file, you can declare

void foo()
{
  extern "C" void f(int);
  f(4);
}

and foo calls the function f that is defined in an anonymous
namespace in another translation unit.

This is a side effect of
a) anonymous namespace not changing the linkage of objects inside
   them, and
b) "C" linkage ignoring namespaces
(both are reasonable themselves, IMHO)

I'm not sure this was intentional, but I believe this is what the
wording of the FDIS implies.

Regards,
Martin


[ 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              ]

>It is that last group that Committee members have the
>least patience with or sympathy for, and the only ones
>whom I would not consider to be "part of the process".

I believe that last group is the majority and is most in need of patience
and sympathy. Read my response to Herb Sutter.
---
[ 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              ]

john@mail.interlog.com (John R MacMillan) wrote:
>|Besides the public comment periods, people had another way to see what was
>|coming: The C++ standard was tracked very closely by compiler and library
>|vendors. Most major language and library features were already available
>|in commercial products long before the standard was finalized.
>
>While that's mostly true, there's an obvious (to me) exception:  the
>feature that started this thread. Despite being introduced in, what
>1993?, none of the compilers I use support namespaces.

The first committee draft (CD1) was released in April 1995. Namespaces
(and STL, exceptions, RTTI, dynamic_cast) have been available on shipping
commercial compilers since at least November 1995, in the most popular
compiler on Windows (MSVC).

Hence my original point: It is incorrect at best to claim that the changes
made in committee were not visible to most users until after the standard
was passed (which has actually not yet formally happened, although it's
expected in the next month or two and the draft has been cast in stone
since November 1997).

Herb

---
Herb Sutter (mailto:herbs@cntc.com)

Current Network Technologies Corp  2695 North Sheridan Way, Suite 150
www.cntc.com www.peerdirect.com    Mississauga Ontario Canada L5K 2N6
---
[ 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              ]

David R Tribble wrote:

>
> Lord, is this legal?  And meaningful?  In my mind, it's like writing:
>     extern "C" static void f(int) { }

Although I am no standards expert, I think that extern "C" { static ...}
is legal and useful (I've used it!).

The situation I need this is as follows.  I have a custom datatype to
be  used with Tcl/Tk (which is a C library for scripting and windows
operations). To use a custom datatype, you must give Tcl/Tk a pointer to
your "free" procedure for the datatype.  In other words, you must write
a function, say free_my_object, and then (one time only) pass a pointer
to free_my_object to Tcl/Tk's Tcl_RegisterObjType routine.

This function free_my_object should have "C" linkage since it must be
Tcl/Tk callable.  But there is no reason for the name free_my_object to
be visible outside the scope of the source file that defines it and
registers it.  So the function must be declared extern "C", but it is
preferably static.

Does anyone know if there is there a way to get this same functionality
with anonymous namespaces instead of "static"?

-- Steve Vavasis (vavasis@cs.cornell.edu)
---
[ 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              ]

Marcus Barnes <marcus@nospam.multigen.com> writes:

>Al Stevens wrote:

>> I'm not sure how that could be useful. Names in the unnamed namespace have a
>> hidden, unique namespace name. Even if the namespace-qualified names had
>> external linkage, how could anything outside the translation unit access
>> them as external names. You'd have to know the compiler-generated hidden
>> unnamed namespace.

>My concern is with processing load (link times), not accessibility. With
>external linkage, however unique the symbol names, we will be feeding (alot)
>more symbols to the linker then we have been with internal linkage. The
>compiler will also have to munge those symbols, where it might not have had to
>with internal linkage.

There is no requirement that names in the unnamed namespace appear
in any global symbol table. No valid program could detect whether
they did or did not. The most reasonable implementation would be
to keep the names out of global symbol tables.

--
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" <alstevens@midifitz.com> writes:

>>> Complaining about such issues is part of the job of those who comment
>>> publicly on language design and standardization.
>>
>>Such complaints would have been much more helpful if they had been
>>raised during standardization instead of after it was completed.

>I try to represent a large body of programmers who, for one reason or
>another, are not part of the process. They do not get to see the things that
>impact their work until after the standardization is completed.

"Part of the process" is a wide continuum.

At the most-involved end, you can join the committee, attend
meetings, take work assignments, cast official votes. That's
pretty expensive in time and money.

You could join the committee, but attend only meetings
that are convenient. You wouldn't get to cast official
votes (ANSI rules), but you could take work assignments
and lobby via email for your views. This is less expensive
in money, and somewhat less expensive in time.

You could join the committee just to get all the documents
and follow email discussions, participating in discussions
where you have particular interest. If you discover some
change you don't like, you can bring it up yourself in
email. This is pretty minimal cost for being an active
part of the process. Committee membership for J16 is $600
(US) per year. If you are a professional programmer whose
livelihood depends significantly on C++ and you care
about its evolution, surely that money is insignificant.
You spend more than that on software or hardware upgrades
that might be less important to you.

You could not join the committee, but ask questions about
the developement and status of the standard in this
newsgroup. That has been in fact the major purpose of this
newsgroup, and many committee members read this group
and take comments seriously. A number of questions and
comments that have been raised in this newsgroup have
found their way into changes in the draft standard.

You could not join the committee, but wait for the Public-
Comment versions of the draft standard. It's less likely
that you can have an impact on the process, but in fact
a significant number of public comments are adopted.

At the least-involved end, you could ignore the process
until the standard is published, then complain publicly
about all the things you don't like.

It is that last group that Committee members have the
least patience with or sympathy for, and the only ones
whom I would not consider to be "part of the process".

I don't know if it's what Al had in mind when he wrote the
last quoted paragraph above, but it sounds like my last
category.

Of course, there are and will be many programmers whose
first exposure to C++ comes too late to be part of the
process in any meaningful way. They have an opportunity
to be part of the next process, which starts now.

Welcome abord!

--
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" <alstevens@midifitz.com> writes:

> .... It has been suggested to me before that only
>members of the committee are qualified to comment on the actions of the
>committee or on the committee's product. I discard that suggestion.

And so do I, speaking as J16 chair. I hope no Committee member made
the suggestion.  It's unworthy.

>...
>So, to suggest that Standard C++ is above comment and criticism from outside
>the inner circle is, to me at least, inappropriate and unacceptable.

I agree, and so does ANSI. That's why there are advertised public
comment-periods on every standard, and why EVERY comment is logged
and gets an official reply through official channels.

--
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" <alstevens@midifitz.com> wrote:
>I try to represent a large body of programmers who, for one reason or
>another, are not part of the process.

This is a valid and useful position. That's why I and others write columns
too; I'm glad we're on the same wavelength here.

>They do not get to see the things that
>impact their work until after the standardization is completed.

This comment is untrue and easily refuted. I admit that I find it
disappointing because it would paint the standards process as a secretive
black box hidden from public scrutiny until the end product is foisted off
on an unsuspecting world. The process and product have been none of those
things.

Everyone 'got to see the things that impact their work' regularly during
the process because the committee actively published drafts and solicited
public feedback and review during the public comment periods. I actively
contributed in this way several years before ever becoming a committee
member. It bothers me to see people ignore the public comment periods and
then claim that 'people do not get to see the things that impact their
work until after the standardization is completed.'

Besides the public comment periods, people had another way to see what was
coming: The C++ standard was tracked very closely by compiler and library
vendors. Most major language and library features were already available
in commercial products long before the standard was finalized. The new
features in the C++ standard have certainly affected me already -- yes, in
my real-world production code -- long before the standard was passed, and
that fact alone is sufficient to thoroughly refute the above remark.

In contrast, let me add perspective from being on both the C++ and SQL
committees: Vendors are not tracking the SQL3 standard nearly as closely
as C++ -- indeed, a few database vendors are still not SQL92-compliant,
and no vendor to my knowledge has implemented all of SQL92 (that standard
came in "levels" each composed of numerous features). Yet the ANSI H2 and
J16 documents are equally easily available, and the processes equally
open. So why the difference? Partly it's a case of life cycle (this is the
third SQL standard, and the first C++ standard); partly it's a case of
relevance; partly it's a case of size (people complain that the C++
standard is 700-odd pages, conveniently ignoring that well over half is
the standard library which can be ignored if not used, whereas the current
SQL3 draft is somewhere around 1400+ pages spread across at least four
documents -- just the Foundation document is over 940 pages). But the real
reason for the difference is the level of interest: If people -- not just
vendors! -- care about a standard, they can easily, and will, track it.
Just like C++, anyone who's interested in SQL can see what's going on.
There are just fewer people interested in the latest SQL.

So, bottom line: If people care about what's coming in the standard, they
can easily see it -- and influence it -- without being a committee member.
If it's really the case that someone doesn't know what's in the standard
until it's published, it's not for lack of opportunity. To claim otherwise
would be incorrect and improper.

Herb


---
Herb Sutter (mailto:herbs@cntc.com)

Current Network Technologies Corp  2695 North Sheridan Way, Suite 150
www.cntc.com www.peerdirect.com    Mississauga Ontario Canada L5K 2N6
---
[ 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:
>> I'm not sure how that could be useful. Names in the unnamed namespace
>> have a hidden, unique namespace name. Even if the namespace-qualified
>> names had  external linkage, how could anything outside the
>> translation unit access  them as external names. You'd have to know
>> the compiler-generated hidden unnamed namespace.

Marcus Barnes wrote:
> My concern is with processing load (link times), not accessibility.
> With external linkage, however unique the symbol names, we will be
> feeding (a lot) more symbols to the linker then we have been with
> internal linkage. The compiler will also have to munge those symbols,
> where it might not have had to with internal linkage.
>
> This may prove to be a costly way to deprecate one use of "static" in
> the language.

Since it's fairly obvious that anonymous namespaces are meant to be
a long-term replacement for file-static names, and since compilers
have been handling file-static names quite well for many years now,
why on earth would a vendor implement the two kinds of names
differently?

There seems to be the impression that static names don't end up
in the object code.  But they do, on most systems.  Consider
what it takes to resolve the references in an object module that
calls a static function or takes the address of a static variable.
I would wager that the number of symbols present in the object
file, whether they're static or anonymous, is the same.  In fact,
I believe that:
    "internal linkage" = "anonymous namespace".

So again, why would a vendor implement anonymous names differently
than static names?  Or, to phrase it another way, how are the
two kinds of names really different to the linker?

-- David R. Tribble, david.tribble@central.beasys.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              ]

>OK, I've considered it. In fact, I considered it silly.

Me, too. That's why I wrote the response I did.

>> We have this new namespace feature thrust
>> upon us that no one has any experience with and the implications of which no
>> one really understands. The feature creates problems much bigger than those
>> that it solves
>
>This discussion showed no such thing.

A carefule reading of this entire thread does, however, sugggest such a
thing. The fact that a lot of people dispute the perception of the problems
as presented by a few here does not mean the problems do not exist. It only
means that there are two opinions on the issue and, so far, no consensus. I
do not know the demographics of this group, but I suspect that those who
post here are more likely to support than challenge committee decisions. You
might think the war is won based on numbers. But these aren't the trenches.
The trenches are out there in programmer-land.

>No, we don't "have to discuss" these things.

Yet, here you are.

>Some people like to invent
>complex solutions to non-existent problems. (hypothetically, that is...)

Sound familliar? Is anyone thinking "namespaces?" Before the barrage starts,
Pete, I am just joking. It was just too good to resist.
---
[ 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              ]

>That problem is unsolvable.  If names collide, they collide; the
>best the language can do is provide the tools to let you resolve
>the collision.  The C++ namespace does that.

It actually goes a bit further, however, by significantly reducing the odds
of a namespace collision. If you use libraries with no namespace protection
and no careful use of names and name scope, the odds for or against a
collision are marginal at best and a name collision potential exists. If all
the libraries use namespace protection, the odds are completely in your
favor if they use different namespace names and use namespaces correctly. If
all the libraries use namespaces but two of them coincidentally use the same
namespace, the odds that those two will also have colliding names is more in
your favor.

This problem, which might never occur, should be fairly easy to solve by
reasonable people in a cooperative endeavor. Any library that is published
with namespaces is a contemporary one, built in full view of this small
potential for namespace name collision. If you want to use the Acme Graphics
library and the Acme Greenhouse library from different vendors who both
chose AcmeGLib as their namespaces (remember, there are no formal
guidelines), one or both of them should be willing and able to build a
custom version with an alternate namespace by request from one of their
valued customers. Now, you can equally hypothesize circumstances where that
could not occur, but then those circumstances would themselves contribute to
the odds, and the problem virtually disappears.
---
[ 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              ]

>> Complaining about such issues is part of the job of those who comment
>> publicly on language design and standardization.
>
>Such complaints would have been much more helpful if they had been
>raised during standardization instead of after it was completed.

I try to represent a large body of programmers who, for one reason or
another, are not part of the process. They do not get to see the things that
impact their work until after the standardization is completed.
---
[ 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              ]

>An interesting property of a democratic process is that
>the outcome is not always what you wanted.

The committee's work is not a democratic process. You were not elected by
members of the community. You volunteered, appointed yourselves, and paid to
get the appointment. I do not mean to in any way diminish the work of the
committee or the contribution and dedication of its members, which I regard
as awesome. Only to address this particular comment made in response to me.

> Especially if you did not participate in the process while you had the
chance.


That is not a new observation. It has been suggested to me before that only
members of the committee are qualified to comment on the actions of the
committee or on the committee's product. I discard that suggestion. In a
true democratic process the representatives have a constituency who have a
voice and are part of the process.

I considered participation at the beginning, and decided it would be unwise.
In my opinion, direct participation in the deliberation of issues that
involve disagreement and debate would necessarily cause me to join factions,
take sides, development emotional attachments to arguments, and would,
therefore, compromise my objectivity about those issues. My readership
mostly comprises the programmers who do not join committees or concern
themselves with language issues until those issues become a reality in their
work. Those programmers far outnumber those of us who are interested in the
standardization process and in its outcome. I did not think I could report
to them objectively as a member.

So, to suggest that Standard C++ is above comment and criticism from outside
the inner circle is, to me at least, inappropriate and unacceptable.
---
[ 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              ]

David R Tribble <david.tribble@noSPAM.central.beasys.com> writes:

> Since it's fairly obvious that anonymous namespaces are meant to be
> a long-term replacement for file-static names, and since compilers
> have been handling file-static names quite well for many years now,
> why on earth would a vendor implement the two kinds of names
> differently?

Because unnamed namespaces fall out of the namespace implementation
quite naturally (just generate a unique namespace name). OTOH,
"static" could be applied only on a per-definition basis, so most
compilers won't have the concept "Everything from now on has internal
linkage".

At least, this is what I did for g++.

> In fact, I believe that:
>     "internal linkage" = "anonymous namespace".

For most purposes, yes. There are some subtle differences. For
example,

namespace{
  extern "C" void f(int){}
}

gives you a C function f with external linkage, so specifying such a
function in a different translation unit is an error, although I'm not
sure whether diagnostic is required.

Regards,
Martin
---
[ 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              ]

Doug Harrison wrote:
> I'd rather group local definitions inside a single unnamed namespace
> than preface those definition with "static". I think providing an
> alternative to per-definition clutter is a clear win, and the fewer
> meanings for a keyword, the better. I think "static class" would only
> compound the strangeness.

Since I abhor free variables and functions (static or otherwise),
I don't have this problem.  All of my "local definitions" are thus
members of one or more classes (usually declared locally in the
source file at hand), and so they are ipso facto grouped togther
into a single "namespace" (i.e., the class name).  And I don't
suffer from "per-definition clutter".

I think the new anonymous namespace is useful, but I'm not sure
getting rid of file-scope 'static' is wise.  I agree that the
fewer the meanings the better, but of the three meanings we have
in C++ for 'static', two of those came from C, and will continue
to be in C for quite a few years yet.  (This could be taken as
an argument for adding anonymous namespaces to C, though.)

-- David R. Tribble, david.tribble@central.beasys.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              ]

I, David R Tribble <david.tribble@noSPAM.central.beasys.com> wrote:
>> As P J Plauger pointed out a few months ago in the CUJ, namespaces
>> still don't solve one of the problems they were supposed to, that
>> being the collision of names in two separate (usually third-party)
>> libraries.

Nathan Myers wrote:
> That problem is unsolvable.  If names collide, they collide; the
> best the language can do is provide the tools to let you resolve
> the collision.  The C++ namespace does that.

Yes, but not as nicely as being able to truly alias a symbol with
an entirely different name (as opposed to having/requiring a
prefix on the original name).  Placing the colliding names I'm
using in separate namespaces forces me to either 1) rewrite all
uses of both names so that they now have prefixes, or 2) add more
code (in form of inline functions or something similar) to make
one name look different than the other.

With my renaming suggestion ala Eiffel, I only have to add one line
of code to alias a name (a new kind of 'using' declaration), and I
only have to change the occurrences of one of the colliding names,
leaving the other name as is.  And the changed name is not
necessarily longer than it was before, either.  I'm talking about
a true alias for a name, not simply forced prefixing.

But don't get me wrong - I think namespaces are a good idea.  I just
think they could be better.

>> I've always thought that the renaming capability of Eiffel was a
>> clever idea.  It allows you to rename, or alias, a member of a
>> class (or class library), giving it a different name entirely.
>> This seem to me to be more useful than C++ aliases that are nothing
>> more than the original name with an explicit prefix.

> Besides namespace aliases, C++ has inline functions and typedefs.
> Combined, these are more powerful than Eiffel's limited aliasing
> mechanism.

I'm not comparing Eiffel to C++.  I'm pointing out how adding one
feature of Eiffel to C++'s namespaces would make them more useful.

> (Alas, we don't have template typedefs yet, which would
> complete the picture.)

Yep, a definite oversight in C++.

-- David R. Tribble, david.tribble@central.beasys.com --
C++, the PL/1 of the 90s.
---
[ 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:

> I'm not sure how that could be useful. Names in the unnamed namespace have a
> hidden, unique namespace name. Even if the namespace-qualified names had
> external linkage, how could anything outside the translation unit access
> them as external names. You'd have to know the compiler-generated hidden
> unnamed namespace.

My concern is with processing load (link times), not accessibility. With
external linkage, however unique the symbol names, we will be feeding (alot)
more symbols to the linker then we have been with internal linkage. The
compiler will also have to munge those symbols, where it might not have had to
with internal linkage.

This may prove to be a costly way to deprecate one use of "static" in the
language.

Regards.

--
+ Marcus Barnes, Technical Staff        mailto:marcus@multigen.com +
+ Multigen Inc.                         http://www.multigen.com    +
+ 550 S. Winchester Blvd.               phoneto:1-408-556-2654     +
+ Suite 500 San Jose CA 95128           faxto:1-408-261-4103       +
---
[ 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              ]

Christopher Eltschka wrote:

> Marcus Barnes wrote:
>
> [...]
>
> > This leads me to a question. Is there a way to invoke, or revert to, the
> > global namespace? It's seems that there needs to be a way of insuring that a
> > name is in the global namespace. For example:
> >
> > namespace vendor {
> >   namespace <global> {
> >    void foo();
> >   }
> > }
> >
> > This would result in the fully qualified name "::foo", even though it's been
> > nested inside the vendor namespace.
>
> There is a way: Close your namespace and reopen it:

[munch]

Yes, but a header file can always be nested inside a namespace, prior to
inclusion in the
current compilation unit. So things that a header file declares at global scope
can be nested
within some other namespace.

[foo.h]

void foo();                // at global scope, but we cannot enforce it

[eof][

[bar.h]

namespace bar {
#include "foo.h"        // what was ::foo() is now bar::foo()
}

[eof]

Is this a problem that needs a solution?

Regards.

--
+ Marcus Barnes, Technical Staff        mailto:marcus@multigen.com +
+ Multigen Inc.                         http://www.multigen.com    +
+ 550 S. Winchester Blvd.               phoneto:1-408-556-2654     +
+ Suite 500 San Jose CA 95128           faxto:1-408-261-4103       +
---
[ 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              ]

> pointer, reference, member, and so on. According to their docs, "All class
> names begin with C, as in CMyClass.

It get's much worse.  As a consultant, I do C++ programming for a
variety of corporations.  In the last 3 years I would estimate that
80% of the clients have internally published "Coding Standards"
stating that "all class names must begin with C since that is the way
Microsoft does it".  Sometimes I don't know whether to laugh or cry!
:-)

Peace

Peter
---
[ 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              ]

Marcus Barnes wrote:
>
>
> My concern is with processing load (link times), not accessibility. With
> external linkage, however unique the symbol names, we will be feeding (alot)
> more symbols to the linker then we have been with internal linkage. The
> compiler will also have to munge those symbols, where it might not have had to
> with internal linkage.
>
> This may prove to be a costly way to deprecate one use of "static" in the
> language.

Al's point, carried one step further, is that since you can't do
anything useful with this, under the "as if" rule, the compiler is free
to not do it. I'm sure that's what every vendor does.
---
[ 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 wrote:
>
> In article <MMhk1.760$sV4.190857@newscene.newscene.com>,
>   "Al Stevens" <alstevens@midifitz.com> wrote:
> >
> > ... if you have a major namespace problem, it's the biggest thing in
> > your life. If you've never had a significant namespace problem (I have
> > not in 40 years of programming on projects of all sizes), it's not your
> > highest priority.
>
> Are you suggesting that you've been programming in C++ since 1958?
>
> (Namespaces are unique to C++)

The namespace keyword is new in C++ (I hesitate to claim that it's
unique; there are a lot of other programming languages out there). Name
spaces have been around since the first assembler program was created
that allowed you to use a name rather than a numeric address for a
variable. A name space is the set of all names that can appear in a
given context. Name space problems probably date back almost as far -
whenever two pieces of code are combined that used the same name with
incompatible meanings, in a context where that name can have only one
meaning for both.
---
[ 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 wrote in message <6mubod$4sp$1@nnrp1.dejanews.com>...
>In article <MMhk1.760$sV4.190857@newscene.newscene.com>,
>  "Al Stevens" <alstevens@midifitz.com> wrote:
>>
>> ... if you have a major namespace problem, it's the biggest thing in
>> your life. If you've never had a significant namespace problem (I have
>> not in 40 years of programming on projects of all sizes), it's not your
>> highest priority.
>
>Are you suggesting that you've been programming in C++ since 1958?
>
>(Namespaces are unique to C++)

"Namespace problems" aren't.  No points for that one.

--
Regards,
Daniel Parker danielp@no_spam.anabasis.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              ]

dHarrison@worldnet.att.net (Doug Harrison) wrote:

>
>It's sort of insidious that way. I think MFC does indeed use it for
>that purpose, and OWL uses "T" to indicate "type". However, if MFC
>wants to introduce a class named "Widget", how do you think MFC will
>spell it? That's easy: "CWidget". Woe to him who had already written a
>class called CWidget!

Some of the MFC tools try very hard to supply the 'C' for you, and
(AND!) trim the 'C' from the filename. So you can't name something
Cool, and have it go in "cool.h". It is either called CCool or it goes
to the "ool.h" file. Blech.


--
Mike Enright
enrightm@acm.org (Email replies cheerfully ignored, use the news group)
http://www.users.cts.com/sd/m/menright/
Cardiff-by-the-Sea, California, USA
---
[ 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              ]

Marcus Barnes wrote:

[...]

> Yes, but a header file can always be nested inside a namespace, prior to
> inclusion in the
> current compilation unit. So things that a header file declares at global scope
> can be nested
> within some other namespace.
>
> [foo.h]
>
> void foo();                // at global scope, but we cannot enforce it
>
> [eof][
>
> [bar.h]
>
> namespace bar {
> #include "foo.h"        // what was ::foo() is now bar::foo()
> }
>
> [eof]
>
> Is this a problem that needs a solution?

I don't think so. After having tried it once without succeeding,
any user will refrain from doing this anyway.
Note that headers are usually included in one bunch at the beginning
of a file.

BTW, would

  void ::foo();

be legal?
---
[ 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 <359246D8.AE0E007F@acm.org>,
  Pete Becker <petebecker@acm.org> wrote:
>
> Al Stevens wrote:
> >
> > Complaining about such issues is part of the job of those who comment
> > publicly on language design and standardization.
>
> Such complaints would have been much more helpful if they had been
> raised during standardization instead of after it was completed.

Consider that there will undoubtedly be another standardization effort in
the future.  My crystal ball is broken, so let's call it the
ANSI/OSI-2002-C++-Standard.  Thus, these complaints are actually far in
advance of the standardization effort, and may help to direct it's charter.

Surely complaints made four years ago, way back in 1998, even before the
previous standard was finalized, will pull more weight (if the complaints
continue when the new charter is starting up) than more recent complaints
(say, December 2001, when every element in a rebel array of integers
signs a petition -- posted on comp.std.c++ -- to extend the namespace
mechanism to include namefurniture, namebedroom, nametoilet, and so on,
thereby expanding the concept of "data privacy" to include "data comfort"
while simultaneously making any notion of "garbage collection" obsolete).


-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum
---
[ 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              ]

ncm@nospam.cantrip.org (Nathan Myers) wrote:

> Besides namespace aliases, C++ has inline functions and typedefs.
> Combined, these are more powerful than Eiffel's limited aliasing
> mechanism.  (Alas, we don't have template typedefs yet, which would
> complete the picture.)

Improve, yes; complete, no.  Off the top of my head, I can think of six
things that can be declared in a namespace scope: namespaces, types,
templates, functions, objects, and enumerators.  Of these, only namespaces
and types can truly be aliased.  While template typedefs would solve the
biggest problem, small holes would remain.

An inline forwarding function is not the same as a new name for the
original function.  It will have a new address, and writing one requires
access to the copy-constructors of the parameter and return types.  It's
also a maintenance problem, as the signature must match the original.
Function templates have the same problems.

Objects can very nearly be aliased with a reference, but since the
reference definition can appear in only one compilation unit, the code
generated by most compilers would be worse than for a true alias.  (When
the new name is in the global namespace, one can avoid this problem by
making the reference static.)

Finally, enumerators can nearly be aliased by constant definitions, but
different aliases will have different addresses, and the original
enumerator has no address.

                                              --Tom Lippincott
---
[ 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 <35930DA7.43637A1C@nospam.multigen.com>,
  marcus@multigen.com wrote:
>
> Christopher Eltschka wrote:
>
> > Marcus Barnes wrote:
> >
> > [...]
> >
> > > This leads me to a question. Is there a way to invoke, or revert to, the
> > > global namespace? It's seems that there needs to be a way of insuring
> > > that a name is in the global namespace.
> >
> > There is a way: Close your namespace and reopen it:
>
> Yes, but a header file can always be nested inside a namespace, prior to
> inclusion in the current compilation unit. So things that a header file
> declares at global scope can be nested within some other namespace.
> Is this a problem that needs a solution?

I should think not.

    // [foo.h]
    namespace vendor {
      // ...
    }
    void foo(); // Global namespace
    namespace vendor {
      // ...
    }

    // [bar.h]
    #include "foo.h"

Header file foo.h "knows" about namespaces (by definition, since it wants
foo() to be "out" of the vendor namespace).

> [foo.h]
> void foo();                // at global scope, but we cannot enforce it
> [eof]
>
> [bar.h]
> namespace bar {
> #include "foo.h"        // what was ::foo() is now bar::foo()
> }
> [eof]

Including foo.h in this way is only used when foo.h does not "know" about
namespaces.

    // [foo.h]
    namespace vendor {
      // ...
    }
    void foo(); // Global namespace
    namespace vendor {
      // ...
    }

    // [bar.h]
    namespace bar {
    #include "foo.h"
    }

This is clearly a mistake.  Don't worry if the compiler doesn't report it
right away -- it will report it soon enough, as soon as someone tries to
call vendor::foo() instead of bar::vendor::foo() (or, if they are unlucky
enough to have a call to bar::vendor::foo(), the problem will be reported
at link-time.)


-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum
---
[ 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              ]

Jim Cobban <Jim.Cobban.jcobban@nt.com> wrote in article
<6mtp72$n8r@bcarh8ab.bnr.ca>...
> In article <01bd9b25$3103f4c0$01010101@gcolvin-hpc>,
> Greg Colvin <spam@me.not> wrote:
> >
> >
> >Jim Cobban wrote:
> >> ...  The problem solved by namespaces
> >> applies only to a small proportion of even very large projects.  It does not
> >> make sense to make the use of namespaces mandatory even in trivial programs,
> >> such as hello world in order to solve the problems of a handful of (in my
> >> opinion) poorly designed projects.  Let that minority who have the problem
> >> use namespaces, and leave the rest of us alone with our working code.
> >
> >In what way are you not left alone with your working code?
>
> The way the standard is written, which I agree is different from what the
> compiler vendors are actually delivering, all references to functions in the
> standard library must be prefixed by std:: unless I do something like using
> namespace std; which is deprecated.

No, it most certainly is not deprecated.

>    We are currently running Gnu C++ 2.7.2
> in which namespaces are not supported, but I dread what happens when we try
> to move our millions of lines of code to a level of the compiler which
> complies to the namespace specification.  Everything I have read insists
> that we will have to do SOMETHING to every single source file to accomodate
> this change to the language.  Frankly we have better things to spend our
> time on, like delivering useful functionality to our customers.

What happens is you either put a "using namespace std" where needed, or
switch to explicit qualification.  It's that simple.

> I simply do not understand why we, with millions of lines of code as I said,
> much of which comes from imported libraries and other licensed code sources,
> have almost no problems avoiding conflicts which the authors of this concept
> insist are unavoidable.

Careful engineering and a bit of luck would be my guess.

Greg Colvin
---
[ 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              ]

Jim Cobban <Jim.Cobban.jcobban@nt.com> writes:

> The problem solved by namespaces
> applies only to a small proportion of even very large projects.

I have had many collisions in 500 to 3000 lines C/C++ programs.
Note that most collision didn't appeared immediatly, when I
choose the identifier, but after, when I switch to a new
release of the compiler. I hate that.

Now I can't even _imagine_ what can hapen in a big project.
It gives me headaches.

namespaces are IMO elegant; powerfull, easy to use for new
code, easy to put over old code. I don't understand why
they didn't appeared long before.

namespaces aren't trivial to specify and implement, and some
commitees members might complain about the added work, but
1) I don't care about commitee members pain if it serves
   some purpose
2) actually I think that some commitee members like that
   (the work, not the pain)

--

Valentin Bonnard                mailto:bonnardv@pratique.fr
info about C++/a propos du C++: http://pages.pratique.fr/~bonnardv/


[ 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              ]

On 19 Jun 1998 17:22:16 GMT, "Al Stevens" <alstevens@midifitz.com>
wrote:

>Only because C++ does not support:
>
>static class ForUseOnlyByThisTranslationUnit {};
>
>without an instance name included. If it did as C does with structs, static
>and file scope, a time-tested legacy concept, 20 years in the proving,
>instead of being deprecated, would cover what the unnamed namespace does
>now.

I'd rather group local definitions inside a single unnamed namespace
than preface those definition with "static". I think providing an
alternative to per-definition clutter is a clear win, and the fewer
meanings for a keyword, the better. I think "static class" would only
compound the strangeness.

>>Without namespaces, we have to use prefix warts
>>everywhere, e.g. a library writer can't refer to his "A" class without
>>spelling it "wart_A", and that's tedious, and it smells like a
>>language shortcoming.
>
>No, it relieves me from having to wonder which A I am looking at when I read
>the code.

Inside my namespace scope, I know that when I write "A", I'm referring
to my A. I don't see what there is to wonder about.

>I haven't really had any namespace problems. I haven't had any problems that
>needed namespace solutions either. Lots of posts in this thread state
>expressly how namespaces help a programmer as if the poster knows, yet other
>posts about poor implementations and uses of the feature and the
>incompatibility of namespaces and macros clearly indicate that the community
>does not have enough experience with this feature to say except through
>intuition how well the feature is going to work and how it is going to help.
>The jury is still out. That is the risk you take when you expand a
>standardization charter to include language invention.

But the standard does include a test of the facility: the standard
library. In the context of programs that use the standard library, do
you think namespaces meet the goals set for them?

--
Doug Harrison
dHarrison@worldnet.att.net


[ 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              ]

Pete Becker <petebecker@acm.org> writes:

>Fergus Henderson wrote:
>>
>> wkdugan@ix.netcom.com (Bill Dugan) writes:
>> >Pete Becker <petebecker@acm.org> wrote:
>> >>Tom McKearney wrote:
>> >>> You can easily do the following:
>> >>>
>> >>> namespace vendor {
>> >>> #include "VendorHeader1.h"
>> >>> #include "VendorHeader2.h"
>> >>> }
>> >>
>> >>Unfortunately, this doesn't work. The library itself has to be built
>> >>with namespaces, too. Otherwise it won't link.
>> >
>> >Is there something in the standard that forces this, or is it an
>> >avoidable byproduct of current implementation techniques?
>>
>> The latter.  It would be quite straight-forward to either
>
>No, the former. <g>
>
>>         (a) provide a separate tool for manipulating object files and
>>             libraries, allowing one to add, remove, or rename namespace
>>             prefixes
>
>Yes, that is conceivable. But it's outside the scope of the language
>definition.

Of course it is.  But that's exactly what Bill Dugan was asking for --
he wanted to know whether the standard *prevented* implementations
from supporting that kind of thing.

Nathan Myers pointed out a serious problem, though: #include statements
in the VendorHeador*.h files will cause trouble.  Thus there's no easy
way of making the above syntax work.  (In a language with a real module
system rather than "#include", this wouldn't be an issue, of course.)

However, just as implementations could provide tools for adding and
removing namespace prefixes from object files and libraries, they could
provide a related tool that would add or remove them from header files.
Or, as with object files, it could be done on-the-fly: a special command
line option (or pragma) could be used that would cause the compiler to
treat all declarations occurring in the header files in a particular directory
as having been made within a particular namespace, or could add
a particular namespace to the set of namespaces searched by name
lookup just for declarations and definitions in a particular header file.

So, I concede that the exact syntax above won't work, but there's no
reason why the general technique couldn't be made to work.  The only
think it won't handle, of course, is macros.

>> or
>>         (b) extend the linker with support for wrapping up libraries
>>             in namespaces on-the-fly during linking (perhaps by using
>>             an option such as `-l vendor::lib' instead of `-l lib')
>
>This would almost certainly be disastrous.

I don't see why you object so strongly to (b) but not (a), since they're
both doing the same thing, just with a slightly different user interface.
(Or was that comment directed at (a) too?)

>See the example that I gave
>in my other message:

OK, here it is:

 | Suppose VendorHeader1.h supplies a prototype for a function f:
 |
 | void f();
 |
 | In one translation unit (i.e. in a library) you have code that uses that
 | header directly, and calls f.

Ah, but the idea here is that you don't do that.
You use a tool that actually munges the header file, or a compilation
option, so that all the files you compile will get the declaration
wrapped in the vendor namespace, never in global scope.

If you have several third-party libraries which depend on each other,
and for which you do not have source, then should you use your library
munging tool (or linker options) to wrap any symbol references in one
library that depend on symbols defined in another, and similarly you
should use your header file munging tool (or compiler options) to handle
inter-library references in header files.

Now it is likely that implementing the header file munging tool
is going to be more work than the library file munging tool,
so I'm not saying this would necessarily be easy.  But it is possible.
And as I heard on the radio today, 8-year old school children are now doing
things that would only a few years ago have been difficult even for
professional programmers -- so who knows what will happen in the future.

Of course it may be that we all migrate to languages like Java where
you have a proper module system, no macros, and a portable executable
format, all of which make implementing this kind of package renaming
tool much easier.

--
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3        |     -- the last words of T. S. Garp.
---
[ 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              ]

On 19 Jun 1998 23:05:02 GMT, David R Tribble
<david.tribble@noSPAM.central.beasys.com> wrote:

>Microsoft, in its usual arrogance, uses the unbelievably lame prefix
>'C' on all their Foundation Classes names.  It was probably done more
>out of ignorance than outright hostility.

It isn't just MSFT; Borland does the same thing with OWL, except it
uses "T". Unfortunately, many people don't realize those prefixes are
effectively reserved by those libraries, and they tend to use the same
prefix as whatever library they imprinted on. It doesn't help that the
"wizards" suggest such names.

--
Doug Harrison
dHarrison@worldnet.att.net
---
[ 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              ]

Doug Harrison wrote in message <6mpc4m$bd6@bgtnsc01.worldnet.att.net>...
>
>But the standard does include a test of the facility: the standard
>library. In the context of programs that use the standard library, do
>you think namespaces meet the goals set for them?
>
My only gripe is why didn't they provide a better model for naming include
files associated with the namespace?  I'm sure they wouldn't want to send
the message to the programming community that chopping off the .h is a good
way of resolving name conflicts for files.  Surely putting them in a
subdirectory std would have been a better idea?

--
Regards,
Daniel Parker danielp@no_spam.anabasis.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              ]

Clive Bluston <clive@emultek.co.il> writes:

> On the other hand I seem to spend vast amounts of time these days trying
> to get third party code compiled. Most of the time the problem comes
> down to namespace related code.

The same considerations apply to the STL. Many macros, many
problems with compilers... Do you want to apply the same
conclusions ?

> Not only that, when you look at the
> attemts of library writers to get their code to compile in various
> environments, you see that they have introduced large number of macros,
> making the pollution problem even worse!

Is it true ? These macro have a good name, in general
PACKAGENAME_MACRONAME, that won't colide with any else.
Or do you have an example of such colision ?

When I use macros to use namespaces or other features not
widely implemented, I use the form VB_LIB_MACRONAME
when
- VB stands for me
- LIB is the name of the library
- MACRONAME is the underscore separated (long) description
  of the macro

--

Valentin Bonnard                mailto:bonnardv@pratique.fr
info about C++/a propos du C++: http://pages.pratique.fr/~bonnardv/
---
[ 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              ]

Greg Colvin (spam@me.not) wrote:
: Anyway, my point was that someone who really doesn't want to use
: namespaces, and who really does want the library global, and who
: really isn't going to be convinced otherwise, should just issue
: the directive and stop complaining.

the problem with "using namespace std" is that it can introduce name
abiguities into code that used to compile. E.g. with Metrowerks Codewarrior
3, the following fails:

#include <fp.h>
#include <math.h> /* Includes cmath or some such and does a "using
     * namespace std"
     */

double func(void) {
    return sqrt(42); // Generates an error. Call could be to sqrt or std::sqrt.
}

double func2(void) {
    return ::sqrt(42); // Works.
}

Life goes on...

What do people mean when they say "aliases?" Is this a reference to a C++
feature or a technique (perhaps using #defines or some such).

Also, has anyone considered linker support for remapping the namespace of
code in an object module or library. I think that would be quite useful for
resolving conflicts.

By the way, a big advantage to namespaces over prefixing is that its much
easier to do it consistently. On most projects I've worked on, 100%
compliance with prefixing standards has been very elusive.

-Z-
---
[ 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              ]

Tom McKearney wrote:
>>> You can easily do the following:
>>> namespace vendor {
>>> #include "VendorHeader1.h"
>>> #include "VendorHeader2.h"
>>> }

Pete Becker <petebecker@acm.org> wrote:
>> Unfortunately, this doesn't work. The library itself has to be built
>> with namespaces, too. Otherwise it won't link.

As P J Plauger pointed out a few months ago in the CUJ, namespaces
still don't solve one of the problems they were supposed to, that
being the collision of names in two separate (usually third-party)
libraries.

Oh sure, you can wrap both libraries into separate namespaces, like
this:
    // vendor1.h
    namespace VendorOne {
        void foo();
        ...
    }

    // vendor2.h
    namespace vendorTwo {
        void foo();
        ...
    }

But your code still can't easily distiguish between the two foo()
names.  You still have to change all calls to foo(), adding an
explicitly namespace prefix:
    VendorOne::foo();    // Calls VendorOne::foo()

I've always thought that the renaming capability of Eiffel was a
clever idea.  It allows you to rename, or alias, a member of a
class (or class library), giving it a different name entirely.
This seem to me to be more useful than C++ aliases that are nothing
more than the original name with an explicit prefix.

Applying the Eiffel concept to C++ would allow something like
this:
    #include "vendor1.h"
    // Leave VendorOne::foo as is

    #include "vendor2.h"
    namespace VendorTwo {
        using bar = foo;    // VendorTwo::foo is now called bar
        ...
    }

    void myfunc()
    {
        foo();     // Calls VendorOne::foo()
        bar();     // Calls vendorTwo::foo()
    }

The renaming would only apply during compilation; the real names
would still be used at link/load time.  It's a little like
wrapping the call to VendorTwo::foo() inside an inline function
called bar(), except that it only takes a single 'using' line in
the code (or project header).

While this may still require code changes (after the fact, when
the two libraries are used by the same source file), the change
is not as intrusive; I only have to change half my 'foo()' calls
to 'bar()', and I can leave the other half unchanged.

-- David R. Tribble, david.tribble@central.beasys.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              ]

Andrew Koenig (ark@research.att.com) wrote:
: The most important problem that namespaces solve, in my opinion,
: is the problem of combining libraries from multiple vendors.
: This has not been a problem until recently, because there have not
: been many library vendors until recently.

Perhaps the folks arguing against namespaces should consider whether they'd
be happy steering clear of all the names used in the C++ standard library
itself.  Its either that or having all those names prefixed, which would
have introduced a lot of other transition nightmares.

-Z-
---
[ 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 <6mbf8s$qmh$1@nnrp1.dejanews.com>,
  jkanze@otelo.ibmmail.com wrote:
> There is an international brokerage for prefixes: trademark registry.
> I can tell at a glance when I'm dealing with a Rogue Wave header file,
> for example, because the prefixes give it a specific general appearance,
> much like the shape of a Coke bottle is easily recognizable.  I'm not
> sure that putting everything in a common namespace could be registered
> as a trademark, however.

Trademarks are not international; each separate country has its own registry.
While some names have been trademarked for one product in many countries (e.g.
Coke), there are many more cases where the same name belongs to different
companies & products in different countries.

And there are other problems: the same mark can be used by different
companies for different classes of goods (Apple - computer company or record
label?). And trademark registration can lapse or be legally overturned, and
then be used by someone else.

Better choices might be domain names (globally unique, but may get re-used) or
OIDs (which do have a central registry but are a bit unreadable - anyone for
"namespace iso_org_dod_internet_private_enterprise_2561;"?).

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/   Now offering spam-free web-based newsreading


[ 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              ]

>Anyway, my point was that someone who really doesn't want to use
>namespaces, and who really does want the library global, and who
>really isn't going to be convinced otherwise, should just issue
>the directive and stop complaining.


Complaining about such issues is part of the job of those who comment
publicly on language design and standardization.





[ 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 rather group local definitions inside a single unnamed namespace
>than preface those definition with "static". I think providing an
>alternative to per-definition clutter is a clear win, and the fewer
>meanings for a keyword, the better. I think "static class" would only
>compound the strangeness.

I don't think it's that clear. "static struct" worked fine for years. Just
because you prefer to use a namespace doesn't mean we didn't already have a
mechanism that would have worked if it had not been removed from the
language.

>>No, it relieves me from having to wonder which A I am looking at when I
read
>>the code.
>
>Inside my namespace scope, I know that when I write "A", I'm referring
>to my A.

You are fortunate that you have to look at only your own code.

> I don't see what there is to wonder about.

Only because you are using (saddled with) the namespace feature in the first
place. My argument is that you don't need namespaces when you judiciously
use prefixes. You seem to be saying that you don't need prefixes because you
have namespaces. We're going round in circles here.

>But the standard does include a test of the facility: the standard
>library. In the context of programs that use the standard library, do
>you think namespaces meet the goals set for them?


I have not read the goals. I do not know that they are formally stated
anywhere outside of the minutes of committee deliberations. As far as I
know, the committee was not required to conduct a formal requirements
analysis with a published result, a grave omission given the committee's
self-appointed mandate to innovate language and library design.

I think all the standard library names should be in the global namespace
anyway. After all, it's the Standard Library. No one should be using those
names. Library writers could use the old C underscore convention for
whatever external names they need. That works fine as long as everyone
acknowledges the convention. Unless, of course, you think the standard
library will grow substantially in the future and need a bunch more
user-visible names that might collide. I don't think it will or should.





[ 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              ]

>the problem with "using namespace std" is that it can introduce name
>abiguities into code that used to compile. E.g. with Metrowerks Codewarrior
>3, the following fails:
>
>#include <fp.h>
>#include <math.h> /* Includes cmath or some such and does a "using
>    * namespace std"
>    */
>
>double func(void) {
>    return sqrt(42); // Generates an error. Call could be to sqrt or
std::sqrt.
>}
>
>double func2(void) {
>    return ::sqrt(42); // Works.
>}

That looks like a compiler bug. The sqrt function is supposed to be the same
function in both the std and the global namespace. Unless, of course, you
work for Microsoft.

>What do people mean when they say "aliases?" Is this a reference to a C++
>feature or a technique (perhaps using #defines or some such).

namespace sgl = SpiffyGraphicsLibrary;

Lets you use sgl as an abbreviated alias in your code.


>Also, has anyone considered linker support for remapping the namespace of
>code in an object module or library. I think that would be quite useful for
>resolving conflicts.

There is a discussion of such a thing earlier in this thread. I consider it
to be a kludge on a kludge.

>By the way, a big advantage to namespaces over prefixing is that its much
>easier to do it consistently. On most projects I've worked on, 100%
>compliance with prefixing standards has been very elusive.


Which is the best argument I've heard here for namespaces over prefixes and
a sad commentary on the commitment to quality of some programmers. If class
designers use prefixes judiciously, programmers have no choice but to
comply. If class designers simply refuse to adhere to a project's
guidelines, then I guess we need a language feature to encourage them to be
better programmers.





[ 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              ]

Consider this discussion, folks. We have this new namespace feature thrust
upon us that no one has any experience with and the implications of which no
one really understands. The feature creates problems much bigger than those
that it solves so that we have to discuss contriving "header file munging"
and "library file munging" tools to solve namespace problems. Who knows what
problems will arise from the munging approach? Complexity built on top of
complexity. Where does it all end?





[ 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              ]

On 24 Jun 98 09:41:55 GMT, "Daniel Parker" <danielp@nospam.com> wrote:

>Doug Harrison wrote in message <6mpc4m$bd6@bgtnsc01.worldnet.att.net>...
>>
>>But the standard does include a test of the facility: the standard
>>library. In the context of programs that use the standard library, do
>>you think namespaces meet the goals set for them?
>>
>My only gripe is why didn't they provide a better model for naming include
>files associated with the namespace?  I'm sure they wouldn't want to send
>the message to the programming community that chopping off the .h is a good
>way of resolving name conflicts for files.  Surely putting them in a
>subdirectory std would have been a better idea?

Maybe, but there's a practical reason it isn't addressed: the language
standard has no concept of directories or any requirement that they be
supported by the compiler. Standardization is very difficult and every
time you introduce a new concept you have to deal with myriad
consequences. For example, what is the directory separator character?
On Unix, it's '/', but on Windows machines, it's '\'. On a Mac, it's
':' (search me ?!?). On a Mac, you can have a '/' in a file name...
and on and on. I'm sure this is only one of at least 10 potential
issues. In a standard where the system is only required to support 6.2
file naming, I think you'd find it hard to require directories.

C++ makes lots of other concessions to limitations of individual
implementations. Sometimes I wish it didn't, but that's part of its
long-standing culture, and possibly a reason that it has gained such
widespread use.

-Dave

BTW, I support your approach where libraries other than std are
concerned; I use it myself.


[ 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              ]

"Daniel Parker" <danielp@nospam.com> writes:

>Doug Harrison wrote in message <6mpc4m$bd6@bgtnsc01.worldnet.att.net>...
>>
>My only gripe is why didn't they provide a better model for naming include
>files associated with the namespace?  I'm sure they wouldn't want to send
>the message to the programming community that chopping off the .h is a good
>way of resolving name conflicts for files.  Surely putting them in a
>subdirectory std would have been a better idea?

The C and C++ standards make no statements about standard include
files or what their names are, and make no statements whatever
about directories anyplace in the documents. (See for example
16.2 "Source file inclusion" in the C++ draft standard.)

The standards define the spelling of source-language constructs
that make specified sets of declarations available to the program.

It is left entirely up to the implemention how to satisfy
the requirements. Commonly, but not universally, the
#include <...> directive causes a text file of source code
to be read. Commonly, but not universally, the spelling of the
header between <> delimiters is also the spelling of a file name
on the system.

The C++ committee, when specifying spelling of headers, was
faced with a profusion of common file name extensions.  For C++
header files, existing systems used ".h", ".H", ".hh", ".hpp",
".hxx", and probably others I've forgotton about. Standardizing
on one particular extension would have been seen as favoring
one set of implementations (and users of those systems) over
others.  Instead, the commttee decided to specify no extension,
thus affecting all implementations, and all programmers, equally.

C++ implementators, assuming they read actual files as the
implementation of headers, can choose whatever file names
they like, and put them anyplace they like. It would be quite
reasonable for an implementation to continue to use whatever
file naming convention it had been using, and arrange for the
compiler to pick up that file in response to a request for a
standard header. That is, the programmer always writes
 #include <iostream>
to get the correct header on all conforming systems, no
matter what the implementation uses for the actual file
(if it indeed uses a file).

As an extension, an implementation is free to recognize whatever
header spellings they recognized before. As a service to their
customers, I would expect vendors to do something like that.
So if you were used to writing
 #include <iostream.hpp>
your vendor might well continue to support that so your programs
could continue to compile. Allowing such code violates no
provision of the standard.

--
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              ]

>My only gripe is why didn't they provide a better model for naming include
>files associated with the namespace?  I'm sure they wouldn't want to send
>the message to the programming community that chopping off the .h is a good
>way of resolving name conflicts for files.

The standard does not say that the standard headers have to be files. It
says:

  "A  header is not necessarily a source file, nor are the sequences
  delimited by < and > in header names  necessarily  valid  source  file
names"

>Surely putting them in a
>subdirectory std would have been a better idea?

Not all platforms will support the concept of subdirectories in a
hierarchical file structure.
---
[ 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              ]

Doug Harrison wrote:
>
> On 19 Jun 1998 23:05:02 GMT, David R Tribble
> <david.tribble@noSPAM.central.beasys.com> wrote:
>
> >Microsoft, in its usual arrogance, uses the unbelievably lame prefix
> >'C' on all their Foundation Classes names.  It was probably done more
> >out of ignorance than outright hostility.
>
> It isn't just MSFT; Borland does the same thing with OWL, except it
> uses "T". Unfortunately, many people don't realize those prefixes are
> effectively reserved by those libraries, and they tend to use the same
> prefix as whatever library they imprinted on. It doesn't help that the
> "wizards" suggest such names.

When I first started using MFC, I was under the impression that the
leading "C" was meant to differentiate classes from other types of
identifiers; it never occured to me that it was meant to identify MFC
software.
---
[ 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              ]

On 24 Jun 98 09:44:16 GMT, David R Tribble
<david.tribble@noSPAM.central.beasys.com> wrote:

>As P J Plauger pointed out a few months ago in the CUJ, namespaces
>still don't solve one of the problems they were supposed to, that
>being the collision of names in two separate (usually third-party)
>libraries.
>
>Oh sure, you can wrap both libraries into separate namespaces, like
>this:
>    // vendor1.h
>    namespace VendorOne {
>        void foo();
>        ...
>    }
>
>    // vendor2.h
>    namespace vendorTwo {
>        void foo();
>        ...
>    }
>
>But your code still can't easily distiguish between the two foo()
>names.  You still have to change all calls to foo(), adding an
>explicitly namespace prefix:
>    VendorOne::foo();    // Calls VendorOne::foo()

Get used to it. If you think carefully about the problems and
consequences of namespace collisions, I think you'll eventually come
to this conclusion:

The use of names outside the current namespace should always be
qualified**
[**except when taking advantage of Koenig lookup]

Using-directives ("using namespace X") should only be used for
namespace composition. Using-declarations can be used with care at
function scope, but they should usually also be reserved for building
a new namespace from names in other namespaces.

>I've always thought that the renaming capability of Eiffel was a
>clever idea.  It allows you to rename, or alias, a member of a
>class (or class library), giving it a different name entirely.
>This seem to me to be more useful than C++ aliases that are nothing
>more than the original name with an explicit prefix.
>
>Applying the Eiffel concept to C++ would allow something like
>this:
>    #include "vendor1.h"
>    // Leave VendorOne::foo as is
>
>    #include "vendor2.h"
>    namespace VendorTwo {
>        using bar = foo;    // VendorTwo::foo is now called bar
>        ...
>    }
>
>    void myfunc()
>    {
>        foo();     // Calls VendorOne::foo()
>        bar();     // Calls vendorTwo::foo()
>    }
>
>The renaming would only apply during compilation; the real names
>would still be used at link/load time.  It's a little like
>wrapping the call to VendorTwo::foo() inside an inline function
>called bar(), except that it only takes a single 'using' line in
>the code (or project header).

The best way to handle this in C++ is as follows:

    #include "vendor1.h"
    // Leave VendorOne::foo as is

    #include "vendor2.h"
    // Leave VendorTwo::foo as is

    #include "MyNamespace.h"
    namespace MyNamespace
    {
        using VendorOne::foo;
        namespace V2 = VendorTwo;
        ...
    }

   namespace MyNamespace
   {
        void myfunc()
        {
            foo();     // Calls VendorOne::foo()
            V2::foo();     // Calls vendorTwo::foo()
        }
    }

I agree that Eiffel's mechanism is clever, and possibly even useful.
We have something like that for types, with typedef. What I don't
agree with is the (implied) use of using-directives to avoid having to
qualify names.

>While this may still require code changes (after the fact, when
>the two libraries are used by the same source file), the change
>is not as intrusive; I only have to change half my 'foo()' calls
>to 'bar()', and I can leave the other half unchanged.

In the example above, I only have to qualify half my 'foo()' calls
with V2, and I can leave the other half unchanged.

-Dave
---
[ 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> wrote in article <AL8k1.1035$u4.504437@newscene.newscene.com>...
> >Anyway, my point was that someone who really doesn't want to use
> >namespaces, and who really does want the library global, and who
> >really isn't going to be convinced otherwise, should just issue
> >the directive and stop complaining.
>
> Complaining about such issues is part of the job of those who comment
> publicly on language design and standardization.

Indeed.  But I get a strong sense of: "the committee has foisted
this awful new feature on us, and we have to use it because the
standard library is in a namespace."  So I repeat that if you don't
want to use qualified names the feature was designed with a simple
escape hatch.  You may still think the feature awful, but at worst
it costs you one line in each source file that includes a standard
header.

Greg Colvin


[ 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              ]

On 24 Jun 1998 15:26:50 GMT, "Al Stevens" <alstevens@midifitz.com>
wrote:


>Only because you are using (saddled with) the namespace feature in the first
>place. My argument is that you don't need namespaces when you judiciously
>use prefixes. You seem to be saying that you don't need prefixes because you
>have namespaces. We're going round in circles here.

I think most people are not seriously considering your prefix
suggestion because namespaces are a superior tool for avoiding name
collisions. You can work with short, manageable aliases but link
against long, unweildy namespace names. You can avoid qualifying names
altogether when they come from the same namespace you're coding in
(this is very common). These qualities make namespaces a more
manageable way to handle the problem. Prefixes force you to choose
between security and readability (a short prefix is more likely to
collide; a longere prefix obfuscates). In my experience, the more
difficult it is to read the code I'm writing, the harder it is to
reason about while I'm writing it. That's a major productivity drain.

>I think all the standard library names should be in the global namespace
>anyway. After all, it's the Standard Library. No one should be using those
>names. Library writers could use the old C underscore convention for
>whatever external names they need. That works fine as long as everyone
>acknowledges the convention. Unless, of course, you think the standard
>library will grow substantially in the future and need a bunch more
>user-visible names that might collide. I don't think it will or should.

Probably the most-requested addition to the library standard that I've
heard is a standard GUI library. I think we will have one eventually.
If so, it will certainly represent a large number of new names.
Even if the library only grows a little in the future, namespace std
will protect existing code from collisions.


[ 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              ]

Nathan Myers wrote:

> Tom McKearney<me@nospam.com> wrote:
> >You can easily do the following:
> >
> >namespace vendor
> >{
> >#include "VendorHeader1.h"
> >#include "VendorHeader2.h"
> >}
> >
> >and this way there are no surprises and you always know where your
> >code came from.  It also serves as a useful documentation tool.
>
> Sorry, this doesn't work _at all_.
>
> Typical library headers include system headers:
>
>   // VendorHeader1.h
>   #include <stddef.h>
>   ...  // stuff using size_t
>
> What happens when this gets wrapped in a namespace?  Now there is
> no ::size_t or std::size_t; instead, you have vendor::size_t and/or
> vendor::std::size_t.

This leads me to a question. Is there a way to invoke, or revert to, the
global namespace? It's seems that there needs to be a way of insuring that a
name is in the global namespace. For example:

namespace vendor {
  namespace <global> {
   void foo();
  }
}

This would result in the fully qualified name "::foo", even though it's been
nested inside the vendor namespace.

On the same note, it seems that a namespace can always be nested (perhaps
hidden) inside another namespace. Is there no way to prevent this? Should
there be?

Just thinking out loud ...

--
+ Marcus Barnes, Technical Staff        mailto:marcus@multigen.com +
+ Multigen Inc.                         http://www.multigen.com    +
+ 550 S. Winchester Blvd.               phoneto:1-408-556-2654     +
+ Suite 500 San Jose CA 95128           faxto:1-408-261-4103       +





[ 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 <uT8k1.1037$u4.509829@newscene.newscene.com>,
  "Al Stevens" <alstevens@midifitz.com> wrote:

> >By the way, a big advantage to namespaces over prefixing is that its much
> >easier to do it consistently. On most projects I've worked on, 100%
> >compliance with prefixing standards has been very elusive.
>
> Which is the best argument I've heard here for namespaces over prefixes and
> a sad commentary on the commitment to quality of some programmers. If class
> designers use prefixes judiciously, programmers have no choice but to
> comply. If class designers simply refuse to adhere to a project's
> guidelines, then I guess we need a language feature to encourage them to be
> better programmers.

Whoa, below the belt!

One could just as well argue that classes aren't neccesary.  Show me a class
and a usage of that class, and I can show you a struct and a valid usage of
that struct in C.

    Constructors?          Call the initialization function.

    Copy constructor?      Call the copy function.

    Destructors?           Call the termination function.

    Assignment?            Call the assign function.

    Member functions?      Another case where we need prefixes.

    Overloaded functions?  A case for suffixes.  Instead of x.add(5) we
        get T_add_int(&x,5), which is more readable to a C programmer.

    Overloaded operators?  Call the equivalent functions with real names,
        dang it!  *Real* programmers can use "plus" instead of "operator+"!

    Virtual functions?     I'll even accomplish that, by making the first
        member of the struct a pointer to a table of function pointers, and
        I'll use enumerations to create offsets in the table.  This is the
        same thing as the "vtable" that most C++ compilers do under the
        covers, but my motto for the day is "never do anything under the
        covers that you wouldn't do in the middle of the street."

    Private data members?  Still another case for prefixes.  I'll use names
        starting with "internal_" and add some comments that say it better
        not be used from outside the class!  See my motto for the day, above.

    Inheritance?           Just make a Base structure the first data element
        in struct Derived, and use macro #defines to make Derived_func1 the
        same as Base_func1.

    Multiple inheritance?  Much easier than in C++, because "ambiguous
        function calls" are never a problem.  Just be sure to #define the
        macro correctly and everything works!

The only reason a good C programmer would ever violate these rules, is if they
were not aware of them, right?  So I'll use extensive documentation and
everything will be fine.  And if anybody ever does violate these rules, I'll
whine about how we must need a language feature to be good programmers, since
we can't manage it ourselves.

But then someone will accuse me of being unfair, and I'll agree with them,
and wake up and return to the real world, which in my case means using C++
with all sorts of rules designed to protect me.  Programmers can still break
the rules, of course, but it takes effort.
    // Create a T without calling the constructor
    T &t = *(T*)new char[sizeof(T)];
Programmers can do this right now, but if they do it's legal (in 31 of the
50 United States) to shoot them, because they deserve it.  There is NO WAY
to do this kind of thing accidentally!


-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/   Now offering spam-free web-based newsreading


[ 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:

>>I'd rather group local definitions inside a single unnamed namespace
>>than preface those definition with "static". I think providing an
>>alternative to per-definition clutter is a clear win, and the fewer
>>meanings for a keyword, the better. I think "static class" would only
>>compound the strangeness.

>I don't think it's that clear. "static struct" worked fine for years.

I don't know what you mean by it formerly "working".

In the construct
 static struct S { ... };
the keyword "static" has no meaning.

In the construct
 static struct S { ... } s;
"static" applies to object "s", not to the type "S".

Even if we extended "static" to mean something helpful when
applied to a type, it doesn't solve the problem of two
static structs with the same name in different headers.

Putting struct S in a namespace has an effect you cannot get
otherwise: the name will not collide with anything in any other
namespace.

--
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              ]

>When I first started using MFC, I was under the impression that the
>leading "C" was meant to differentiate classes from other types of
>identifiers; it never occured to me that it was meant to identify MFC
>software.


Your impression is correct. The C is part of the prefix notations that
Microsoft use to identify the type of the name and whether it is a class,
pointer, reference, member, and so on. According to their docs, "All class
names begin with C, as in CMyClass.

For some reason, function names are exempt from that notational standard.



[ 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 don't know what you mean by it formerly "working".


Yeah, you're right. That was a silly example, contrived with the absense of
forethought. My C compiler does not complain about static struct S { }; but
the same C++ compiler (same compiler suite) produces a diagnostic that the
static is ignored, causing me to draw a false conclusion.



[ 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              ]

Fergus Henderson wrote:
>
>
> Of course it is.  But that's exactly what Bill Dugan was asking for --
> he wanted to know whether the standard *prevented* implementations
> from supporting that kind of thing.

The standard doesn't prevent implementations from supporting anything at
all. The standard only attempts to define what a conforming program is,
and what the meaning of that program is. If you want to write code that
assumes that a name that occurs at global scope and the same name
occuring inside a namespace refer to the same object you are not writing
C++. An implementation that supports such a construct is not compiling
C++.

> So, I concede that the exact syntax above won't work, but there's no
> reason why the general technique couldn't be made to work.  The only
> think it won't handle, of course, is macros.

While you're at it, you can recognize the pattern that adding two
integers produces in object files and change the code, thus permitting
overloading the addition operator for integers. <g>


[ 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              ]

On 24 Jun 1998 15:26:50 GMT, "Al Stevens" <alstevens@midifitz.com>
wrote:

>I don't think it's that clear. "static struct" worked fine for years. Just
>because you prefer to use a namespace doesn't mean we didn't already have a
>mechanism that would have worked if it had not been removed from the
>language.

Could you expand on that, please? I've never heard of using "static
struct" to force internal linkage of a class.

And I do understand that what you suggest could have been made to
work, but I've already explained why I think it represents an inferior
solution, so I won't belabor the point further.

>>Inside my namespace scope, I know that when I write "A", I'm referring
>>to my A.
>
>You are fortunate that you have to look at only your own code.

Actually, my code uses several libraries I didn't write.

>> I don't see what there is to wonder about.
>
>Only because you are using (saddled with) the namespace feature in the first
>place. My argument is that you don't need namespaces when you judiciously
>use prefixes. You seem to be saying that you don't need prefixes because you
>have namespaces. We're going round in circles here.

I don't disagree that prefixes address many of the problems addressed
by namespaces. I just think that in comparison, namespaces are less
clumsy, more natural, more convenient, and more powerful. What I
disagree with is the notion that the prefix concept is good enough to
render namespaces an unworthy addition to C++.

>I have not read the goals. I do not know that they are formally stated
>anywhere outside of the minutes of committee deliberations. As far as I
>know, the committee was not required to conduct a formal requirements
>analysis with a published result, a grave omission given the committee's
>self-appointed mandate to innovate language and library design.

You might want to read chapter 17, "Namespaces", in Stroustrup's
"Design and Evolution of C++".

>I think all the standard library names should be in the global namespace
>anyway. After all, it's the Standard Library. No one should be using those
>names. Library writers could use the old C underscore convention for
>whatever external names they need. That works fine as long as everyone
>acknowledges the convention. Unless, of course, you think the standard
>library will grow substantially in the future and need a bunch more
>user-visible names that might collide. I don't think it will or should.

Using namespaces means you don't have to consult a list of forbidden
names before choosing the most natural name for an entity. The STL
introduced many new global names that could've conflicted with
existing programs; wrapping the standard library in namespace std
ensures they don't. If C had namespaces and placed its standard
library in one, and it wasn't so macro-happy, then there would have
been no need for rules concerning use of names beginning with
"str[a-z]" or "mem[a-z]" in translation units that include <string.h>,
or names beginning with "E[0-9A-Z]" in translation units that include
<errno.h>, etc. That's obscure, and in general, it's absurd, and it
can be a real nuisance. I don't have any problem with standards
reserving names beginning with the underscore, for example, but beyond
that, let me have my first choice of names, please.

--
Doug Harrison
dHarrison@worldnet.att.net


[ 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              ]

>Indeed.  But I get a strong sense of: "the committee has foisted
>this awful new feature on us, and we have to use it because the
>standard library is in a namespace."

Allow me to rephrase your interpretation:  "the committee has foisted this
untested new feature on us and has used the standard library as their
breadboard and the community of programmers as their alpha testers."

I do not think the namespace feature is awful. I think it has wonderful
potential. But I think we should have come by it by way of more conservative
measures before it became a mandated language feature. I think, however,
that whenever someone suggests such a thing, the wagons start to circle.



[ 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              ]

>Whoa, below the belt!

Now,  let's not overreact.

>One could just as well argue that classes aren't neccesary.  Show me a
class
>and a usage of that class, and I can show you a struct and a valid usage of
>that struct in C.

Or in assembly language. Or in machine language. Or in binary.

>    Overloaded operators?  Call the equivalent functions with real names,
dang it!

I like that suggestion!

>And if anybody ever does violate these rules, I'll
>whine about how we must need a language feature to be good programmers,
since
>we can't manage it ourselves.

If you truly believe that my arguments are just whining, then perhaps we
should agree to disagree and move on to other subjects. I'll take your
inclination to so characterize into consideration before posting again.



[ 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 think most people are not seriously considering your prefix
>suggestion because namespaces are a superior tool for avoiding name
>collisions.

I'm losing focus here. I don't have a prefix suggestion. I do not suggest
using prefixes instead of namespaces or that prefixes are in any way a
superior solution. My point is that prefixes adequately solved the problems
that namespaces address because experience indicates that the namespace
problem is relatively small compared to the number of projects fielded
without such problems. What I'm learning from the posters here is that if
you have a major namespace problem, it's the biggest thing in your life. If
you've never had a significant namespace problem (I have not in 40 years of
programming on projects of all sizes), it's not your highest priority. We
did not need a new feature, particularly one with all the hidden
implications that have been described here. Now that we have it, I'll use
it.

>Probably the most-requested addition to the library standard that I've
>heard is a standard GUI library. I think we will have one eventually.

Perhaps when we have a standard GUI. Some people think we already have one.
The issue has already been addressed by frameworks that offer cross-platform
development. The problem is that you have to code to the lowest common
denominator, and hardly anybody wants to do that.



[ 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              ]

Doug Harrison wrote:

> On 19 Jun 1998 17:22:16 GMT, "Al Stevens" <alstevens@midifitz.com>
> wrote:
>
> >Only because C++ does not support:
> >
> >static class ForUseOnlyByThisTranslationUnit {};
> >
> >without an instance name included. If it did as C does with structs, static
> >and file scope, a time-tested legacy concept, 20 years in the proving,
> >instead of being deprecated, would cover what the unnamed namespace does
> >now.
>
> I'd rather group local definitions inside a single unnamed namespace
> than preface those definition with "static". I think providing an
> alternative to per-definition clutter is a clear win, and the fewer
> meanings for a keyword, the better. I think "static class" would only
> compound the strangeness.

One concern I have for unnamed namespaces is linkage overhead. Everything still
has external linkage, as I understand it, and this puts a greater burden on the
linker. Using the static keyword to indicate internal linkage allows the
compiler to do the job entirely.

Deprecating the use of "static" to indicate internal linkage seems wrong, unless
it's legal for a compiler to treat the unnamed namespace as a directive for
internal linkage?

Regards.

--
+ Marcus Barnes, Technical Staff        mailto:marcus@multigen.com +
+ Multigen Inc.                         http://www.multigen.com    +
+ 550 S. Winchester Blvd.               phoneto:1-408-556-2654     +
+ Suite 500 San Jose CA 95128           faxto:1-408-261-4103       +
---
[ 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 <6mqqcn$543$1@nnrp1.dejanews.com>,
  AlanStokes@my-dejanews.com wrote:
>
> Better choices might be domain names (globally unique, but may get re-used) or
> OIDs (which do have a central registry but are a bit unreadable - anyone for
> "namespace iso_org_dod_internet_private_enterprise_2561;"?).

Sure!  Provided it looks like this:

    // FastFood.h
    #ifndef FASTFOOD_H_INCLUDED
    #define FASTFOOD_H_INCLUDED
    namespace iso_org_dod_internet_private_enterprise_2561 {
        class Customer { };
        class Employee { };
    };
    #ifndef FASTFOOD_LONG_NAMESPACE
        namespace FastFood = iso_org_dod_internet_private_enterprise_2561;
    #endif // FASTFOOD_LONG_NAMESPACE
    #endif // FASTFOOD_H_INCLUDED

Now I can use the header like this:
    #include "FastFood.h" // Automatically uses namespace alias FastFood
    FastFood::Employee owner("AllanW");
    int main() {
        FastFood::Customer c("Joe Public");
        e.feed(c);
    }

The reason that this is better than specifying namespace FastFood is that,
if a namespace collision DOES happen, I can fix it by including the file
this way instead:

    // Here we use the Private Enterprise 2561 FastFood classes
    #define FASTFOOD_LONG_NAMESPACE // Don't use any namespace alias
    #include "2561/FastFood.h"  // Our FastFood-type stuff
    // Now we define our own namespace alias:
    namespace FastFood1 = iso_org_dod_internet_private_enterprise_2561;

    // Here we use the Public Menu FastFood classes, even though their
    // default namespace alias would conflict with our own.  Presumably
    // this other library has it's own method of specifying the short
    // namespace alias.  The mechanism doesn't need to be the same one
    // we use, just so long as it can be done.
    #define FASTFOOD_USE_NAMESPACE_ALIAS FastFood2
    #include "menu/FastFood.h"  // Some other FastFood-type stuff
    // Technically, we don't need to switch namespace aliases for both
    // classes, just one.  Realistically, doing this would confuse the
    // maintenance programmer, who, when she sees this:
    //    FastFood::money a(123.45);
    // might assume that FastFood referred to the wrong library.
    // Therefore, as a matter of style, whenever we must override the
    // default namespace alias for a library, we override all of the
    // other cases of that name as well.

    // Now we can use the namespace aliases and not worry about what the
    // "usual" short name is, and yet everything will link together properly:
    FastFood1::Employee owner("AllanW");
    FastFood2::MenuItem food("Hamburger");
    int main() {
        FastFood1::Customer c("Joe Public");
        e.feed(c);
        food.consume(c.name()); // Yum!
    }


-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/   Now offering spam-free web-based newsreading
---
[ 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              ]

>One concern I have for unnamed namespaces is linkage overhead. Everything
still
>has external linkage, as I understand it, and this puts a greater burden on
the
>linker. Using the static keyword to indicate internal linkage allows the
>compiler to do the job entirely.

I'm not sure how that could be useful. Names in the unnamed namespace have a
hidden, unique namespace name. Even if the namespace-qualified names had
external linkage, how could anything outside the translation unit access
them as external names. You'd have to know the compiler-generated hidden
unnamed namespace.



[ 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              ]

On 25 Jun 1998 05:35:22 GMT, "Al Stevens" <alstevens@midifitz.com>
wrote:

>>I think most people are not seriously considering your prefix
>>suggestion because namespaces are a superior tool for avoiding name
>>collisions.
>
>I'm losing focus here. I don't have a prefix suggestion. I do not suggest
>using prefixes instead of namespaces or that prefixes are in any way a
>superior solution. My point is that prefixes adequately solved the problems
>that namespaces address because experience...

YOUR experience

>...indicates that the namespace
>problem is relatively small compared to the number of projects fielded
>without such problems. What I'm learning from the posters here is that if
>you have a major namespace problem, it's the biggest thing in your life. If
>you've never had a significant namespace problem (I have not in 40 years of
>programming on projects of all sizes), it's not your highest priority. We
>did not need a new feature,

YOU didn't need the feature

>particularly one with all the hidden
>implications that have been described here. Now that we have it, I'll use
>it.

Do what you will; just please remember that your personal experience,
though long, may be limited.

>>Probably the most-requested addition to the library standard that I've
>>heard is a standard GUI library. I think we will have one eventually.
>
>Perhaps when we have a standard GUI. Some people think we already have one.
>The issue has already been addressed by frameworks that offer cross-platform
>development. The problem is that you have to code to the lowest common
>denominator, and hardly anybody wants to do that.

I think there may be other, previously unexplored ways to address
those problems. But that's another thread.


[ 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              ]

Marcus Barnes wrote:
>
> Doug Harrison wrote:
>
> > On 19 Jun 1998 17:22:16 GMT, "Al Stevens" <alstevens@midifitz.com>
> > wrote:
> >
> > >Only because C++ does not support:
> > >
> > >static class ForUseOnlyByThisTranslationUnit {};
> > >
> > >without an instance name included. If it did as C does with structs, static
> > >and file scope, a time-tested legacy concept, 20 years in the proving,
> > >instead of being deprecated, would cover what the unnamed namespace does
> > >now.
> >
> > I'd rather group local definitions inside a single unnamed namespace
> > than preface those definition with "static". I think providing an
> > alternative to per-definition clutter is a clear win, and the fewer
> > meanings for a keyword, the better. I think "static class" would only
> > compound the strangeness.
>
> One concern I have for unnamed namespaces is linkage overhead. Everything still
> has external linkage, as I understand it, and this puts a greater burden on the
> linker. Using the static keyword to indicate internal linkage allows the
> compiler to do the job entirely.
>
> Deprecating the use of "static" to indicate internal linkage seems wrong, unless
> it's legal for a compiler to treat the unnamed namespace as a directive for
> internal linkage?

Shouldn't the compiler be allowed to do this under the as-if rule?
Internal and external linkage IMHO cannot be distinguished from
a standard conforming program in any other way than trying to access
the symbol from another translation unit. But you cannot do that
for symbols in unnamed namespaces.


[ 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 <01bd9b25$3103f4c0$01010101@gcolvin-hpc>,
Greg Colvin <spam@me.not> wrote:
>
>
>Jim Cobban wrote:
>> ...  The problem solved by namespaces
>> applies only to a small proportion of even very large projects.  It does not
>> make sense to make the use of namespaces mandatory even in trivial programs,
>> such as hello world in order to solve the problems of a handful of (in my
>> opinion) poorly designed projects.  Let that minority who have the problem
>> use namespaces, and leave the rest of us alone with our working code.
>
>In what way are you not left alone with your working code?

The way the standard is written, which I agree is different from what the
compiler vendors are actually delivering, all references to functions in the
standard library must be prefixed by std:: unless I do something like using
namespace std; which is deprecated.  We are currently running Gnu C++ 2.7.2
in which namespaces are not supported, but I dread what happens when we try
to move our millions of lines of code to a level of the compiler which
complies to the namespace specification.  Everything I have read insists
that we will have to do SOMETHING to every single source file to accomodate
this change to the language.  Frankly we have better things to spend our
time on, like delivering useful functionality to our customers.

I simply do not understand why we, with millions of lines of code as I said,
much of which comes from imported libraries and other licensed code sources,
have almost no problems avoiding conflicts which the authors of this concept
insist are unavoidable.

--
Jim Cobban   |  jcobban@nortel.ca                   |  Phone: (613) 763-8013
Nortel (MCS) |                                      |  FAX:   (613) 763-5199
---
[ 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              ]

Marcus Barnes wrote:

[...]

> This leads me to a question. Is there a way to invoke, or revert to, the
> global namespace? It's seems that there needs to be a way of insuring that a
> name is in the global namespace. For example:
>
> namespace vendor {
>   namespace <global> {
>    void foo();
>   }
> }
>
> This would result in the fully qualified name "::foo", even though it's been
> nested inside the vendor namespace.

There is a way: Close your namespace and reopen it:

namespace vendor
{
  void f(); // gets vendor::f()
} // temporarily close the namespace

void foo(); // gets ::foo();

namespace vendor // reopen the namespace
{
  void g(); // gets vendor::g()

  void f()  // definition of vendor::f() declared above
  {
    ::foo(); // calls global foo() declared above
    g();     // calls vendor::g() declared above
  }
}

[...]
---
[ 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) wrote:
: That looks like a compiler bug. The sqrt function is supposed to be the same
: function in both the std and the global namespace. Unless, of course, you
: work for Microsoft.

The draft standard says in section "7.3.1.1 Library contents":
-----
2 All library entities except macros, operator new and  operator  delete
  are  defined  within  the  namespace  std  or namespaces nested within
  namespace std.
-----

Hence there is definitely a std::sqrt (and actually, many of them given
overloading). So code that was using the C++ math library and some other
library that defined a similar sqrt will not compile even if one does a
 using namespace std;
after including the C++ math library. (It would have compiled before,
calling one or the other of the sqrt functions depending on the linker and
its arguments. As such this is a transition problem that is not solved by
Greg Colvin's suggestion. I don't mean to imply that this is a big deal,
merely that the advice is not as universal as claimed.)

(Metrowerks may have a problem in that it looks tricky to include the C
(not C++) math library in a C++ program. But I'll have to investigate
that. I don't think that would present any standard conformance issues
though.)

[Thanks for the description of aliases. I found the relevant text in the
draft standard.]

: There is a discussion of such a thing earlier in this thread. I consider it
: to be a kludge on a kludge.

[Re: a namespace aware linker.]

If library vendors are good about using long identifiers (I propose GUIDs
myself, but I'm sure many of you will retch at that) then it may not be
necessary. But still, if you've got two libraries that conflict, a tool
that fixes it would be a godsend. (Hell, for dealing with old C libraries
alone, this tool would be useful. I'd be all over it right now for
disambiguating Win32 (Microsoft Windows) identifiers from QTML (Apple
Quicktime Media Layer).)

I was very glad to hear about namespaces making it into C++ as I considered
the lack of identifier management to be a great problem for large software
projects. I sort of saw it from a Modula 3 point of view. Namespaces
aren't modules, but they're a lot better than nothing.

-Z-
---
[ 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              ]

David R Tribble <david.tribble@noSPAM.central.beasys.com> wrote:
>
>As P J Plauger pointed out a few months ago in the CUJ, namespaces
>still don't solve one of the problems they were supposed to, that
>being the collision of names in two separate (usually third-party)
>libraries.

That problem is unsolvable.  If names collide, they collide; the
best the language can do is provide the tools to let you resolve
the collision.  The C++ namespace does that.

>I've always thought that the renaming capability of Eiffel was a
>clever idea.  It allows you to rename, or alias, a member of a
>class (or class library), giving it a different name entirely.
>This seem to me to be more useful than C++ aliases that are nothing
>more than the original name with an explicit prefix.

Besides namespace aliases, C++ has inline functions and typedefs.
Combined, these are more powerful than Eiffel's limited aliasing
mechanism.  (Alas, we don't have template typedefs yet, which would
complete the picture.)

--
Nathan Myers
ncm@nospam.cantrip.org  http://www.cantrip.org/
---
[ 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              ]

<AlanStokes@my-dejanews.com> wrote:
>
>Better choices might be domain names (globally unique, but may get re-used) or
>OIDs (which do have a central registry but are a bit unreadable - anyone for
>"namespace iso_org_dod_internet_private_enterprise_2561;"?).

This way madness lies.  Can you imagine going to court to defend
your continued use of an identifier (depended upon by your customers'
programs) because somebody else bought up a division of your company
and now owns the OID?

--
Nathan Myers
ncm@nospam.cantrip.org  http://www.cantrip.org/
---
[ 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> wrote:
>Where does it all end?

It ends with people using namespaces properly, and avoiding the problems
that all the expedients and workarounds try to solve, badly.

--
Nathan Myers
ncm@nospam.cantrip.org  http://www.cantrip.org/
---
[ 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              ]

On 24 Jun 98 17:15:40 GMT, James Kuyper <kuyper@wizard.net> wrote:

>When I first started using MFC, I was under the impression that the
>leading "C" was meant to differentiate classes from other types of
>identifiers; it never occured to me that it was meant to identify MFC
>software.

It's sort of insidious that way. I think MFC does indeed use it for
that purpose, and OWL uses "T" to indicate "type". However, if MFC
wants to introduce a class named "Widget", how do you think MFC will
spell it? That's easy: "CWidget". Woe to him who had already written a
class called CWidget!

--
Doug Harrison
dHarrison@worldnet.att.net
---
[ 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:
>
> Consider this discussion, folks.

OK, I've considered it. In fact, I considered it silly.

> We have this new namespace feature thrust
> upon us that no one has any experience with and the implications of which no
> one really understands. The feature creates problems much bigger than those
> that it solves

This discussion showed no such thing.

> so that we have to discuss contriving "header file munging"
> and "library file munging" tools to solve namespace problems.

No, we don't "have to discuss" these things. Some people like to invent
complex solutions to non-existent problems. (hypothetically, that is...)
That doesn't make the perceived problems real, nor does it make the
invented solutions likely to be seen in practice.

> Who knows what
> problems will arise from the munging approach? Complexity built on top of
> complexity. Where does it all end?

It ends right where it started, with no such work being done.
---
[ 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:

> I think all the standard library names should be in the global namespace
> anyway. After all, it's the Standard Library. No one should be using those
> names. Library writers could use the old C underscore convention for
> whatever external names they need. That works fine as long as everyone
> acknowledges the convention. Unless, of course, you think the standard
> library will grow substantially in the future and need a bunch more
> user-visible names that might collide. I don't think it will or should.

The standard library names may have been used in code prior to the standard
library being created. I think this is the reason that the standard library was
put into the std::  namespace. I know of at least one case of this, where a
class called "string" by a major vendor existed before the standard library was
created, and I imagine others may have existed. It may be argued that other
vendors should have been required to put any of their conflicting names into a
namespace and that the standard library should have been put into the global
namespace, but this puts both an onus on other already created code to change.
This also may not have been possible if libraries and and object files existed,
along wth their header files, and the vendor was no longer around. All in all I
think that the C++ standards committee did the wise thing by putting the
standard library in the std:: namespace.
---
[ 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 <MMhk1.760$sV4.190857@newscene.newscene.com>,
  "Al Stevens" <alstevens@midifitz.com> wrote:
>
> ... if you have a major namespace problem, it's the biggest thing in
> your life. If you've never had a significant namespace problem (I have
> not in 40 years of programming on projects of all sizes), it's not your
> highest priority.

Are you suggesting that you've been programming in C++ since 1958?

(Namespaces are unique to C++)


-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/   Now offering spam-free web-based newsreading
---
[ 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              ]

>YOUR experience

.... and the experience of many of my associates.

>YOU didn't need the feature

Ditto. You seem to presume that I am somehow distanced from other
programmers. Is this because we disagree? Are you that convinced that every
other programmer in the world had the opposite experience and sorely needed
the feature? Based on what? Or is this just getting personal? If so, I
surrender.
---
[ 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:

[...]

> >>No, it relieves me from having to wonder which A I am looking at when I
> read
> >>the code.
> >
> >Inside my namespace scope, I know that when I write "A", I'm referring
> >to my A.
>
> You are fortunate that you have to look at only your own code.
>

Yes, that's exactly the advantage of namespaces: As long as I don't
explicitly use anything else, I only have to look at my own code.
And if I use anything else, I just have to look on what I use.

[...]
---
[ 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:
>
> Complaining about such issues is part of the job of those who comment
> publicly on language design and standardization.

Such complaints would have been much more helpful if they had been
raised during standardization instead of after it was completed.
---
[ 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              ]

Greg Colvin wrote:
>
> James Kuyper <kuyper@wizard.net> wrote in article
> <358A89E5.167E@wizard.net>...
> >
> > Based upon Section 1.3, paragraph 2, a conforming C++ implementation is
> > not required to compile any program. Any program, no matter how short,
> > may be rejected as exceeding the resource limits of an implementation.
> > I thought the conformance requirements for C9X were lax, but the
> > conformance requirements for C++ are a joke.  Of course, once an
> > implementation does agree to do something with a program, the
> > requirements on what it does get a lot more meaningful.
>
> It's no joke.  The trouble with specifying any actual minimum is
> that it will become treated as a maximum.  That is, if the standard
> says that all implementations must support at least 31 characters
> in identifiers, you can be sure that some corporate coding standards
> will say that "because the standard does not guarantee support for
> identifiers over 31 characters, no identifier shall exceed 31
> characters" and so on.  I'm currently trying to code in a subset of

Sounds like a wise practice to me. What's your problem with it?

> ANSI C that is hamstrung in just that way, and my employer even has
> their own lint program to be sure I don't stray  By not imposing any
> such minima, we give implementors and code style Nazi's no excuse for
> imposing arbitrary maxima.

Call me a code style Nazi, then. I've seen how poorly most programmers
write their code. Without some such automated code checking system,
porting their code between implementations would be even more of a
nightmare than it already is. in the absence of standard limits that
mean something, there is no way I can write my code so as to guarantee
portability to an arbitrary conforming implementation. Any code I write
that I might otherwise hope to be portable may need re-coding in
unpredictable ways when actually ported to a new implementation. It's
bad enough that I have to do this to cope with the behavior that is
explicitly implementation-defined; it becomes a nightmare when I have to
cope with unpredictable resource limits.


[ 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 originally wrote:
>...  You can trademark the name of a product or a company,
>and you can copyright a set of assembler mnemonics, but you can't
>trademark a variable or typedef name.  If that were the case, some
>bozo would have tried to trademark the name "x" (as a variable name)
>a long time ago.  Kind of like trademarking the word "love" for
>paperback novels.

[Several comments then ensued about trademark granting and protection.]

Daniel Parker wrote:
> McDonald's is actually a very weak trademark.  ...
> But McDonald's is also on weaker grounds in preventing other people
> from using the name.

Which was my original point, even though I didn't make it clear.
You may indeed trademark just about any name you wish, as long as it
isn't confusable with an existing trademark in a similar business, and
more specifically, as long as the courts uphold it as a unique
trademark.

Preventing the *use* of a trademark is a different story, and this is
where we return to the discussion of typedef names and namespace names.
McDonalds cannot legally prevent me from using a namespace of
'McDonalds' in my software product, for several reasons.  Number one
on the list is that I'm not using the name as a trademark or as
advertising, so I'm not encroaching upon illegal use of the name
(as long as I don't call my software product 'McDonalds', since this
would put me on shakier ground).  (The same holds when I ask the guy
behind the McDonalds counter for a 'coke'; 'Coke' is a trademarked name,
but I'm not using it in any way that consitutes infringement.)

So the door is open for using company names, product names, internet
domain names, etc., for namespace names.  Especially if the company
using the name owns the name to begin with.

-- David R. Tribble, david.tribble@central.beasys.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              ]

Fergus Henderson wrote:
>
> wkdugan@ix.netcom.com (Bill Dugan) writes:
> >Pete Becker <petebecker@acm.org> wrote:
> >>Tom McKearney wrote:
> >>> You can easily do the following:
> >>>
> >>> namespace vendor {
> >>> #include "VendorHeader1.h"
> >>> #include "VendorHeader2.h"
> >>> }
> >>
> >>Unfortunately, this doesn't work. The library itself has to be built
> >>with namespaces, too. Otherwise it won't link.
> >
> >Is there something in the standard that forces this, or is it an
> >avoidable byproduct of current implementation techniques?
>
> The latter.  It would be quite straight-forward to either

No, the former. <g>

>
>         (a) provide a separate tool for manipulating object files and
>             libraries, allowing one to add, remove, or rename namespace
>             prefixes

Yes, that is conceivable. But it's outside the scope of the language
definition.

> or
>         (b) extend the linker with support for wrapping up libraries
>             in namespaces on-the-fly during linking (perhaps by using
>             an option such as `-l vendor::lib' instead of `-l lib')

This would almost certainly be disastrous. See the example that I gave
in my other message: when you use the same name inside a namespace and
outside a namespace it means two different things. You can't just stomp
it into a namespace and expect your program to do the same thing that it
used to do.


[ 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              ]

James Kuyper <kuyper@wizard.net> wrote in article <358E7B1D.2781@wizard.net>...
> Greg Colvin wrote:
> >
> > James Kuyper <kuyper@wizard.net> wrote in article
> > <358A89E5.167E@wizard.net>...
> > >
> > > Based upon Section 1.3, paragraph 2, a conforming C++ implementation is
> > > not required to compile any program. Any program, no matter how short,
> > > may be rejected as exceeding the resource limits of an implementation.
> > > I thought the conformance requirements for C9X were lax, but the
> > > conformance requirements for C++ are a joke.  Of course, once an
> > > implementation does agree to do something with a program, the
> > > requirements on what it does get a lot more meaningful.
> >
> > It's no joke.  The trouble with specifying any actual minimum is
> > that it will become treated as a maximum.  That is, if the standard
> > says that all implementations must support at least 31 characters
> > in identifiers, you can be sure that some corporate coding standards
> > will say that "because the standard does not guarantee support for
> > identifiers over 31 characters, no identifier shall exceed 31
> > characters" and so on.  I'm currently trying to code in a subset of
>
> Sounds like a wise practice to me. What's your problem with it?

Thirty-one I can (almost) live with.  Eight is very hard.  And
that's just a start.  Right now we are forced to code to the
lowest limits that work on all the many platforms we support, and
those are very low indeed.  The result is that all identifiers
begin with an inscrutable three or four character prefix, with
only few characters left to hint at the meaning of the function.
And header files are restricted to just six characters, so there is
no guessing what they are for from their name.  It's awful, believe
me.  For much of our code we have given up writing in C at all.
Instead we have a C macro system that conforms to all the limits,
and we use Scheme and Java compilers to generate the C.

My preference would be to simply conform to the Standard, without
arbitrary limits, and deal with lousy compilers only as necessary.
How?  By finding a quality compiler for that platform if possible,
or by writing scripts to create short names if necessary.

> > ANSI C that is hamstrung in just that way, and my employer even has
> > their own lint program to be sure I don't stray  By not imposing any
> > such minima, we give implementors and code style Nazi's no excuse for
> > imposing arbitrary maxima.
>
> Call me a code style Nazi, then. I've seen how poorly most programmers
> write their code. Without some such automated code checking system,
> porting their code between implementations would be even more of a
> nightmare than it already is. in the absence of standard limits that
> mean something, there is no way I can write my code so as to guarantee
> portability to an arbitrary conforming implementation. Any code I write
> that I might otherwise hope to be portable may need re-coding in
> unpredictable ways when actually ported to a new implementation. It's
> bad enough that I have to do this to cope with the behavior that is
> explicitly implementation-defined; it becomes a nightmare when I have to
> cope with unpredictable resource limits.

I don't object to standards, I've devoted years now to writing
them.  But arbitrary minima are of no help.  The C standard simply
says that an implementation shall accept at least one program that
meets all the minima, so keeping all your code within the minima
guarantees you nothing.  For modern compilers the only real limit
is available memory, not any countable syntactic category.  And that
limit can be very large. We have only file that gets close to
breaking it, and that is a 3 megabyte byte C file which is
generated from 600 kilobytes of Scheme files.

And call me a code-style Anarchist, but I've never bought the
argument that code is improved by imposing arbitrary limits,
and refuse to believe that any automatable criteria can actually
ensure quality engineering.  Let the programmer use the full power
of the available tools, and let a culture of quality and open
review take care of the rest.



[ 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:
> I haven't really had any namespace problems. I haven't had any
> problems that needed namespace solutions either. Lots of posts in this
> thread ... clearly
> indicate that the community does not have enough experience with this
> feature to say except through intuition how well the feature is going
> to work and how it is going to help.
> The jury is still out. That is the risk you take when you expand a
> standardization charter to include language invention.

Indeed.  I'm curious as to whether POSIX will eventually place all of
their system names into a separate namespace (perhaps 'sys::' or
'posix::'?).  It would be nice, even in light of the transition pains
it would create, because it's a good long-term solution.

Or will POSIX place all its names into the 'std::' namespace (which
appears to be reserved only for the C++ language and ISO library
itself)?

Or, heaven forbid, will POSIX do nothing and leave their names in the
global '::' namespace?

The POSIX names will provide a real-world proving ground for
namespaces, for better or worse.  Let's hope POSIX does the right thing,
and let's hope that namespaces really are a good idea in the long run.
And if they are, maybe we can hope that C will catch up some day, too.

-- David R. Tribble, david.tribble@central.beasys.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              ]

On 18 Jun 1998 21:34:47 GMT, abrahams@motu.com (David Abrahams) wrote:

>Maybe I wasn't clear here. I don't know exactly what ILog Views is,
>but I bet it's not what I want. I'm looking for a C++ wrapper for the
>Win32 API which doesn't change ANY of the interfaces, but eliminates
>all macros and puts everything into a namespace. If the wrapper was a
>DLL it should be possible to avoid anything from Win32 making it into
>the global namespace. Using overloading it should be possible to deal
>with the ASCII/Unicode issue.
>

NO, overloading is not the solution. I want *different behavior* from
the same program, depending on sone compiler #defines. The most
important to me is the difference between debug and release variants.
Since inline functions and templates must be there in source form, it
is not possible e.g. to simply link to different libraries.

Martin



------------------------------------------------
Martin Aupperle 1xx754.273x@compuserve.com
(replace x with 0 - fight spamming)
------------------------------------------------
---
[ 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 in message ...
>Namespaces do not solve any problem that prefixes didn't already solve
>(except perhaps the aesthetic ones that Stroustrup perceives). There is no
>international (or national, or otherwise) namespace brokerage/clearing
>house/authority, so you still have the chance that two vendors could choose
>the same namespace.

This isn't true.  What about when a vendor doesn't use namespaces?
You can easily do the following:

namespace vendor
{
#include "VendorHeader1.h"
#include "VendorHeader2.h"
}

and this way there are no surprises and you always know where your code came
from.
It also serves as a useful documentation tool.

Tom McKearney
---
[ 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 <6mbf8s$qmh$1@nnrp1.dejanews.com>,
  jkanze@otelo.ibmmail.com wrote:
>
> In article <6m9eh8$oio$1@nnrp1.dejanews.com>,
>   AllanW@my-dejanews.com wrote:
> > we'll ignore that for now... *sigh*).  Anyway, I have two global functions
> > with the same name, both with "C" linkage, from completely different
> > vendors and completely different purposes.  There are three other name
> > collisions too, which I won't go into here.

> Well, if a company isn't using prefixes (in pre-namespace code), there's
> no reason to suppose that they will use namespaces today.  A company that
> doesn't care about its users doesn't care about its users, and namespaces
> aren't going to change the attitude of the company.  The answer to that
> is to not deal with such companies.
>
> And of course, if the company doesn't ship its code already wrapped in
> a namespace, you can't wrap it yourself later.  Not to mention that
> namespaces don't help with macros.

If I didn't know better (I do), I would say you didn't have any experience
with real-world systems.

We're talking about legacy code converted from BASIC to C to C++.  And
if I tell my bosses that they shouldn't have dealt with those companies in
1978, and shouldn't deal with them now, they'll have two choices: Rewrite
this giant system from scratch, or fire me and find someone who will work
with it as is.  I actually kind of like that first option, but I wouldn't
be the one paying for it.

We have reasons for not upgrading to a newer version of the package.  But
let's say that we were on the latest version.  Let's also consider the
point of view of the vendor.

"We could change the name of all routines to support a prefix, such as
changing SendMessage to abcSendMessage.  But that would break the code
of a few thousand customers.  We could minimize the damage with macros,
perhaps, but it certainly wouldn't be painless.  So the best answer is
to use a prefix for all NEW functions, but leave the legacy names alone."

...until someone shows up with namespaces.

"We could put our whole library in namespace abc.  This still isn't
painless for our customers, but it's pretty close -- they just need to
add "using namespace abc" in all of their legacy code, and relink.
New code could use abc::SendMessage, and old code could continue to
use SendMessage.  Truely excellent; let's do it."

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/   Now offering spam-free web-based newsreading
---
[ 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 <358AE8BD.2F5D@noSPAM.central.beasys.com>,
david.tribble@noSPAM.central.beasys.com says...

> You can trademark the name of a product or a company,
> and you can copyright a set of assembler mnemonics, but you can't
> trademark a variable or typedef name.

You don't have to use the name for any specific purpose to trademark
it.  However, you're not allowed to trademark things that are simply
generic names for something, and/or are already in common usage.
Though you don't have to do nearly as much to prove originality as
with a patent (excluding design patents, which are a lot like
trademarks) you can't trademark something like a single word that's
already in common usage.

> If that were the case, some bozo would have tried to trademark the
> name "x" (as a variable name) a long time ago.

As above -- the trademark has to be at least slightly different from
things already in common use.

> I still think using internet domain names for namespaces is a good
> start.  Someone complained that that would tie namespaces to closely
> to company and product names.  Is there another alternative?
> If you buy Rogue Wave's class library, wouldn't you expect it to
> have a namespace like 'RogueWave::' or 'RW::' rather than something
> like 'Bob::' or 'Spot::'?

Ultimately, I don't think it matters a lot.  It's going to be awfully
hard to enforce any single system, but I don't think it's necessary.

In practice, almost every time I've used more than one large library
in a project, there's been some conflict between some pair.  When you
have hundreds or thousands of names to deal with, I'd consider it
nearly inevitable.

By contrast, even a very large project isn't likely to have more than
a dozen or so namespaces involved.  Dealing with a dozen names in very
specific places is trivial compared to dealing with thousands of them.

I'd also note that if you DO run into two libraries that use the same
name for their namespace, as long as you have source code to at least
one of them, it's pretty trivial to find the `namespace' and change
the namespace for one, followed by a recompilation.  In theory you can
do the same with prefixes, but it in reality it's nearly always more
work than it's worth -- I'm not sure I've ever seen it done
successfully.

--
    Later,
    Jerry.

The Universe is a figment of its own imagination.
---
[ 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              ]

Tom McKearney wrote:
>
> Al Stevens wrote in message ...
> >Namespaces do not solve any problem that prefixes didn't already solve
> >(except perhaps the aesthetic ones that Stroustrup perceives). There is no
> >international (or national, or otherwise) namespace brokerage/clearing
> >house/authority, so you still have the chance that two vendors could choose
> >the same namespace.
>
> This isn't true.  What about when a vendor doesn't use namespaces?
> You can easily do the following:
>
> namespace vendor
> {
> #include "VendorHeader1.h"
> #include "VendorHeader2.h"
> }
>
> and this way there are no surprises and you always know where your code came
> from.
> It also serves as a useful documentation tool.

Unfortunately, this doesn't work. The library itself has to be built
with namespaces, too. Otherwise it won't link.
 -- Pete


[ 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              ]

The following is drawn from my experience and is not a legal opinion.

>You don't have to use the name for any specific purpose to trademark it.

When I applied to register a product name trademark, I was required to show
that a product was actually being marketed under that name.

> However, you're not allowed to trademark things that are simply generic
names for something, and/or are already in common usage.


What about "Coke," "Delphi," "Tide," "Shell," "Whisk," and "Slice?" Those
words all mean something else and are in common usage. But they are also
registered trademark names of products.

As it was explained to me by a trademark/patent lawyer, you can trademark
names like that as long as your trademark does not create confusion with
another product of the same type, which is why Borland could use Delphi for
a programming environment even though another company had a national online
service with the same name.

So, presumably, you could call your accounting program McDonald's and be
within the spirit and letter of the law, but you'd still probably have to do
battle with an army of corporate lawyers over it. A local hotdog restaurant
here is called "Dogs 'R' Us" with the R backwards. They got sued by Toys 'R'
Us and prevailed.



[ 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              ]

On 21 Jun 1998 15:36:59 GMT, Pete Becker <petebecker@acm.org> wrote:

>Tom McKearney wrote:

snip

>> This isn't true.  What about when a vendor doesn't use namespaces?
>> You can easily do the following:
>>
>> namespace vendor
>> {
>> #include "VendorHeader1.h"
>> #include "VendorHeader2.h"
>> }
>>
>> and this way there are no surprises and you always know where your code came
>> from.
>> It also serves as a useful documentation tool.
>
>Unfortunately, this doesn't work. The library itself has to be built
>with namespaces, too. Otherwise it won't link.
> -- Pete

Is there something in the standard that forces this, or is it an
avoidable byproduct of current implementation techniques?
---
[ 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              ]

Tom McKearney<me@nospam.com> wrote:
>You can easily do the following:
>
>namespace vendor
>{
>#include "VendorHeader1.h"
>#include "VendorHeader2.h"
>}
>
>and this way there are no surprises and you always know where your
>code came from.  It also serves as a useful documentation tool.

Sorry, this doesn't work _at all_.

Typical library headers include system headers:

  // VendorHeader1.h
  #include <stddef.h>
  ...  // stuff using size_t

What happens when this gets wrapped in a namespace?  Now there is
no ::size_t or std::size_t; instead, you have vendor::size_t and/or
vendor::std::size_t.

Anyway, even if they don't include system headers, the names
defined in them would mangle differently and become unlinkable
with the compiled library.

--
Nathan Myers
ncm@nospam.cantrip.org  http://www.cantrip.org/
---
[ 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              ]

The most serious flaw I have noticed in namespaces comes when you want to
use namespaces *without* doing a "using" on the namespace. Under these
conditions, it becomes virtually impossible to make effective use of
any operator overloading which may be defined in the namespace (of course,
you can still use the operators with sufficient silly syntax, but once you
add all the syntax, you might as well just be calling a function instead
of using an operator in an expression).

Just as an example of the sort of amusement this provides, trying writing
a small program *without* "using std" which does streams I/O :-).
--
>>==>> The *Best* political site <URL:http://www.vote-smart.org/> >>==+
      email: Tom.Horsley@worldnet.att.net icbm: Delray Beach, FL      |
<URL:http://home.att.net/~Tom.Horsley> Free Software and Politics <<==+


[ 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 in message ...
>
>So, presumably, you could call your accounting program McDonald's and be
>within the spirit and letter of the law, but you'd still probably have to
do
>battle with an army of corporate lawyers over it. A local hotdog restaurant
>here is called "Dogs 'R' Us" with the R backwards. They got sued by Toys
'R'
>Us and prevailed.
>
McDonald's is actually a very weak trademark.  It's unusal to have the name
of a person accepted as a trademark.  The way that a company like McDonald's
can do that is to show that when people hear the name, they invariently
think of the hamburger chain.  But McDonald's is also on weaker grounds in
preventing other people from using the name.

When Pierre Trudeau was prime minister of Canada, an enterprising company
attempted to use the name Pierre, Eh? on a brand of bottled spring water.
On the bottle they had a label giving the biographical details of our prime
minister.  Perrier sued and was succesful in stopping them.

All these and other stories from our friendly law firm; a great big beast
that needs to be kept well fed.

Regards,
Daniel Parker danielp@no_spam.anabasis.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              ]

wkdugan@ix.netcom.com (Bill Dugan) writes:
>Pete Becker <petebecker@acm.org> wrote:
>>Tom McKearney wrote:
>>> You can easily do the following:
>>>
>>> namespace vendor {
>>> #include "VendorHeader1.h"
>>> #include "VendorHeader2.h"
>>> }
>>
>>Unfortunately, this doesn't work. The library itself has to be built
>>with namespaces, too. Otherwise it won't link.
>
>Is there something in the standard that forces this, or is it an
>avoidable byproduct of current implementation techniques?

The latter.  It would be quite straight-forward to either

 (a) provide a separate tool for manipulating object files and
     libraries, allowing one to add, remove, or rename namespace
     prefixes
or
 (b) extend the linker with support for wrapping up libraries
     in namespaces on-the-fly during linking (perhaps by using
     an option such as `-l vendor::lib' instead of `-l lib')

--
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3        |     -- the last words of T. S. Garp.


[ 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              ]

Bill Dugan wrote:
>
> On 21 Jun 1998 15:36:59 GMT, Pete Becker <petebecker@acm.org> wrote:
>
> >Tom McKearney wrote:
>
> snip
>
> >> This isn't true.  What about when a vendor doesn't use namespaces?
> >> You can easily do the following:
> >>
> >> namespace vendor
> >> {
> >> #include "VendorHeader1.h"
> >> #include "VendorHeader2.h"
> >> }
> >>
> >> and this way there are no surprises and you always know where your code came
> >> from.
> >> It also serves as a useful documentation tool.
> >
> >Unfortunately, this doesn't work. The library itself has to be built
> >with namespaces, too. Otherwise it won't link.
> >       -- Pete
>
> Is there something in the standard that forces this, or is it an
> avoidable byproduct of current implementation techniques?

Suppose VendorHeader1.h supplies a prototype for a function f:

void f();

In one translation unit (i.e. in a library) you have code that uses that
header directly, and calls f. In another translation unit you wrap the
header in a namespace, resulting in, in effect,

namespace vendor
{
void f();
}

These two f's are two different functions, one whose fully qualified
name is ::f and the other whose fully qualified name is vendor::f.
That's perfectly legal and proper, and one of the main reasons for
namespaces to exist is to make sure that these two names refer to
distinct functions. For example:

#include <iostream>

void f()
{
std::cout << "I'm global.\n";
}

namespace vendor
{
void f()
{
std::cout << "I'm in namespace vendor.\n";
}
}

int main()
{
f();
vendor::f();
return 0;
}

This program is required to print out

 I'm global.
 I'm in namespace vendor.


[ 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              ]

Tom.Horsley@worldnet.att.net (Thomas A. Horsley) writes:

>The most serious flaw I have noticed in namespaces comes when you want to
>use namespaces *without* doing a "using" on the namespace. Under these
>conditions, it becomes virtually impossible to make effective use of
>any operator overloading which may be defined in the namespace

I suspect you are seeing the effect of transitional compilers,
not a problem with the language definition. The language rules
now require that when evaluating a function call (including
overloaded operators), the namespaces associated with all
the operands are included automatically. Example:

namspace N {
    class T { ... };
    T operator+(const T&, const T&);
}
N::T t1, t2;
... t1 + t2 ... // uses N::operator+


>Just as an example of the sort of amusement this provides, trying writing
>a small program *without* "using std" which does streams I/O :-).

    #include <iostream>
    int main() { std::cout << "Hello, world!\n"; }

If this example doesn't work with your current compiler,
it should with the next release.

--
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              ]

Nathan Myers wrote in message <6mc341$egr$1@shell7.ba.best.com>...
>Daniel Parker<danielp@nospam.com> wrote:
>>
>>Clearly, but what about references that are made in inlined code and
>>templated code, not compiled code?  That's what I was concerned with.
>
>Alias names exist only at compile time, not at link time -- just like
>typedef-names.  The language specifies this, and makes no exception
>for templates or inlines.

I suspect what he wanted to ask -- and if not, I'm asking it -- is, what
do you do about names that need to go in header files, and are therefore
visible to clients of the library?

--
Ross Smith ................................... mailto:ross.s@ihug.co.nz
.............. The Internet Group, Auckland, New Zealand ..............
  "Remember when we told you there was no future? Well, this is it."
                                                        -- Blank Reg




[ 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              ]

>but I bet it's not what I want. I'm looking for a C++ wrapper for the
>Win32 API which doesn't change ANY of the interfaces, but eliminates
>all macros and puts everything into a namespace.

Or makes the unicode/ASCII calls template functions with specialized
implementations. Either solution is directed at C++, of course, and
windows.h is for C, too, which is why it has to be how it is.

> Try porting a pre-existing large project to Win32 and avoiding a name
conflict;

And so many other portability problems that you wind up rewriting the
program anyway. Most interactive applications so closely intertwine the user
interface with the underlying problem domain (read failure to encapsulate)
that moving the application to another UI usually requires a rewrite. The
Windows MFC application/document/view architecture strongly encourages that
tightly-coupled design model, and I would suspect that the same is true of
other GUI frameworks.

Besides, if you eliminate "all macros" you give up the message map, which is
implemented with macros, and for which C++ has no other acceptable idiom
short of hand-coding the underlying structures.





[ 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              ]

>First, there are never any "cut and dried" requirements when standardizing
>a language.

Never say never. The C committee had a clearly defined charter as to what
they were to do, which was essentially to codify existing usage and resolve
the ambiguities found across existing implementations. I call that pretty
cut and dried.

6 out of 41 isn't much dissention? Sounds like about 15% to me. That's
pretty significant. Governments have been overturned by smaller minorities.
---
[ 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              ]

>The most important problem that namespaces solve, in my opinion,
>is the problem of combining libraries from multiple vendors.

Assuming the vendors all employ namespaces in a rational, coordinated
manner. Namespaces offer a solution, which is mostly misunderstood and
relatively untested if the messages on this thread are any indication.

>This has not been a problem until recently, because there have not
>been many library vendors until recently.


I just pulled out a 10-year old issue of Dr. Dobb's Journal and counted 28
ads for library vendors.
---
[ 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              ]

jkanze@otelo.ibmmail.com wrote:
>
> In article <6m9fgu$6b9$1@news.interlog.com>,
>   "Daniel Parker" <danielp@nospam.com> wrote:
> >
> > David R Tribble wrote in message <3587F092.89E@noSPAM.central.beasys.com>...
> >
> > >>
> > >> When Standard C increased that limit to 31 characters, the problem
> > >> essentially went away.
> > >
> >
> > Could someone enlighten me as to what the current limit is for C++ class
> > names?
>
> 1.
>
> To make that clearer: the following program is required to compile on
> all conforming implementations, but could conceivably give a different
> answer (2) on some:
>
>     #include <iostream>
>
>     int             a1 = 1 ;
>     int
>     main()
>     {
>         int             a2 = 2 ;
>         std::cout << a1 << '\n' ;
>         return 0 ;
>     }

Based upon Section 1.3, paragraph 2, a conforming C++ implementation is
not required to compile any program. Any program, no matter how short,
may be rejected as exceeding the resource limits of an implementation.
I thought the conformance requirements for C9X were lax, but the
conformance requirements for C++ are a joke.  Of course, once an
implementation does agree to do something with a program, the
requirements on what it does get a lot more meaningful.


[ 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              ]

Andrew Koenig <ark@research.att.com> wrote:

> In article <6mbej7$o3p@bcarh8ab.bnr.ca>,
> Jim Cobban <Jim.Cobban.jcobban@nt.com> wrote:
>
> > I very strongly agree with this position.  The problem solved by namespaces
> > applies only to a small proportion of even very large projects.
>
> The most important problem that namespaces solve, in my opinion,
> is the problem of combining libraries from multiple vendors.
> This has not been a problem until recently, because there have not
> been many library vendors until recently.

Yes, but there is also another very nice effect of namespaces not
directly related to real or potential name clashes. It is an abstraction
tool. They make higher level modules than class and not necessarily a
library, explicit and provides a name in the code for them. This helps.


--
Lars Farm; lars.farm@ite.mh.se  -  Limt/Channelmatic: lars.farm@limt.se


[ 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              ]

>Anonymous namespaces certainly make the following cleaner:
>
>namespace {
>
>class ForUseOnlyByThisTranslationUnit {};
>
>void fun() {}
>
>}
>
>Without namespaces, the function would need to be declared static, and
>one would need to ensure the class name is unique throughout the
>program.

Only because C++ does not support:

static class ForUseOnlyByThisTranslationUnit {};

without an instance name included. If it did as C does with structs, static
and file scope, a time-tested legacy concept, 20 years in the proving,
instead of being deprecated, would cover what the unnamed namespace does
now.

>Without namespaces, we have to use prefix warts
>everywhere, e.g. a library writer can't refer to his "A" class without
>spelling it "wart_A", and that's tedious, and it smells like a
>language shortcoming.

No, it relieves me from having to wonder which A I am looking at when I read
the code.

>Have you had any namespace problems that weren't due to incomplete
>implementations or compiler bugs?

I haven't really had any namespace problems. I haven't had any problems that
needed namespace solutions either. Lots of posts in this thread state
expressly how namespaces help a programmer as if the poster knows, yet other
posts about poor implementations and uses of the feature and the
incompatibility of namespaces and macros clearly indicate that the community
does not have enough experience with this feature to say except through
intuition how well the feature is going to work and how it is going to help.
The jury is still out. That is the risk you take when you expand a
standardization charter to include language invention.



[ 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              ]

jkanze@otelo.ibmmail.com wrote:
>> (and to not register the
>> use of his specific prefix as a registered trademark,

AllanW@my-dejanews.com wrote:
> We can do that?

No, we can't.  You can trademark the name of a product or a company,
and you can copyright a set of assembler mnemonics, but you can't
trademark a variable or typedef name.  If that were the case, some
bozo would have tried to trademark the name "x" (as a variable name)
a long time ago.  Kind of like trademarking the word "love" for
paperback novels.

> We've just been assuming that other libraries weren't
> deliberately hostile, so a simple prefix to avoid accidents was
> sufficient.

Microsoft, in its usual arrogance, uses the unbelievably lame prefix
'C' on all their Foundation Classes names.  It was probably done more
out of ignorance than outright hostility.

I still think using internet domain names for namespaces is a good
start.  Someone complained that that would tie namespaces to closely
to company and product names.  Is there another alternative?
If you buy Rogue Wave's class library, wouldn't you expect it to
have a namespace like 'RogueWave::' or 'RW::' rather than something
like 'Bob::' or 'Spot::'?

-- David R. Tribble, david.tribble@central.beasys.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              ]

David R Tribble wrote in message
>>...
>>internet web address of "beasys.com", so I could put all of the code I
>>write for them into the namespace "com_beasys::" (or "COM_BEASYS::",
>>or even the nested namespace "Com::BeasSys::").  If I wanted to be
>>more specific, because my library is separate from the other libraries
>>developed by the other departments in my company, I could use a longer
>>name like 'com_beasys_productname::'.  Since C++ allows namespace
>>'aliases', I can easily equate this to a shorter, more convenient
>>prefix (like 'bea::') in my header files for end users of my library.

Daniel Parker wrote:
> Namespaces are wonderful, but there are still the practical issues
> that need to be dealt with.  Like in your example, suppose your
> company ships two libraries, both of which have long namespace names,
> one of which uses the other.  Sure, your customers can use a short
> alias, but what about your one library that uses the other?  does it
> have to use the long namespace name?

That's where namespace aliases (7.3.2) come in handy.  I probably
wouldn't use an alias like 'bea::', but something a little more
descriptive (but still conveniently short):

    #include "beacomm.h"
    namespace COM_BEASYS_Commlib_10 = BEAComm;

    #include "beafile.h"
    namespace COM_BEASYS_Filehandling_22 = BEAFile;

    ... BEAComm::read();
    ... BEAFile::read();

> And if it does, do you show that long name in your printed reference
> manuals, say in a function prototype?

I would probably give them a short alias for free in the header file,
and use that name in the documentation.

    // beacomm.h

    namespace COM_BEASYS_Commlib_10 { ... };
    namespace COM_BEASYS_Commlib_10 = BEAComm;

-- David R. Tribble, david.tribble@central.beasys.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 <alstevens@midifitz.com> wrote in article
<DEvi1.20575$08.4858311@newscene.newscene.com>...
> >First, there are never any "cut and dried" requirements when standardizing
> >a language.
>
> Never say never. The C committee had a clearly defined charter as to what
> they were to do, which was essentially to codify existing usage and resolve
> the ambiguities found across existing implementations. I call that pretty
> cut and dried.

I hear this a lot, but it is not a fair or accurate characterization of
the C++ committee's charter.

Greg Colvin
---
[ 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              ]

James Kuyper <kuyper@wizard.net> wrote in article
<358A89E5.167E@wizard.net>...
>
> Based upon Section 1.3, paragraph 2, a conforming C++ implementation is
> not required to compile any program. Any program, no matter how short,
> may be rejected as exceeding the resource limits of an implementation.
> I thought the conformance requirements for C9X were lax, but the
> conformance requirements for C++ are a joke.  Of course, once an
> implementation does agree to do something with a program, the
> requirements on what it does get a lot more meaningful.

It's no joke.  The trouble with specifying any actual minimum is
that it will become treated as a maximum.  That is, if the standard
says that all implementations must support at least 31 characters
in identifiers, you can be sure that some corporate coding standards
will say that "because the standard does not guarantee support for
identifiers over 31 characters, no identifier shall exceed 31
characters" and so on.  I'm currently trying to code in a subset of
ANSI C that is hamstrung in just that way, and my employer even has
their own lint program to be sure I don't stray  By not imposing any
such minima, we give implementors and code style Nazi's no excuse for
imposing arbitrary maxima.

Greg Colvin


[ 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              ]

On 18 Jun 1998 18:24:39 GMT, jkanze@otelo.ibmmail.com wrote:

>In article <35886d28.214524542@news.motu.com>,
>  abrahams@motu.com wrote:
>
>> Anyone who writes a C++ namespace-wrapped library for Win32 which
>> cleans up these problems is my instant hero.
>
>I don't know the policy of ILog here -- I used Views with a compiler
>which didn't support namespaces.  But they do use prefixes very consistently.
>(I also don't know what platforms they are available for, other than
>the ones we used, or were considering: Sun Solaris, HP-UX and Windows NT.)
>
>This has also been the policy of every other third party library I've used,
>with the exception of the USL class library.

Maybe I wasn't clear here. I don't know exactly what ILog Views is,
but I bet it's not what I want. I'm looking for a C++ wrapper for the
Win32 API which doesn't change ANY of the interfaces, but eliminates
all macros and puts everything into a namespace. If the wrapper was a
DLL it should be possible to avoid anything from Win32 making it into
the global namespace. Using overloading it should be possible to deal
with the ASCII/Unicode issue.


[ 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              ]

Then you just described bad code from non-naive good programmers who do
understand the basics of that old chestnut, encapsulation, nee information
hiding, but who, for some reason or another, chose not to employ it. Call it
rash or anything else you want, but that's my reaction to what you
described.

Of course I can't tell you all the things they could have done differently
without looking at all the code. But I can tell you that many many large C
and C++ projects have been developed and integrated successfully without the
severe namespace pollution problems you describe.



[ 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 think for the first problem, the best solution is (on the
>non-conforming compilers):
>#define std


CPP Lives!  :-)



[ 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              ]

Daniel Parker<danielp@nospam.com> wrote:
>David Abrahams wrote in message <358940f0.268749141@news.motu.com>...
>> "Daniel Parker" <danielp@nospam.com> wrote:
>>
>>
>
>>>Sure, your customers can use a short alias, but what about your one
>>>library that uses the other?  does it have to use the long namespace name?
>>
>>It is free to use any alias it wants to, since the alias only lives as
>>long as you're compiling. The link name will still be the long
>>namespace name.
>
>Clearly, but what about references that are made in inlined code and
>templated code, not compiled code?  That's what I was concerned with.

Alias names exist only at compile time, not at link time -- just like
typedef-names.  The language specifies this, and makes no exception
for templates or inlines.

--
Nathan Myers
ncm@nospam.cantrip.org  http://www.cantrip.org/



[ 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              ]

Daniel Parker<danielp@nospam.com> wrote:
>
>Nathan Myers wrote in message <6m9vd9$q93$1@shell7.ba.best.com>...
>>
>>A good choice for a namespace name is something both abstract and
>>not likely to be chosen by anybody else.  For industrial purposes,
>>a name like LibMessage_NCM980622 might be a good choice when
>>combined with appropriate aliases.  The initials and date code
>>come from when the namespace was created, not who currently maintains
>>it or when it was last changed, so the name is stable.
>>
>Suppose we do this, suppose we have two libraries, each wrapped in its own
>namespace, viz.
>
>MatrixLib_DAP980622
>
>and
>
>RandomLib_GFW980622
>
>and suppose RandomLib requires the services of MatrixLib.  Now, our
>customers can use aliases, but what do we do; do we have to reference the
>MatrixLib classes as, say, MatrixLib_DAP980622::SymmetricMatrix, in the
>RandomLib library?

You can put an alias for MatrixLib in the RandomLib namespace.

>... what do we show in our printed documentation of RandomLib
>methods that take MatrixLib arguments? Presumably we couldn't show the long
>name, would just MatrixLib do?

I would think so... the alias in your own namespace can be part of your
public interface.

>... quite frankly if someone were to buy us up, I would view the
>changing of the namespace as their problem, not ours :-)

Except that they would assign *you* to change it.  It's a bigger
problem when a library you license and depend on is bought out by
somebody else.

--
Nathan Myers
ncm@nospam.cantrip.org  http://www.cantrip.org/



[ 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              ]

Jim Cobban wrote in message <6mbej7$o3p@bcarh8ab.bnr.ca>...
>In article <32_h1.16526$08.3962038@newscene.newscene.com>,
>I very strongly agree with this position.  The problem solved by namespaces
>applies only to a small proportion of even very large projects.  It does not
>make sense to make the use of namespaces mandatory even in trivial programs,
>such as hello world in order to solve the problems of a handful of (in my
>opinion) poorly designed projects.  Let that minority who have the problem
>use namespaces, and leave the rest of us alone with our working code.

I very strongly disagree. I find namespaces (particularly anonymous
ones) very useful even in small projects. Sure, you don't have to use
them. If you enjoy the prospect of name clashes and/or extraordinarily
tedious prefixing then I would recommend steering well clear of
namespaces.

- Jim

--
Jim Barry, Thermoteknix Systems Ltd., Cambridge, UK.
http://www.thermoteknix.co.uk Queen's Award for Export 1998
Antispam address courtesy of http://www.bigfoot.com
Or e-mail direct: jim at thermoteknix dot co dot uk
---
[ 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> wrote:
>>
>>> There is no international (or national, or otherwise) namespace
>>> brokerage/clearing house/authority, so you still have the chance
>>> that two vendors could choose the same namespace.

I think a lot of attention has been focussed on this point.
But really it is not such an important one, IMHO.
Even if namespaces don't *eliminate* the problem of name clashes,
they surely reduce the frequency of such occurrences and make them
easier to deal with when they do occur.  The average program would
only use a few top-level packages, so collisions between namespace
names should be orders of magnitude less common than collisions
between names of funtions, classes, etc.

--
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3        |     -- the last words of T. S. Garp.
---
[ 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              ]

Nathan Myers wrote:
>
> <AllanW@my-dejanews.com> wrote:
> >
> >> There is no international (or national, or otherwise) namespace
> >> brokerage/clearing house/authority, so you still have the chance
> >> that two vendors could choose the same namespace.
> >
> >That could happen if vendors started using names like Email or Tools.
> >
> >But a more wise choice would indicate both the organization name and
> >the problem domain.
>
> Unfortunately this is the first thing everybody thinks to do, but it
> causes problems.  Don't do this!
>
> The problems arise later, when the code changes hands: the company
> changes its name, or the project or product name, or sells the product
> to some other company.  Then some pointy-haired manager comes in and
> tells you to change the namespace name to avoid trademark infringement,
> or just to avoid calling favorable attention to his predecessor.
>

The obvious solution to this is that any user of the library
makes a namespace alias and uses only this in his programs
(that's a reasonable idea anyway, to shorten the namespace name).
If this alias is defined in a project wide header file, you'll
have to change just one name if the namespace name changes.

For example, assume, Borland's VCL is put in a namespace
BorlandVisualClassLibrary. Then your header file would contain
the line

namespace vcl = BorlandVisualClassLibrary;

(I hope I got the syntax right). If the project was a library
itself, the namespace alias should of course be a member of
the library namespace. Now imagine, the library was bought
by Microsoft, and they decided to rename the namespace to
MicrosoftVisualClassLibrary. Now all you'd have to do is to
change this single line. If, however, something in the library
changed, you can be glad to be warned through the namespace
renaming.

> A good choice for a namespace name is something both abstract and
> not likely to be chosen by anybody else.  For industrial purposes,
> a name like LibMessage_NCM980622 might be a good choice when
> combined with appropriate aliases.  The initials and date code
> come from when the namespace was created, not who currently maintains
> it or when it was last changed, so the name is stable.

I don't think the vendor should provide aliases if there's no
special reason for it. It's up to the user to make a reasonable
alias.

>
> Note that this approach shades into techniques for allowing use of
> different versions of a library with incompatible interfaces/semantics
> in the same program.

This can be done with the original approach as well, by adding
a version number to the namespace (which is still more readable
than your example above). For example: FoosoftTheKillerLibrary,
FoosoftTheKillerLibrary_2, FoosoftTheKillerLibrary_3

[...]
---
[ 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 <6m9ggu$rgk$1@nnrp1.dejanews.com>,
  AllanW@my-dejanews.com wrote:
>
> In article <6m8qc3$m3d$1@nnrp1.dejanews.com>,
>   jkanze@otelo.ibmmail.com wrote:
> > (and to not register the
> > use of his specific prefix as a registered trademark,
> We can do that?  We've just been assuming that other libraries weren't
> deliberately hostile, so a simple prefix to avoid accidents was sufficient.
> (Sort of like the C++ philosophy on encapsulation: protect against
> accidents, not fraud.)

I would be surprised if you couldn't.  You can register just about anything
as a trademark.

> > sort of like Coca Cola registered the shape of its bottle),
> But that's tangible.  They can patent their bottle shape, because any moron
or
> patent worker can see the bottle shape with no special tools.

Not patent, register as a trademark.  Anyone who looks at an include file
from Rogue Wave (or ILog, or any one of a number of companies I can think
of) can see it immediately, without any special tools.  In fact, without
any real programming knowledge.  (This is actually an advantage of prefixes.
The fact that they are literally everywhere in all of the include files
means that you don't need any special knowledge to see them.  It would
be much harder to argue trademark status for SomeSpecialName if the only
place it appeared was behind a namespace keyword.)

--
James Kanze    +33 (0)1 39 23 84 71    mailto: kanze@gabi-soft.fr
        +49 (0)69 66 45 33 10    mailto: jkanze@otelo.ibmmail.com
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient   e objet --
              -- Beratung in objektorientierter Datenverarbeitung

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/   Now offering spam-free web-based newsreading
---
[ 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              ]

Jim Cobban wrote:
>
> In article <32_h1.16526$08.3962038@newscene.newscene.com>,
> Al Stevens <alstevens@midifitz.com> wrote:
> >We coded C and C++ for over 20 years without a namespace feature, and
> >somehow we got programs to work. Apparently some people had some problems
> >that they laid at the door of namespace pollution. My experience, and that
> >of the original poster is that those problems were the exception rather than
> >the rule. ...
>
> I very strongly agree with this position.  The problem solved by namespaces
> applies only to a small proportion of even very large projects.
> ...

My own experience differs.  For the industrial projects I work on, the
problem solved by namespaces is there virtually 100% of the time for
larger projects and some lesser but non-zero percent of smaller
projects.

One of the things I learned quickly in doing Standards committee work is
that some problems or practices which I thought were univeral are not
only not universal, but a lot of programmers have never even heard of
them.  I guess namespace pollution is one of those problems some folks
never see, but others fight daily.

I envy programmers who work in some kind of alternate world where
namespace pollution is not an issue, but it sure is in the world I work
in.

--Beman Dawes
---
[ 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              ]

On 16 Jun 98 16:41:50 GMT, "Al Stevens" <alstevens@midifitz.com>
wrote:

>Namespaces do not solve any problem that prefixes didn't already solve
>(except perhaps the aesthetic ones that Stroustrup perceives).

Anonymous namespaces certainly make the following cleaner:

namespace {

class ForUseOnlyByThisTranslationUnit {};

void fun() {}

}

Without namespaces, the function would need to be declared static, and
one would need to ensure the class name is unique throughout the
program. With namespaces, you just write the code. I think this goes
beyond aesthetic, entering the realm of genuinely useful.

>I think that a long time ago the "namespace problem" was deeply felt, and
>long after it had been effectively addressed with a simple solution,
>language framers felt compelled to solve it again with a complicated one.
>This is not a popular opinion, but my experience is the same as yours. I
>never had a problem with namespace issues until C++ compilers implemented
>namespaces and added the std namespace to the libraries.

As for the name collision issue, prefixes are a bit hokey, affecting
both the user and the developer of a library. Namespaces make things
easier for the developer, and they give both more control over what
names they see. Without namespaces, we have to use prefix warts
everywhere, e.g. a library writer can't refer to his "A" class without
spelling it "wart_A", and that's tedious, and it smells like a
language shortcoming.

Have you had any namespace problems that weren't due to incomplete
implementations or compiler bugs? I haven't, though compiler bugs have
prevented me from using namespaces as fully as I would like.

--
Doug Harrison
dHarrison@worldnet.att.net
---
[ 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              ]

"Daniel Parker" <danielp@nospam.com> writes:

>David R Tribble wrote in message <3587F092.89E@noSPAM.central.beasys.com>...

>>>
>>> When Standard C increased that limit to 31 characters, the problem
>>> essentially went away.
>>

>Could someone enlighten me as to what the current limit is for C++ class
>names?  I had a quick glance through Stroustrup 3rd ed, but couldn't find
>it.

There are no limits in the C++ standard. Appendix A, which is
"informative" (non-binding), suggests allowing names that do not
differ in their first 1024 characters.

Implementors may have and document stricter limits.


>Namespaces are wonderful, but there are still the practical issues that need
>to be dealt with.  Like in your example, suppose your company ships two
>libraries, both of which have long namespace names, one of which uses the
>other.  Sure, your customers can use a short alias, but what about your one
>library that uses the other?  does it have to use the long namespace name?

No. You can create an alias and use it in your code. An alias is
scoped and is just an alias, like a typedef. Example:

namespace MyLongNamespaceName1 {
 ...
}
namespace MyLongNamespaceName2 {
 namespace ns1 = MyLongNamespaceName1; // alias
 ns1::Type1 u;
 typedef ns1::LongTypeName2 T2;
 T2 v; // MyLongNamespaceName1::LongTypeName2
 ...
}

You want to be careful not to put the alias declaration at
global scope in a public header, since that would defeat the
purpose of having a long name (reduce name conflicts).

The long names don't need to appear very many times in source code.

--
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              ]

Nathan Myers wrote in message <6mc341$egr$1@shell7.ba.best.com>...
>>Clearly, but what about references that are made in inlined code and
>>templated code, not compiled code?  That's what I was concerned with.
>
>Alias names exist only at compile time, not at link time -- just like
>typedef-names.  The language specifies this, and makes no exception
>for templates or inlines.
>
I think you missed the point of the (possibly badly worded) question, but
nevermind; you answered it in your other post.

--
Regards,
Daniel Parker danielp@no_spam.anabasis.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              ]

Nathan Myers wrote in message <6mc2m5$ccn$1@shell7.ba.best.com>...
>Daniel Parker<danielp@nospam.com> wrote:
>>
>>Nathan Myers wrote in message <6m9vd9$q93$1@shell7.ba.best.com>...
>>>
>>do we have to reference the
>>MatrixLib classes as, say, MatrixLib_DAP980622::SymmetricMatrix, in the
>>RandomLib library?
>
>You can put an alias for MatrixLib in the RandomLib namespace.
>
Obvious?  Possibly, but I didn't think of it.  Anyway, thanks.

Regards,
Daniel Parker danielp@anabasis.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              ]

Jim Cobban wrote:
> ...  The problem solved by namespaces
> applies only to a small proportion of even very large projects.  It does not
> make sense to make the use of namespaces mandatory even in trivial programs,
> such as hello world in order to solve the problems of a handful of (in my
> opinion) poorly designed projects.  Let that minority who have the problem
> use namespaces, and leave the rest of us alone with our working code.

In what way are you not left alone with your working code?

Greg Colvin


[ 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              ]

Christopher Eltschka <celtschk@physik.tu-muenchen.de> wrote:
>Nathan Myers wrote:
>>
>> <AllanW@my-dejanews.com> wrote:
>> >
>> >But a more wise choice would indicate both the organization name and
>> >the problem domain.
>>
>> Unfortunately this is the first thing everybody thinks to do, but it
>> causes problems.  Don't do this!
>
>The obvious solution to this is that any user of the library
>makes a namespace alias  ...
>
>namespace vcl = BorlandVisualClassLibrary;

Unfortunately this doesn't work in some important cases.

In particular, the linkage names in compiled code are based
on the original namespace name, so when the pointy-haired
manager orders the name changed, it breaks link compatibility
regardless of your aliases.

>> A good choice for a namespace name is something both abstract and
>> not likely to be chosen by anybody else.  For industrial purposes,
>> a name like LibMessage_NCM980622 might be a good choice when
>> combined with appropriate aliases.  The initials and date code
>> come from when the namespace was created, not who currently maintains
>> it or when it was last changed, so the name is stable.
>
>I don't think the vendor should provide aliases if there's no
>special reason for it. It's up to the user to make a reasonable
>alias.

The vendor can provide aliases in a separate header file as a
convenience for casual users.  Users will probably demand it
anyway.  When the alias definitions are in a separate header
you don't have to use them (e.g. if they happen to collide
with something else).

--
Nathan Myers
ncm@nospam.cantrip.org  http://www.cantrip.org/



[ 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 wrote in message <6m9ggu$rgk$1@nnrp1.dejanews.com>...
>In article <6m8qc3$m3d$1@nnrp1.dejanews.com>,
>  jkanze@otelo.ibmmail.com wrote:
>> (and to not register the
>> use of his specific prefix as a registered trademark,
>We can do that?

Sure.  Just check with your friendly local law firm, and many thousands of
dollars and a couple of years later, you'll have yourself a trademark valid
in one country, although you may have to iterate a few times on the name.
Then repeat this process for all other countries in which you wish to sell
your software.  Trademarks aren't software patents, by the way.

--
Regards,
Daniel Parker danielp@no_spam.anabasis.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              ]

jkanze@otelo.ibmmail.com writes:

>In article <6m6ndq$clm@engnews1.Eng.Sun.COM>,
>  stephen.clamage@sun.com (Steve Clamage) wrote:

>> Implementations are allowed to add content to namespace std,
>> so the using-directive may bring more than you bargained for
>> into your program.
>>
>> By way of comparison, C has the rule that implementations may
>> add content to the global namespace, but only using names
>> reserved to the implementation.  I don't recall ever seeing a
>> C implementation that followed that rule. With namespaces, the
>> rule is self-enforcing for C++.

>I don't know.  I have two library implementations immediately
>available: the STL Port (3.01) and VC++ (5.0).  The STL Port (which
>I believe is a direct copy of the SGI implementation) defines macros
>with names that C declares in the user namespace.  As far as I can
>tell, VC++ doesn't (although it would be easy to have missed one), but
>it still shares headers between C and C++, with many of the "functions"
>in the C library implemented as macros (which is, I believe, illegal
>according to the C++ standard).  I see no reason to expect this to
>improve.

I think we are speaking to different points.

First, let's set aside the transition difficulties. (The fact that
something is difficult doesn't mean it isn't worth doing, or that
we shouldn't endure the difficulties.) It will be a while before
implementations and users have had time to adjust to the brave new
world of Standard C++. Until then, we'll see all sorts of anomalies.

Next, an implementor might not implement the standard correctly
for any number of reasons, ranging from misunderstanding, to
sloth, to backwards-compatibility issues overriding the desire
to conform to the standard. If the implementation doesn't pretend
to be standard-conforming, we can't really discuss the real or
imagined benefits of standard conformance.

>In the end, namespaces which don't include macros really don't buy us
>that much (except a more complicated name lookup).

Addressing now a standard-conforming implementation, the C++
implemention will contain only the macros that the C standard
requires to be macros. At least, those will be the only macros
that could impinge on names reserved to the programmer.
The C++ implementation is not allowed to substitute macros for
standard library functions; it can use inline functions instead.

That isn't necessarily hard to arrange. For example, the
C++ version of stdio.h could include the C version of stdio.h,
which defines macro putc. Then it does something like this:
 inline int (putc)(int c) { return putc(c); }
 #undef putc
A C++ program now generates the same code as a C program using
putc, but putc is no longer a macro. The C++ implementor
didn't have to touch the C header or duplicate its contents
to accomplish that.

As for macros in third-party libraries, I hope they are used
only for configuration control, and that they are long and
ugly with the vendor's name as a prefix.

--
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              ]

When you go to that much trouble to contrive an example to prove your point,
you are a lot more zealous than I am. I suppose I could hypothesize any code
I wanted to counter your arguments, but I'm not at all that up in arms about
it. Quite the contrary, it's more stuff for me to write about as I try to
make it to retirement without having to learn Java.

We coded C and C++ for over 20 years without a namespace feature, and
somehow we got programs to work. Apparently some people had some problems
that they laid at the door of namespace pollution. My experience, and that
of the original poster is that those problems were the exception rather than
the rule. I would gamble that the ratio of namespace-problem plagued
projects to non-namespace-problem plagued projects is very low (if I said
that right). Nonetheless, now we have namespaces, and we are going to have
them, and they are going to be a PITA until it all gets sorted out, the
industry figures out what to do with them, and the compilers figure out how
to implement them.

As one poster said, "...the committee was convinced, after heated and highly
technical debate, that namespaces were a worthy addition to the language,"
which says to me that it was not a cut and dried requirement if enough
members debated heatedly against it, indicating that my experience is not
unique.
---
[ 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              ]

On 17 Jun 1998 22:46:50 GMT, AllanW@my-dejanews.com wrote:

>In article <6m8qc3$m3d$1@nnrp1.dejanews.com>,
>  jkanze@otelo.ibmmail.com wrote:
>> In the end, namespaces which don't include macros really don't buy us
>> that much (except a more complicated name lookup).  Even if namespaces
>> included macros, if a vendor in prenamespace time was stupid enough to
>> deliver his libraries without using prefixes
>
>Microsoft has the ultra-mega example of this, in the form of Windows.H.
>There are hundreds of functions and almost as many structures.  This is
>the original API designed for C.  MFC was Microsoft's attempt at making
>it C++ -friendly, and in some ways they succeeded, but it still has to
>#include most of windows.h -- so the same global names pollute in the
>same way that they always have.  This also crosses compiler platforms
>to (all?) C++ compilers which target Microsoft Windows.
>
>Not that I'm complaining (job security, and all that), but it does seem
>a lot more messy than it should be, even pre-namespace.

I wasn't going to bring it up, but now that you've started the ball
rolling...

WINDOWS.H is worse than that for many reasons, not the least of which
is that *every* function which can take a string is actually a MACRO
which maps to one of two functions (the unicode and the ASCII version)
depending on some other MACRO which you set to choose the Unicode
version of windows. And they're using really obvious, useful names for
these macros, like, for example, GetObject!!!! Try porting a
pre-existing large project to Win32 and avoiding a name conflict; I
dare ya. Even if you're in a namespace, you're royally outta luck
because their macros change your names out from under you.

Anyone who writes a C++ namespace-wrapped library for Win32 which
cleans up these problems is my instant hero.

-Dave
---
[ 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> wrote:
>
>> There is no international (or national, or otherwise) namespace
>> brokerage/clearing house/authority, so you still have the chance
>> that two vendors could choose the same namespace.
>
>That could happen if vendors started using names like Email or Tools.
>
>But a more wise choice would indicate both the organization name and
>the problem domain.

Unfortunately this is the first thing everybody thinks to do, but it
causes problems.  Don't do this!

The problems arise later, when the code changes hands: the company
changes its name, or the project or product name, or sells the product
to some other company.  Then some pointy-haired manager comes in and
tells you to change the namespace name to avoid trademark infringement,
or just to avoid calling favorable attention to his predecessor.

A good choice for a namespace name is something both abstract and
not likely to be chosen by anybody else.  For industrial purposes,
a name like LibMessage_NCM980622 might be a good choice when
combined with appropriate aliases.  The initials and date code
come from when the namespace was created, not who currently maintains
it or when it was last changed, so the name is stable.

Note that this approach shades into techniques for allowing use of
different versions of a library with incompatible interfaces/semantics
in the same program.

>Remember, application code doesn't need to be wrapped in a namespace.
>It's not until you begin to make code reusable that this becomes valuable.

Sorry, this is not right either.  Namespaces are not just for exporting
interfaces, they help to protect your own code against indiscipline in
others' libraries.  Of course when you're writing code within a namespace,
you can hardly tell it's there, so there can be little reason *not* to
use them.

--
Nathan Myers
ncm@nospam.cantrip.org  http://www.cantrip.org/
---
[ 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              ]

Nathan Myers wrote in message <6m9vd9$q93$1@shell7.ba.best.com>...
><AllanW@my-dejanews.com> wrote:
>>
>
>A good choice for a namespace name is something both abstract and
>not likely to be chosen by anybody else.  For industrial purposes,
>a name like LibMessage_NCM980622 might be a good choice when
>combined with appropriate aliases.  The initials and date code
>come from when the namespace was created, not who currently maintains
>it or when it was last changed, so the name is stable.
>
Suppose we do this, suppose we have two libraries, each wrapped in its own
namespace, viz.

MatrixLib_DAP980622

and

RandomLib_GFW980622

and suppose RandomLib requires the services of MatrixLib.  Now, our
customers can use aliases, but what do we do; do we have to reference the
MatrixLib classes as, say, MatrixLib_DAP980622::SymmetricMatrix, in the
RandomLib library?  Presumably we can't use short aliases if the MatrixLib
names appear in RandomLib header files.  And if we do use those long
namespace names, what do we show in our printed documentation of RandomLib
methods that take MatrixLib arguments? Presumably we couldn't show the long
name, would just MatrixLib do?

This would be a little easier, Nathan, if we could use a shorter name with a
little bit of our company name in it, but I do appreciate your point.
Although quite frankly if someone were to buy us up, I would view the
changing of the namespace as their problem, not ours :-)

--
Regards,
Daniel Parker danielp@no_spam.anabasis.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              ]

On 17 Jun 98 18:23:54 GMT, "Al Stevens" <alstevens@midifitz.com>
wrote:

>>I guess you've never had to link a large existing program with a large
>>existing library.
>
>Only lots of times in the past 33 years since I first used assemblers and
>compilers that built relocatable object modules.
>
>>The number of conflicting names was enormous. Just think: thousands of
>>names declared in source files waiting to cause problems when a
>>conflicting definition showed up in a header! Conflicting function
>>names and global variables! Lurking unpredictabilities!
>
>Let me oversimplify and generalize without knowing any more detail than you
>provided. Thousands of external identifiers that should not have been in
>global scope in the first place.You just described bad code from naive
>programmers who do not understand the basics of that old chestnut,
>encapsulation, nee information hiding.

Uh, hello?
We're talking real-world code here, with a long history. It started as
straight 'C' code, so of course functions which couldn't be made
static were at global scope. It's a very, very large project, and
there were lots of those. Then we had C++ without namespaces. Most
classes don't make sense nested inside other classes, so of course
they are at global scope. And you realize, of course, that there's no
way to make any sort of type declaration static without using the
unnamed namespace...

Actually, I know the programmers involved, and they were not at all
naive, nor did they lack an understanding of encapsulation. I can't
imagine what you think they might have done differently to prevent the
problems I described. It sounds like you're saying "I've never had
these problems, and people who do must be bad programmers". Kinda
rash, don't you think?

>>Now that's a real-world case. I agree that namespaces are hard to
>>understand how to use.
>
>Really? I think in principle, the feature is quite small and elegant. I just
>don't think it's all that necessary and that it can be unwieldy to cope with
>particularly if all those naive programmers are turned loose on it.

It is small and elegant, but it doesn't automatically lead to good
usage. And understanding what good usage is takes some non-trivial
thought. That's my only point.

>>I lament the lack of a good set of publicly-available guidelines for the
>use of namespaces.
>
>You got that right. And for the assignment of namespace names, too.

FWIW, I favor a name which includes the problem domain, my initials
and the date I started the namesapce. That avoids the problems of code
transferred to new organizations. Managers may be prone to demand the
removal of all organization-specific information from link 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              ]

Greg Colvin<spam@me.not> wrote:
>Nathan Myers <ncm@nospam.cantrip.org>
>>  Al Stevens<alstevens@midifitz.com> wrote:
>> >Greg Colvin wrote:
>> >> On any reasonable implementation you can get the
>> >> standard library back into global namespace with a simple
>> >>   using namespace std;
>> >
>> >That suggestion, which I have often suggested and used, usually evokes an
>> >emotional response from some committee members. They think it is an awful
>> >thing to do.
>>
>> It is an awful thing to teach, because it's a bad habit.  Feel free to
>> do it in the privacy of your own home, but don't present it as sound
>> engineering.
>
>Well, I'm not teaching, I'm coding for a living.  If I have code
>that needs to port to compilers without working namespaces, or a
>lot of existing code that depends on the standard library being
>in global namespace, then I have a problem on a conforming compiler.
>It seems the easiest solution is to just put the library back into
>the global namespace with a using directive.  If you have a better
>suggestion I really would like to hear it.

It's the best approach I know of, for the situation Greg describes.
It's a transitional approach, for a transitional time.

>Anyway, my point was that someone who really doesn't want to use
>namespaces, and who really does want the library global, and who
>really isn't going to be convinced otherwise, should just issue
>the directive and stop complaining.

Exactly.

--
Nathan Myers
ncm@nospam.cantrip.org  http://www.cantrip.org/



[ 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 wrote:
>
> When patent workers have to spend hours
> learning what "xor" means and how memory-mapped video RAM works, they might
> get the impression that drawing an erasable line this way is patentable.  You
> and I know better, but we're not patent workers...

We're also not living at the time when that patent was granted, so not
in a position to make quick judgments about what was and was not obvious
at that time.


[ 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              ]

On 18 Jun 98 04:20:08 GMT, "Daniel Parker" <danielp@nospam.com> wrote:


>Namespaces are wonderful, but there are still the practical issues that need
>to be dealt with.  Like in your example, suppose your company ships two
>libraries, both of which have long namespace names, one of which uses the
>other.  Sure, your customers can use a short alias, but what about your one
>library that uses the other?  does it have to use the long namespace name?

It is free to use any alias it wants to, since the alias only lives as
long as you're compiling. The link name will still be the long
namespace name. If the libraries ship with shorter aliases defined in
their header files, those can (assuming a normal implementation of
headers) be safely edited by users in case of a conflict. If the
library vendor doesn't want to ship any aliases in their headers, then
yes, the headers for one library that uses another must use the long
names. The source files, of course, can still use any alias the
library writer chooses.

-Dave


[ 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 <32_h1.16526$08.3962038@newscene.newscene.com>,
  "Al Stevens" <alstevens@midifitz.com> wrote:

> As one poster said, "...the committee was convinced, after heated and highly
> technical debate, that namespaces were a worthy addition to the language,"
> which says to me that it was not a cut and dried requirement if enough
> members debated heatedly against it, indicating that my experience is not
> unique.

First, there are never any "cut and dried" requirements when standardizing
a language.  Second, the debate involves more than just technical issues;
the main argument against namespaces was that they would delay the standard.
Third, the final vote was something like 35-6 in favor, which doesn't
suggest much dissention.  (I was one of the 6, and I can tell you it
felt pretty lonely.)

--
James Kanze    +33 (0)1 39 23 84 71    mailto: kanze@gabi-soft.fr
        +49 (0)69 66 45 33 10    mailto: jkanze@otelo.ibmmail.com
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient   e objet --
              -- Beratung in objektorientierter Datenverarbeitung

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/   Now offering spam-free web-based newsreading


[ 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              ]

On 18 Jun 98 04:24:54 GMT, "Greg Colvin" <spam@me.not> wrote:

>Well, I'm not teaching, I'm coding for a living.  If I have code
>that needs to port to compilers without working namespaces, or a
>lot of existing code that depends on the standard library being
>in global namespace, then I have a problem on a conforming compiler.
>It seems the easiest solution is to just put the library back into
>the global namespace with a using directive.  If you have a better
>suggestion I really would like to hear it.

I think for the first problem, the best solution is (on the
non-conforming compilers):
#define std

But for the second problem, you can't do better than
using namespace std;


[ 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 <6m9eh8$oio$1@nnrp1.dejanews.com>,
  AllanW@my-dejanews.com wrote:
>
> In article <NOwh1.12171$08.3080430@newscene.newscene.com>,
>   "Al Stevens" <alstevens@midifitz.com> wrote:
> >
> > >namespaces were designed to solve the name pollution problems of the C++
> > >world. In practice this was a minor problem.
> >
> > Actually it was a major problem with K&R C:
> >
> > "Only the first eight characters of an internal name are significant...For
> > external names...the number may be less than eight." The C Programming
> > Language, 1978.

How many third party C libraries were available in 1978:-)?

> > Namespaces do not solve any problem that prefixes didn't already solve
> > (except perhaps the aesthetic ones that Stroustrup perceives).
> Oh, sure they do.  If you won't buy my hypothetical example above, consider
> the very real one I recently dealt with.

Namespaces don't solve any problem that prefixes didn't already solve
(see below).  On the other hand, I don't think there is any argument that
they solve the problem better.  The only questions are how much better,
how much they cost, and are they worth the price.  (Actually, I should
say that the only questions WERE ...  Now that the standard requires
namespaces, I pay the price, or have paid it, and I would be a fool to
not use them.)

> I was converting a process maintenance program from DOS to Windows.  In one
> routine, unusual data in the database triggers an E-mail message to the
> project manager.  We use a third-party tool (whose name I won't mention, but
> no it was NOT Ibm) to send messages automatically.
>
> But it seems that Windows already has a global function named SendMessage.
> (Actually, they have two, named SendMessageU and SendMessageA, and a macro
> definition to translate SendMessage into one of these two other names, but
> we'll ignore that for now... *sigh*).  Anyway, I have two global functions
> with the same name, both with "C" linkage, from completely different
> vendors and completely different purposes.  There are three other name
> collisions too, which I won't go into here.

Well, if a company isn't using prefixes (in pre-namespace code), there's
no reason to suppose that they will use namespaces today.  A company that
doesn't care about its users doesn't care about its users, and namespaces
aren't going to change the attitude of the company.  The answer to that
is to not deal with such companies.

And of course, if the company doesn't ship its code already wrapped in
a namespace, you can't wrap it yourself later.  Not to mention that
namespaces don't help with macros.

> > There is no
> > international (or national, or otherwise) namespace brokerage/clearing
> > house/authority, so you still have the chance that two vendors could choose
> > the same namespace.

There is an international brokerage for prefixes: trademark registry.
I can tell at a glance when I'm dealing with a Rogue Wave header file,
for example, because the prefixes give it a specific general appearance,
much like the shape of a Coke bottle is easily recognizable.  I'm not
sure that putting everything in a common namespace could be registered
as a trademark, however.

--
James Kanze    +33 (0)1 39 23 84 71    mailto: kanze@gabi-soft.fr
        +49 (0)69 66 45 33 10    mailto: jkanze@otelo.ibmmail.com
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient   e objet --
              -- Beratung in objektorientierter Datenverarbeitung

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/   Now offering spam-free web-based newsreading


[ 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 <32_h1.16526$08.3962038@newscene.newscene.com>,
Al Stevens <alstevens@midifitz.com> wrote:
>We coded C and C++ for over 20 years without a namespace feature, and
>somehow we got programs to work. Apparently some people had some problems
>that they laid at the door of namespace pollution. My experience, and that
>of the original poster is that those problems were the exception rather than
>the rule. ...

I very strongly agree with this position.  The problem solved by namespaces
applies only to a small proportion of even very large projects.  It does not
make sense to make the use of namespaces mandatory even in trivial programs,
such as hello world in order to solve the problems of a handful of (in my
opinion) poorly designed projects.  Let that minority who have the problem
use namespaces, and leave the rest of us alone with our working code.

--
Jim Cobban   |  jcobban@nortel.ca                   |  Phone: (613) 763-8013
Nortel (MCS) |                                      |  FAX:   (613) 763-5199


[ 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 <6m9fgu$6b9$1@news.interlog.com>,
  "Daniel Parker" <danielp@nospam.com> wrote:
>
> David R Tribble wrote in message <3587F092.89E@noSPAM.central.beasys.com>...
>
> >>
> >> When Standard C increased that limit to 31 characters, the problem
> >> essentially went away.
> >
>
> Could someone enlighten me as to what the current limit is for C++ class
> names?

1.

To make that clearer: the following program is required to compile on
all conforming implementations, but could conceivably give a different
answer (2) on some:

    #include <iostream>

    int             a1 = 1 ;
    int
    main()
    {
        int             a2 = 2 ;
        std::cout << a1 << '\n' ;
        return 0 ;
    }

Actually, of course, market presure will pretty much assure that no compiler
will treat only one character as significant, even if the standard allows
it.  Given that most compilers will also try and conform to the C standard,
I doubt that we will see any the use less than 32.

The standard does make a non-normative recommendation, however, that an
implementation support at least 1024.

--
James Kanze    +33 (0)1 39 23 84 71    mailto: kanze@gabi-soft.fr
        +49 (0)69 66 45 33 10    mailto: jkanze@otelo.ibmmail.com
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient   e objet --
              -- Beratung in objektorientierter Datenverarbeitung

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/   Now offering spam-free web-based newsreading


[ 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 <6ma16g$fib$1@news.interlog.com>,
  "Daniel Parker" <danielp@nospam.com> wrote:
>
> AllanW@my-dejanews.com wrote in message <6m9ggu$rgk$1@nnrp1.dejanews.com>...
> >In article <6m8qc3$m3d$1@nnrp1.dejanews.com>,
> >  jkanze@otelo.ibmmail.com wrote:
> >> (and to not register the
> >> use of his specific prefix as a registered trademark,
> >We can do that?
>
> Sure.  Just check with your friendly local law firm, and many thousands of
> dollars and a couple of years later, you'll have yourself a trademark valid
> in one country, although you may have to iterate a few times on the name.
> Then repeat this process for all other countries in which you wish to sell
> your software.  Trademarks aren't software patents, by the way.

Have you actually registered a trademark?  I've been told that the process
is quite simple.  (Only told, I have no personal experience.)  Of course,
I would probably want to consult a lawyer.  But if you are starting a
firm to distribute software, you'll probably have to consult a lawyer anyway.
I would guess the total cost around a thousand dollars (not many thousands),
probably less.

--
James Kanze    +33 (0)1 39 23 84 71    mailto: kanze@gabi-soft.fr
        +49 (0)69 66 45 33 10    mailto: jkanze@otelo.ibmmail.com
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient   e objet --
              -- Beratung in objektorientierter Datenverarbeitung

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/   Now offering spam-free web-based newsreading

[ 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 <35886d28.214524542@news.motu.com>,
  abrahams@motu.com wrote:

> Anyone who writes a C++ namespace-wrapped library for Win32 which
> cleans up these problems is my instant hero.

I don't know the policy of ILog here -- I used Views with a compiler
which didn't support namespaces.  But they do use prefixes very consistently.
(I also don't know what platforms they are available for, other than
the ones we used, or were considering: Sun Solaris, HP-UX and Windows NT.)

This has also been the policy of every other third party library I've used,
with the exception of the USL class library.

--
James Kanze    +33 (0)1 39 23 84 71    mailto: kanze@gabi-soft.fr
        +49 (0)69 66 45 33 10    mailto: jkanze@otelo.ibmmail.com
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient   e objet --
              -- Beratung in objektorientierter Datenverarbeitung

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/   Now offering spam-free web-based newsreading


[ 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              ]

David Abrahams wrote in message <358940f0.268749141@news.motu.com>...
>On 18 Jun 98 04:20:08 GMT, "Daniel Parker" <danielp@nospam.com> wrote:
>
>

>>Sure, your customers can use a short alias, but what about your one
>>library that uses the other?  does it have to use the long namespace name?
>
>It is free to use any alias it wants to, since the alias only lives as
>long as you're compiling. The link name will still be the long
>namespace name.

Clearly, but what about references that are made in inlined code and
templated code, not compiled code?  That's what I was concerned with.

--
Regards,
Daniel Parker danielp@no_spam.anabasis.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 <6m9at4$t38@engnews1.Eng.Sun.COM>,
  clamage@Eng.Sun.COM (Steve Clamage) wrote:
>
> jkanze@otelo.ibmmail.com writes:
>
> >In article <6m6ndq$clm@engnews1.Eng.Sun.COM>,
> >  stephen.clamage@sun.com (Steve Clamage) wrote:
>
> >> Implementations are allowed to add content to namespace std,
> >> so the using-directive may bring more than you bargained for
> >> into your program.
> >>
> >> By way of comparison, C has the rule that implementations may
> >> add content to the global namespace, but only using names
> >> reserved to the implementation.  I don't recall ever seeing a
> >> C implementation that followed that rule. With namespaces, the
> >> rule is self-enforcing for C++.
>
> >I don't know.  I have two library implementations immediately
> >available: the STL Port (3.01) and VC++ (5.0).  The STL Port (which
> >I believe is a direct copy of the SGI implementation) defines macros
> >with names that C declares in the user namespace.  As far as I can
> >tell, VC++ doesn't (although it would be easy to have missed one), but
> >it still shares headers between C and C++, with many of the "functions"
> >in the C library implemented as macros (which is, I believe, illegal
> >according to the C++ standard).  I see no reason to expect this to
> >improve.
>
> I think we are speaking to different points.

I'm only elaborating on your statement that "don't recall ever seeing
a C implementation that followed that rule."  A quick check of the
few data points I had available suggested that this would also be
the case for C++ -- that whatever the standard says, implementations
will polute the user name space somewhat.

I expect that the problem will be less in C++, but I don't expect it
to disappear.  For one thing, implementations will continue to offer
access to non-standard extensions, and these will often involve common
headers with C, and functions in global namespace.  (Or will Sun wrap
all of the functions in unistd.h in a special namespace?)  Of course,
once I invoke such extensions, I have left the world of what the standard
guarantees.  But if I don't invoke them, I don't write very many useful
programs.

My major point wasn't so much that namespaces aren't good -- they are
superior to prefixes, for several reasons.  It was more that all name
space polution problems aren't miraculously going to disappear just because
the language has namespaces.  Other points I've made (or tried to make)
in other postings are that, at least in the environments I generally
work in, name space polution hasn't been a serious problem in the past,
so that there was no PRESSING need for a better solution, and that,
having already "paid" for namespaces, I'd be a fool not to use them,
because they are a better solution.

I think that the above three points are facts.  Now for the opinion (which
isn't important anyway, because it concerns the past, and what should have
been done): we needed a C++ standard much, much earlier.  It is difficult
to estimate how much any one new feature cost, but globally, I would guess
that the sum of all the new features cost us at least three years.  That's
three years that I've had to live without a standard, and three years more
that I'll have to wait to have stable and compatible compilers on all major
platforms.  In the case of namespaces, I don't think the advantages justified
the price, in general.  Globally, it is more difficult -- they certainly
didn't for my applications, but I know others (with different constraints)
who could hardly be using C++ without some of the new template features.
I still think we'd have done better standarizing what we had (roughly,
CFront 3.0), and then going on from there.  (Think about it: if we had,
we'd be preparing for the first revision in only two more years.  And
because we had a stable base language, we could be considering some really
useful features, like garbage collection, or real modules.)

--
James Kanze    +33 (0)1 39 23 84 71    mailto: kanze@gabi-soft.fr
        +49 (0)69 66 45 33 10    mailto: jkanze@otelo.ibmmail.com
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient   e objet --
              -- Beratung in objektorientierter Datenverarbeitung

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/   Now offering spam-free web-based newsreading


[ 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 <6mbg34$sff$1@nnrp1.dejanews.com>,
 <jkanze@otelo.ibmmail.com> wrote:

> To make that clearer: the following program is required to compile on
> all conforming implementations, but could conceivably give a different
> answer (2) on some:

>     #include <iostream>

>     int             a1 = 1 ;
>     int
>     main()
>     {
>         int             a2 = 2 ;
>         std::cout << a1 << '\n' ;
>         return 0 ;
>     }

Not true.  The C++ standard explicitly says that all characters of an
identifier are significant, so a conforming implementation is not
permitted to decide that a1 and a2 are really the same identifier.

What an implementation *is* permitted to do is to reject this
program on the basis that it does not have enough capacity to
deal with 2-character identifiers that aren't part of the
standard library.  Analogously, a strictly conforming C compiler
is permitted to reject the following C program for the same reason:

 #include <stdio.h>

 int a1 = 1;

 main()
 {
  int a2 = 2;

  printf("%d\n", a1);
  return 0;
 }

Although the C standard gives lower bounds on capacity limitations,
it requires only that a compiler be able to compile a single program
that simultaneously meets all the bounds.  Implementations are permitted
to reject other programs if they like :-)

In both cases, of course, the marketplace would reject any compiler
that rejected these programs.
--
    --Andrew Koenig
      ark@research.att.com
      http://www.research.att.com/info/ark



[ 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              ]

jkanze@otelo.ibmmail.com wrote in message
<6mbhfe$ufk$1@nnrp1.dejanews.com>...
>In article <6ma16g$fib$1@news.interlog.com>,
>  "Daniel Parker" <danielp@nospam.com> wrote:
>>
>Have you actually registered a trademark?  I've been told that the process
>is quite simple.

Started the process up about a year ago for Canada and the U.S.  About eight
months later, got a request for narrowing the description from one of the
countries.  Expect to here back in another six to ten months.  The two
problems are (1) the sheer length of time it takes to get a response, (2)
the fact that you have to get a separate trademark for each country.  A good
part of the cost is the preliminary searching you have to do to avoid the
problem of discovering a couple of years later that somebody else has the
right to the trademark, there's no central registry of trademarks in the
U.S., for example, there are many databases that need to be searched, and
even then you don't know for sure.  Once you have a trademark, you need your
law firm to monitor for applications for a similiar mark, and to protest if
there are any.  With marks, if you don't protect them, you lose them.

--
Regards,
Daniel Parker danielp@no_spam.anabasis.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              ]

Clive Bluston wrote:
>
> namespaces were designed to solve the name pollution problems of the C++
> world. In practice this was a minor problem. I have worked on several
> large projects and only had to make a few changes here and there due to
> name space pollution.
> On the other hand I seem to spend vast amounts of time these days trying
> to get third party code compiled. Most of the time the problem comes
> down to namespace related code. Not only that, when you look at the
> attemts of library writers to get their code to compile in various
> environments, you see that they have introduced large number of macros,
> making the pollution problem even worse!

Are any of these problems fundamental to namespaces, or are they the
result of trying to deal with various degrees of conformance in
different compilers? If it's the latter, then you can expect the
problems to go away with time.
 -- Pete


[ 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 <3584E215.9BC23434@emultek.co.il>, clive@emultek.co.il wrote:

> My conclusion is that though the namespace solution looked nice on
> paper, in practice it is a disaster, and has taken C++ a step back
> instead of forward.

The addition of namespaces are a major change in the language.  It is
amazing just how much this addition effects both compilers and libraries.

However, IMO what you are seeing is the effect of the **transition** to
namespaces as opposed to the namespace itself.  All transitions are
painful.  The bigger the more so.  But I think that namespaces are worth
the pain of transition.

-Howard


[ 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              ]

On 16 Jun 98 19:15:41 GMT, "Al Stevens" <alstevens@midifitz.com>
wrote:

>> On any reasonable implementation you can get the
>> standard library back into global namespace with a simple
>>   using namespace std;
>
>That suggestion, which I have often suggested and used, usually evokes an
>emotional response from some committee members. They think it is an awful
>thing to do.
>
>>so I have to wonder just what problem namespace std is giving you.
>
>
>And I have to wonder what previous overwhelming problem namespaces solves. I
>think a lot of people wanted them who did not necessarily need them. My
>problem as a writer was with the issue during the transition, not with any
>particular code as a programmer. My position on that is in the public
>record.

I guess you've never had to link a large existing program with a large
existing library. I recently had to, and though they were not already
in namespaces, the most expedient solution was to wrap the entire
library in a namespace. Some of the code was written by the same
people; some of it was even copied from the program to the library.
The number of conflicting names was enormous. Just think: thousands of
names declared in source files waiting to cause problems when a
conflicting definition showed up in a header! Conflicting function
names and global variables! Lurking unpredictabilities!

Now that's a real-world case. I agree that namespaces are hard to
understand how to use. But for new code, once you figure out how to
use them, they confer enormous benefits in terms of program
organization and code readability. I lament the lack of a good set of
publicly-available guidelines for the use of namespaces. A friend of
mine was working on such a series of articles; I hope he'll finish
them soon!

-Dave


[ 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> wrote:
>> On any reasonable implementation you can get the
>> standard library back into global namespace with a simple
>>   using namespace std;
>
>That suggestion, which I have often suggested and used, usually evokes an
>emotional response from some committee members. They think it is an awful
>thing to do.

It is an awful thing to teach, because it's a bad habit.  Feel free to
do it in the privacy of your own home, but don't present it as sound
engineering.

>>so I have to wonder just what problem namespace std is giving you.
>
>And I have to wonder what previous overwhelming problem namespaces solves.
>I think a lot of people wanted them who did not necessarily need them. My
>problem as a writer was with the issue during the transition, not with any
>particular code as a programmer. My position on that is in the public
>record.

It solves problems faced by library writers.  If you are not a writer
of widely-used libraries, you probably will not have faced these problems
much.

Many criticisms of the standard take the form, "I've never needed this
feature, so it shouldn't be there."  The committee had representatives
from many backgrounds, and the standard reflects this broad experience.
This is a good thing.  That not everybody needs every feature all the
time should be no surprise.  There are roads all over the world you've
never driven on.

--
Nathan Myers
ncm@nospam.cantrip.org  http://www.cantrip.org/



[ 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 <6m6ndq$clm@engnews1.Eng.Sun.COM>,
  stephen.clamage@sun.com (Steve Clamage) wrote:

> Implementations are allowed to add content to namespace std,
> so the using-directive may bring more than you bargained for
> into your program.
>
> By way of comparison, C has the rule that implementations may
> add content to the global namespace, but only using names
> reserved to the implementation.  I don't recall ever seeing a
> C implementation that followed that rule. With namespaces, the
> rule is self-enforcing for C++.

I don't know.  I have two library implementations immediately
available: the STL Port (3.01) and VC++ (5.0).  The STL Port (which
I believe is a direct copy of the SGI implementation) defines macros
with names that C declares in the user namespace.  As far as I can
tell, VC++ doesn't (although it would be easy to have missed one), but
it still shares headers between C and C++, with many of the "functions"
in the C library implemented as macros (which is, I believe, illegal
according to the C++ standard).  I see no reason to expect this to
improve.

In the end, namespaces which don't include macros really don't buy us
that much (except a more complicated name lookup).  Even if namespaces
included macros, if a vendor in prenamespace time was stupid enough to
deliver his libraries without using prefixes (and to not register the
use of his specific prefix as a registered trademark, sort of like
Coca Cola registered the shape of its bottle), then why should I expect
him to suddenly use namespaces intelligently?

--
James Kanze    +33 (0)1 39 23 84 71    mailto: kanze@gabi-soft.fr
        +49 (0)69 66 45 33 10    mailto: jkanze@otelo.ibmmail.com
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient   e objet --
              -- Beratung in objektorientierter Datenverarbeitung

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/   Now offering spam-free web-based newsreading


[ 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              ]

Somebody wrote:
>> namespaces were designed to solve the name pollution problems of the C++
>> world. In practice this was a minor problem.

Al Stevens wrote:
> Actually it was a major problem with K&R C:
> "Only the first eight characters of an internal name are significant...For
> external names...the number may be less than eight." The C Programming
> Language, 1978.
>
> When Standard C increased that limit to 31 characters, the problem
> essentially went away.

Except for external names, which were still only guaranteed to be unique
to 8 characters.  C9X increases the minimum to 31 characters (and 63 for
internal names), so for operating systems that didn't already support
long external names, the problem will be lessened in the next few years.

> Library makers could use prefixes to at least try to
> uniquely qualify their names. In D&E, Stroustrup deprecates this practice
> because it is "ugly" as if namespaces are pretty and because long prefixes
> are "unpleasant" as if long namespaces are pleasant. It is a matter of
> perception.
>
> Namespaces do not solve any problem that prefixes didn't already solve
> (except perhaps the aesthetic ones that Stroustrup perceives).

Indeed.  Namespaces are nothing more than fancy prefixes.

But how much code have you seen (especially in programming magazines)
that actually bothered to use unique prefixes?  How likely is the
average
programmer to affix a prefix to the code he writes (not to mention
declaring private free functions and variables as 'static' to keep them
out of the external namespace)?  At least by inventing namespaces and
encouraging the use of 'std::' the C++ committee is forcing programmers
to think about the consequences of their external names more than they
did in the past.  There will still be programmers, no doubt, who will
not
use namespaces, or prefixes, in the years to come, but at least they can
take comfort that the libraries they link with won't collide with their
names.

And namespaces also provide a solution to the the problem of code
versioning.  If I change the contents of class Foo by adding or
rearranging member variables and virtual functions in the next release,
code compiled to run against the previous version will still link but
will break during runtime.  If I put Foo into a namespace with a version
suffix (such as 'com_beasys_1_00::'), the incompatibility will be caught
by the linker.  Try doing that with simple name prefixes.

> There is no
> international (or national, or otherwise) namespace brokerage/clearing
> house/authority, so you still have the chance that two vendors could choose
> the same namespace.

But there is a clearinghouse for web addresses, which Java decided to
take advantage of for its package naming convention.  We could start
doing
the same for C++ namespaces.  For instance, the company I work for has
an
internet web address of "beasys.com", so I could put all of the code I
write for them into the namespace "com_beasys::" (or "COM_BEASYS::", or
even the nested namespace "Com::BeasSys::").  If I wanted to be more
specific, because my library is separate from the other libraries
developed by the other departments in my company, I could use a longer
name like 'com_beasys_productname::'.  Since C++ allows namespace
'aliases', I can easily equate this to a shorter, more convenient prefix
(like 'bea::') in my header files for end users of my library.

Following this convention would minimize the possibility of namespace
collisions.  (The only problem is what to do when the company changes
its
web address, or gets bought out by another company.  But again,
namespace
aliases can solve this, too.)

> I think that a long time ago the "namespace problem" was deeply felt, and
> long after it had been effectively addressed with a simple solution,
> language framers felt compelled to solve it again with a complicated one.
> This is not a popular opinion, but my experience is the same as yours. I
> never had a problem with namespace issues until C++ compilers implemented
> namespaces and added the std namespace to the libraries.

We are all going to have to suffer to some degree during the transition
to standard ISO C++, which will probably take at least another two or
three years.  Just like we all had to suffer for about three years while
the compiler vendors caught up to the ISO C89 standard (remember?).

I for one support the move to the 'std::' namespace prefix.  In fact,
I've always felt that the C standard library names should have a 'std_'
prefix, and the operating system library names should have a 'sys_' or
'os_' prefix, for the simple reason that far too many of the standard
library names can collide with the names I'd like to use for my code.
Names like 'errno' and 'open' are far too useful to be restricted to
an unprefixed namespace.

I think C++ is moving in the right direction with the 'std::' prefix.
Hopefully, POSIX and the other operating systems will follow ISO's lead
and start putting the system library functions into 'sys::' or the like
in the near future.

Yes, having to specify 'std::' can be a pain, especially when converting
old code.  But it increases readability, maintainability, and lessens
the
possibilitied of collisions with future code.  In the long run, it will
save time, money, and frustration.  You *will* get used to coding
'std::errno' some day.  So in the long run it's the Right Thing To Do.

-- David R. Tribble, david.tribble@central.beasys.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              ]

>I guess you've never had to link a large existing program with a large
>existing library.

Only lots of times in the past 33 years since I first used assemblers and
compilers that built relocatable object modules.

>The number of conflicting names was enormous. Just think: thousands of
>names declared in source files waiting to cause problems when a
>conflicting definition showed up in a header! Conflicting function
>names and global variables! Lurking unpredictabilities!

Let me oversimplify and generalize without knowing any more detail than you
provided. Thousands of external identifiers that should not have been in
global scope in the first place.You just described bad code from naive
programmers who do not understand the basics of that old chestnut,
encapsulation, nee information hiding. So I guess it is necessary to build
features into programming languages to circumvent such bad programming.
Given that guideline I can think of dozens of other features we could have
added.

>Now that's a real-world case. I agree that namespaces are hard to
>understand how to use.

Really? I think in principle, the feature is quite small and elegant. I just
don't think it's all that necessary and that it can be unwieldy to cope with
particularly if all those naive programmers are turned loose on it.

>I lament the lack of a good set of publicly-available guidelines for the
use of namespaces.

You got that right. And for the assignment of namespace names, too.
---
[ 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 believe you are overstating the case and the responses you may have
received.


    BUCK: He also has some suggestions for implementers as to how they can
limit the damage: e.g. includes and also does "using namespace std;" so that
"Hello, world" still works.
   CLAMAGE: That is a truly bad suggestion.

That was one of the less emotional responses I read. :-)



[ 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              ]

>It is an awful thing to teach, because it's a bad habit.  Feel free to
>do it in the privacy of your own home, but don't present it as sound
>engineering.

See what I mean?

>It solves problems faced by library writers.  If you are not a writer
>of widely-used libraries, you probably will not have faced these problems
>much.

I am and I have not. But then, I tend to put only those names that users
need (function names, class names) in global scope.

>The committee had representatives
>from many backgrounds, and the standard reflects this broad experience.

That's a pretty good description of a committee and a committee-designed
product--horses and camels and all that. (he said, ducking)

>There are roads all over the world you've never driven on.

But I've never looked at an unfamiliar road and said, "What's that for?"
---
[ 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              ]

>But how much code have you seen (especially in programming magazines)
>that actually bothered to use unique prefixes?

Seen? Written!

>How likely is the average
>programmer to affix a prefix to the code he writes (not to mention
>declaring private free functions and variables as 'static' to keep them
>out of the external namespace)?  At least by inventing namespaces and
>encouraging the use of 'std::' the C++ committee is forcing programmers
>to think about the consequences of their external names more than they
>did in the past.

I guess I'm not really confortable with the argument that a feature exists
to force bad programmers to be good ones.

> We could start doing the same for C++ namespaces.

By voluntary convention or with some kind of authority backing it up?

>We are all going to have to suffer to some degree during the transition
>to standard ISO C++, which will probably take at least another two or
>three years.

I don't mind you telling me I have to suffer if you don't mind my whining
about it.

>I for one support the move to the 'std::' namespace prefix.  In fact,
>I've always felt that the C standard library names should have a 'std_'
>prefix

Tell that to Microsoft, whose interpretation of the standard specification
allows them to leave all the C names in the global namespace irrespective of
which header you include.

>You *will* get used to coding 'std::errno' some day.  So in the long run
it's the Right Thing To Do.

Kicking and screaming, I'm already doing it (well not for errno; who uses
errno?) because the majority of my code is published and has to at least
look like it's contemporary, a phenomenom of the trade press that restricts
me to those few platforms where almost compliant compilers are available.



[ 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              ]

jkanze@otelo.ibmmail.com writes:

>... if a vendor in prenamespace time was stupid enough to
>deliver his libraries without using prefixes (and to not register the
>use of his specific prefix as a registered trademark, sort of like
>Coca Cola registered the shape of its bottle), then why should I expect
>him to suddenly use namespaces intelligently?

Converting a project to use namespaces in a moderately intelligent fashion
should be easier than converting it to use prefixes.

In my experience, introduction of prefixes into a project developed
without them is a major hassle.

--
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3        |     -- the last words of T. S. Garp.


[ 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              ]

David R Tribble <david.tribble@noSPAM.central.beasys.com> wrote:
> Namespaces are nothing more than fancy prefixes.

Not so.  Namespaces have semantics of their own.  Perhaps some of
the problems some people have comes from an expectation that they
are nothing but fancy prefixes.  For example:

-... namespaces also provide a solution to the the problem of code
-versioning.  ... If I put Foo into a namespace with a version
-suffix (such as 'com_beasys_1_00::'), the incompatibility will be caught
-by the linker.  Try doing that with simple name prefixes.

It also provides a possibility to link groups of names and allow
you to disambiguate explicitly where they are used, rather than
where they are declared.  Try that with (fancy) prefixes.

>> There is no
>> international (or national, or otherwise) namespace brokerage/clearing
>> house/authority, so you still have the chance that two vendors could
>> choose the same namespace.
>
>But there is a clearinghouse for web addresses, which Java decided to
>take advantage of for its package naming convention.  We could start
>doing the same for C++ namespaces. ...
>If I wanted to be more specific, because my library is separate from
>the other libraries developed by the other departments in my company,
>I could use a longer name like 'com_beasys_productname::'.

I believe that any convention of adopting company, division, or
trademarked product names in namespace names will cause very serious
problems.  (Trademarked aliases are OK.)  The Java people will suffer
for it, perhaps in time for users of C++ to notice.  Aliases can't
fix the problem, but they will be used to try to hide it, later.

>I think C++ is moving in the right direction with the 'std::' prefix.
>Hopefully, POSIX and the other operating systems will follow ISO's lead
>and start putting the system library functions into 'sys::' or the like
>in the near future.

This would be most welcome.  The GNU C library will be following a path
much like this, and it may be that a complete "reference implementation"
will be ready for them to rubber-stamp soon.

>In the long run, it will
>save time, money, and frustration.  You *will* get used to coding
>'std::errno' some day.  So in the long run it's the Right Thing To Do.

Hmmm, errno will probably be a macro forever.  But there's hope
for putchar!  After all, nobody (not even SCO! :-) has

  #define remove unlink

in their system headers any more.

--
Nathan Myers
ncm@nospam.cantrip.org  http://www.cantrip.org/



[ 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 <NOwh1.12171$08.3080430@newscene.newscene.com>,
  "Al Stevens" <alstevens@midifitz.com> wrote:
>
> >namespaces were designed to solve the name pollution problems of the C++
> >world. In practice this was a minor problem.
>
> Actually it was a major problem with K&R C:
>
> "Only the first eight characters of an internal name are significant...For
> external names...the number may be less than eight." The C Programming
> Language, 1978.
>
> When Standard C increased that limit to 31 characters, the problem
> essentially went away. Library makers could use prefixes to at least try to
> uniquely qualify their names. In D&E, Stroustrup deprecates this practice
> because it is "ugly" as if namespaces are pretty and because long prefixes
> are "unpleasant" as if long namespaces are pleasant. It is a matter of
> perception.

Well, they are.  Take a hypothetical example: IBM's E-Mail Research department
decides to create a brand-spankin' new E-mail package.  The "Obvious" names
for classes in the package are Message, Address, Attachment, etc.  But this
would quickly lead to problems.  Start with the standard C++ library -- even
if these names don't conflict with any names there today, they certainly could
next year.  (Message and Address are especially frightning names, because
each of those terms have meaning outside the problem domain.)

So the natural second choice is IbmMessage, IbmAddress, IbmAttachment, and so
on.  We're getting much better, but then we find out our own sample
application bombs -- it turns out we're trying to download mail from our
CICS mainframe, and that requires a package that already defined class
IbmMessage.

We move to our third choice, IbmEmailMessage, IbmEmailAddress,
IbmEmailAttachment, and so on.  This won't conflict with IbmCicsMessage, so
the problem is solved.

Except that there's a lot to go wrong for the user that has to type:
    IbmEmailMessageNumber MyClass::SendMail(IbmEmailMessage msg,
        vector<IbmEmailAddress> sendto, vector<IbmEmailAddress> cc,
        vector<IbmEmailAttachment> attach) {
        // ...
    }
It's true that simple spelling errors are caught by the compiler, so debugging
is not too big an issue.  But give the poor little programmer a break!  A
better method involves the use of typedefs:
    typedef IbmEmailMessage       msg;
    typedef IbmEmailAddress       msgAddr;
    typedef IbmEmailAttachment    msgAttach;
etc.  This works out well until the same typedef names are used by some other
package.  At that point we have a different problem.

The new problem is easer to solve.  If both packages put all of their typedefs
into a separate header file, which is not required in order to use the
package by it's full name, then all the user has to do is put the
IbmEmail-specific routines in one compilation unit (which uses our typedefs
from our header file) and the routines specific to the other library into
a different compilation unit (which uses the other typedefs from the other
header file).  If there are any INDIVIDUAL ROUTINES that need access to both
libraries, they can usually be trivially redefined to remove this dependancy,
but if we can't or won't do that, we simply fall back to using the long names
FOR THAT ONE ROUTINE and all is well.

Now compare that mechanism to the namespace solution.

    namespace IbmMail {
        class Message;
        class Address;
        class Attachment;
        // ...
    }
The header file has some minor syntax differences, but the only real change
is to factor out the letters "IbmMail" from every public name and put them
in the namespace instead.

Application code that is specific to IbmMail can use:
    using namespace IbmMail;
which accomplishes exactly the same thing as the old file full of typedefs.
That is, it brings short and useful names into scope as synonyms for the
long and safe names that the linker sees.

Application which needs to use both IbmMail and some other package with a
Message class, can simply omit this line.  The very few routines in that
situation simply continue to use the long names, such as
    IbmMail::Message msg;

Now I'm not saying that the end result of all of this is any better than the
first method.  It simply saves the poor programmer's fingers, and
incidentally, it's a lot easier to read, once you're used to it.

I hope you're not going to argue that since one method works, we should never
ever invent a newer method to replace it?

> Namespaces do not solve any problem that prefixes didn't already solve
> (except perhaps the aesthetic ones that Stroustrup perceives).
Oh, sure they do.  If you won't buy my hypothetical example above, consider
the very real one I recently dealt with.

I was converting a process maintenance program from DOS to Windows.  In one
routine, unusual data in the database triggers an E-mail message to the
project manager.  We use a third-party tool (whose name I won't mention, but
no it was NOT Ibm) to send messages automatically.

But it seems that Windows already has a global function named SendMessage.
(Actually, they have two, named SendMessageU and SendMessageA, and a macro
definition to translate SendMessage into one of these two other names, but
we'll ignore that for now... *sigh*).  Anyway, I have two global functions
with the same name, both with "C" linkage, from completely different
vendors and completely different purposes.  There are three other name
collisions too, which I won't go into here.

> There is no
> international (or national, or otherwise) namespace brokerage/clearing
> house/authority, so you still have the chance that two vendors could choose
> the same namespace.

That could happen if vendors started using names like Email or Tools.  But
a more wise choice would indicate both the organization name and the problem
domain.  Remember, application code doesn't need to be wrapped in a namespace.
It's not until you begin to make code reusable that this becomes valuable.
Weather you're making a common class for applications in your own
programming unit, or creating a bullet-proof library for worldwide sales,
you now have the chance to be used in ways and environments you didn't
originally envision.  That's when you use namespaces.

A good namespace choice would include both the organization name and the
problem domain.  Although this doesn't guarantee uniqueness, it is normally
sufficient -- there's not all that much occurance of two companies with the
same or very similar names, both selling general-purpose C++ software
libraries with similar purposes.  So namespaces of the form
    namespace CompanyPackage
are unlikely to have collisions.  (It's not impossible, but it's unlikely.)
For instance, MicrosoftWindows or RogueWaveTools or BorlandObjectWindows
or MidifitzAutoAccompany are reasonably safe namespace names, which in most
cases won't need to be typed by the user more than once per translation unit.
(I suppose a company named Rogue could create a package named WaveTools,
which would collide with Rogue Wave's Toolbox.  But this seems unlikely
to be an accident.)

> I think that a long time ago the "namespace problem" was deeply felt, and
> long after it had been effectively addressed with a simple solution,
> language framers felt compelled to solve it again with a complicated one.
> This is not a popular opinion, but my experience is the same as yours. I
> never had a problem with namespace issues until C++ compilers implemented
> namespaces and added the std namespace to the libraries.

I do have problems with namespace.  It takes getting used to.  I'm starting
to get there, though.

I also had a problem with
    int root_length(const char*filename)
    {
        for (int i=0; filename[i]; ++i)
            if (filename[i]=='.') break;
        return i;
    }
breaking.  Frankly, I always figured that the scope should only apply to
the for-loop body, but I got used to it being the other way around.  Now
that it's finally been decided the other way, I'll have to get used to it
again...  It should be worth it, but I won't be happy until I'm past the
pain...

(... ugh ... ugh ... ugh ...)

Okay, now I'm past the pain.  Hey, this scope thing with variables declared
in for() is a great idea!

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/   Now offering spam-free web-based newsreading


[ 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 <6m8qc3$m3d$1@nnrp1.dejanews.com>,
  jkanze@otelo.ibmmail.com wrote:
> In the end, namespaces which don't include macros really don't buy us
> that much (except a more complicated name lookup).  Even if namespaces
> included macros, if a vendor in prenamespace time was stupid enough to
> deliver his libraries without using prefixes

Microsoft has the ultra-mega example of this, in the form of Windows.H.
There are hundreds of functions and almost as many structures.  This is
the original API designed for C.  MFC was Microsoft's attempt at making
it C++ -friendly, and in some ways they succeeded, but it still has to
#include most of windows.h -- so the same global names pollute in the
same way that they always have.  This also crosses compiler platforms
to (all?) C++ compilers which target Microsoft Windows.

Not that I'm complaining (job security, and all that), but it does seem
a lot more messy than it should be, even pre-namespace.

> (and to not register the
> use of his specific prefix as a registered trademark,
We can do that?  We've just been assuming that other libraries weren't
deliberately hostile, so a simple prefix to avoid accidents was sufficient.
(Sort of like the C++ philosophy on encapsulation: protect against
accidents, not fraud.)

> sort of like Coca Cola registered the shape of its bottle),
But that's tangible.  They can patent their bottle shape, because any moron or
patent worker can see the bottle shape with no special tools.  But software
patents are a different story.  When patent workers have to spend hours
learning what "xor" means and how memory-mapped video RAM works, they might
get the impression that drawing an erasable line this way is patentable.  You
and I know better, but we're not patent workers...

...Don't get me started.  Software patents should be illegal.  But that's a
whole other topic, which belongs in a whole other newsgroup, and there's a
reason I don't read that other newsgroup.

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/   Now offering spam-free web-based newsreading


[ 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              ]

David R Tribble wrote in message <3587F092.89E@noSPAM.central.beasys.com>...

>>
>> When Standard C increased that limit to 31 characters, the problem
>> essentially went away.
>

Could someone enlighten me as to what the current limit is for C++ class
names?  I had a quick glance through Stroustrup 3rd ed, but couldn't find
it.

>internet web address of "beasys.com", so I could put all of the code I
>write for them into the namespace "com_beasys::" (or "COM_BEASYS::", or
>even the nested namespace "Com::BeasSys::").  If I wanted to be more
>specific, because my library is separate from the other libraries
>developed by the other departments in my company, I could use a longer
>name like 'com_beasys_productname::'.  Since C++ allows namespace
>'aliases', I can easily equate this to a shorter, more convenient prefix
>(like 'bea::') in my header files for end users of my library.
>
Namespaces are wonderful, but there are still the practical issues that need
to be dealt with.  Like in your example, suppose your company ships two
libraries, both of which have long namespace names, one of which uses the
other.  Sure, your customers can use a short alias, but what about your one
library that uses the other?  does it have to use the long namespace name?
And if it does, do you show that long name in your printed reference
manuals, say in a function prototype?

--
Regards,
Daniel Parker danielp@no_spam.anabasis.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              ]

Nathan Myers <ncm@nospam.cantrip.org> wrote in article <6m846p$6uv$1@shell7.ba.best.com>...
>  Al Stevens<alstevens@midifitz.com> wrote:
> ...
> >...
> >Greg Colvin wrote:
> >> On any reasonable implementation you can get the
> >> standard library back into global namespace with a simple
> >>   using namespace std;
> >
> >That suggestion, which I have often suggested and used, usually evokes an
> >emotional response from some committee members. They think it is an awful
> >thing to do.
>
> It is an awful thing to teach, because it's a bad habit.  Feel free to
> do it in the privacy of your own home, but don't present it as sound
> engineering.

Well, I'm not teaching, I'm coding for a living.  If I have code
that needs to port to compilers without working namespaces, or a
lot of existing code that depends on the standard library being
in global namespace, then I have a problem on a conforming compiler.
It seems the easiest solution is to just put the library back into
the global namespace with a using directive.  If you have a better
suggestion I really would like to hear it.

Anyway, my point was that someone who really doesn't want to use
namespaces, and who really does want the library global, and who
really isn't going to be convinced otherwise, should just issue
the directive and stop complaining.

Greg Colvin
---
[ 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              ]

namespaces were designed to solve the name pollution problems of the C++
world. In practice this was a minor problem. I have worked on several
large projects and only had to make a few changes here and there due to
name space pollution.
On the other hand I seem to spend vast amounts of time these days trying
to get third party code compiled. Most of the time the problem comes
down to namespace related code. Not only that, when you look at the
attemts of library writers to get their code to compile in various
environments, you see that they have introduced large number of macros,
making the pollution problem even worse!

My conclusion is that though the namespace solution looked nice on
paper, in practice it is a disaster, and has taken C++ a step back
instead of forward.


[ 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              ]