From: Paul Bibbings on
Goran wrote:
> On Jul 1, 4:54 pm, "Martin B." <0xCDCDC...(a)gmx.at> wrote:
>> Is an anonymous / unnamed namespace unique to the translation unit or is
>> it simply unique, that is, is the following legal:
>>
>> *** file.cpp ***
>> // ...
>> namespace {
>> int HelperFn(double d);};
>>
>> // ...
>> void ExternalFn() {
>> // ...
>> int x = HelperFn(1.0);
>> // ...}
>>
>> // ...
>> namespace { // Is this the *same* anonymous namespace as above?
>> int HelperFn(double d) {
>> // ...
>> return l;
>> }};
>>
>> *** ***
>>
>> It works on VC++2005 but is it std behaviour?
>
> Dunno about a standard, but e.g. GCC 3.4.5, MS ccompiler from VS 2008
> and comeau online don't like it. HelperFn is a doubly-defined symbol
> for all three.
>
> Bug in VC2005?

Are you sure that you have provided the code exactly as given by the OP to the
three compilers that you mention? Having fed it myself to gcc-3.4.4, VS2008
(Express) and Comeau, the most that I get is a couple of warnings from Comeau
about the extraneous `;'s at the end of the two namespace definitions.

Regards

Paul Bibbings

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Jens Schmidt on
Francis Glassborow wrote:

> Ric Parkin wrote:
>> where all uses of unique in a translation unit are replaced by the
>> same identifier, and this identifier differes from all others in the
>> entire programme.
>
> Well that is the intention though I am not sure how an implementer can
> guarantee it. Yes we can make it very unlikely that a generated unique
> identifier is not actually unique but it is not proof against
> Machiavelli. (generate an object file, clone it by another name and then
> link both files into the same executable.)

The "name" seen by the linker may contain more than just characters. It
may be a struct containing even virtual fields like the identity of the
object file. This is just a platform problem. C++ already provided some
problems where traditional linkers and object formats had to change. Why
not one more?

>> ie even though uses the term "unnamed" the standard actually says it
>> has a name, it's just that you don't know what it is so can't use it.
>
> Yes, I first came across the concept in Forth. There has to be a name
> but it is unutterable (by the programmer). Actually Forth had a really
> unutterable name that it used for vocabulary roots, ' ' (i.e. a space)
> which was impossible for the programmer to utter from the keyboard
> (whitespace has no significance outside the inner workings of the
> implementation).

PostScript, which is very similar to Forth, has a conversion operator
string->symbol. So you can generate any name you want by using that
conversion to avoid the parser. I don't know Forth well enough, but it
might have such a conversion too.

> Unfortunately C++ cannot be quite so clever because the
> names have to be readable by the linker.

Linkers usually have a much larger set of acceptable characters for
names as compilers have. There is no need to make them parseable, they
are just copied and compared.

Then there is the very old method used by C: all C symbols were prepended
by an underscore, so the whole range of symbols starting with letters
was reserved to the implementation.
--
Greetings,
Jens Schmidt


[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]