Hi guys,

This is my first time posting question here, if I break any rules,
please kindly point out. And I'm really glad to be a part of this
community.

Here is my question,

Our lecturer told us that Unnamed Namespace is an alternative to
Static Internal Variables, but he also said that Namespace has an
"Open" nature. Then, what if we create an integer variable in an
unnamed namespace in one file and then create another integer variable
with the same name in the unnamed namespace in another file? Will this
cause a naming conflict?

-- file1.cpp --
namespace
{
int chenchen;
}

-- file2.cpp --
namespace
{
int chenchen;
}

If there is a naming conflict, then Unnamed Namespace is not able to
function exactly the same as Static Internal Variable does; If there
is no conflict, then Unnamed Namespace doesn't have an "Open"
nature......So, why the standard includes such a feature?.......

( Sorry, I am new to C++, actually I don't even know what exactly I
should ask.....)

On Oct 15, 8:15 am, CrazyJohn <gatesgates2...@gmail.com> wrote:
> Hi guys,
>
> This is my first time posting question here, if I break any rules,
> please kindly point out. And I'm really glad to be a part of this
> community.
>
> Here is my question,
>
> Our lecturer told us that Unnamed Namespace is an alternative to
> Static Internal Variables, but he also said that Namespace has an
> "Open" nature. Then, what if we create an integer variable in an
> unnamed namespace in one file and then create another integer variable
> with the same name in the unnamed namespace in another file? Will this
> cause a naming conflict?
>
> -- file1.cpp --
> namespace
> {
> int chenchen;
>
> }
>
> -- file2.cpp --
> namespace
> {
> int chenchen;
>
> }
>
> If there is a naming conflict, then Unnamed Namespace is not able to
> function exactly the same as Static Internal Variable does; If there
> is no conflict, then Unnamed Namespace doesn't have an "Open"
> nature......So, why the standard includes such a feature?.......
>
> ( Sorry, I am new to C++, actually I don't even know what exactly I
> should ask.....)

The footnote to 7.3.1.1(1) of the C++ standard says: "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"

What this means is that entities in an unnamed namespace are not
visible from other TUs.

By "open nature", it is meant that new entries can be added to the
namespace any time later. 7.3(1) of the standard says : "Unlike other
declarative regions, the definition of a namespace can be split over
several parts of one or more translation units.". For an unnamed
namespace, however, since the names are not visible across TUs, the
definition of "open" gets restricted to the same translation unit.

-N

On Mon, 15 Oct 2007 03:15:53 -0000, CrazyJohn
<gatesgates2005@gmail.com> wrote in comp.lang.c++:

> Hi guys,
>
> This is my first time posting question here, if I break any rules,
> please kindly point out. And I'm really glad to be a part of this
> community.
>
> Here is my question,
>
> Our lecturer told us that Unnamed Namespace is an alternative to
> Static Internal Variables, but he also said that Namespace has an
> "Open" nature. Then, what if we create an integer variable in an
> unnamed namespace in one file and then create another integer variable
> with the same name in the unnamed namespace in another file? Will this
> cause a naming conflict?

The C++ standard requires that the unnamed namespace for each
translation unit in a program be unique.

> -- file1.cpp --
> namespace
> {
> int chenchen;
> }
>
> -- file2.cpp --
> namespace
> {
> int chenchen;
> }

In the example you show above, file1.cpp and file2.cpp are separate
translation units, unless one of them uses the #include directive to
include the contents of the other.

> If there is a naming conflict, then Unnamed Namespace is not able to
> function exactly the same as Static Internal Variable does; If there
> is no conflict, then Unnamed Namespace doesn't have an "Open"
> nature......So, why the standard includes such a feature?.......

This is actually a reasonable question to ask here, although I would
correct your terminology.

If you have this in a C program or C++ program, in a file and outside
of any functions:

static int x;

....this is called "file scope" in C and "namespace scope" in C++. The
object 'x' has file or namespace scope and internal linkage.

In C++, some constructions, such as templates, require that some
symbols they use must have external linkage, not internal linkage.

static int x;

....has internal, not external, linkage, but:

namespace
{
int x;
}

....has external linkage.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

Thank you!!Thank you!! I just tested the code using gnu compiler, and
it works very well!!

On Oct 15, 5:44 am, Neelesh Bodas <neelesh.bo...@gmail.com> wrote:
> On Oct 15, 8:15 am, CrazyJohn <gatesgates2...@gmail.com> wrote:
> > This is my first time posting question here, if I break any rules,
> > please kindly point out. And I'm really glad to be a part of this
> > community.

> > Here is my question,

> > Our lecturer told us that Unnamed Namespace is an alternative to
> > Static Internal Variables, but he also said that Namespace has an
> > "Open" nature. Then, what if we create an integer variable in an
> > unnamed namespace in one file and then create another integer variable
> > with the same name in the unnamed namespace in another file? Will this
> > cause a naming conflict?

> > -- file1.cpp --
> > namespace
> > {
> > int chenchen;
> > }

> > -- file2.cpp --
> > namespace
> > {
> > int chenchen;
> > }

> > If there is a naming conflict, then Unnamed Namespace is not able to
> > function exactly the same as Static Internal Variable does; If there
> > is no conflict, then Unnamed Namespace doesn't have an "Open"
> > nature......So, why the standard includes such a feature?.......

> > ( Sorry, I am new to C++, actually I don't even know what exactly I
> > should ask.....)

> The footnote to 7.3.1.1(1) of the C++ standard says: "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"

> What this means is that entities in an unnamed namespace are not
> visible from other TUs.

That's not quite true. What it means is that they cannot be
names in other TU's. If your compiler supports export, they can
be seen and used by template instantiations, when the template
has been defined in another TU. (That is, in fact, part of the
reason why the anonymous namespace was invented.)

Note for example:

template< int& ri > class T{} ;

static int i1 ;
T< i1 > t1 ; // Illegal...

namespace { int i2 ; } ;
T< i2 > t2 ; // Legal...

If T were actuallly exported, and contained code, that code
could refer to i2 by means of its argument ri. Even though the
code was in another translation unit. This is not possible with
static.

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Dude, thanks for your reply, I really appreciate it. I was just about
to tell myself I understand this, but what you said confuses me
again.

> That's not quite true. What it means is that they cannot be
> names in other TU's. If your compiler supports export, they can
> be seen and used by template instantiations, when the template
> has been defined in another TU. (That is, in fact, part of the
> reason why the anonymous namespace was invented.)
>
> Note for example:
>
> template< int& ri > class T{} ;
>
> static int i1 ;
> T< i1 > t1 ; // Illegal...
>
> namespace { int i2 ; } ;
> T< i2 > t2 ; // Legal...

I understand why using "i1" is illegal, but would you explain why
using unnamed namespace is legal again? And what is this "export"
thing btw......

Thanks in advance.

>
> If T were actuallly exported, and contained code, that code
> could refer to i2 by means of its argument ri. Even though the
> code was in another translation unit. This is not possible with
> static.
>
> --
> James Kanze (GABI Software) email:james.ka...@gmail.com
> Conseils en informatique orientée objet/
> Beratung in objektorientierter Datenverarbeitung
> 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

On Oct 15, 5:09 pm, CrazyJohn <gatesgates2...@gmail.com> wrote:
> Dude, thanks for your reply, I really appreciate it. I was just about
> to tell myself I understand this, but what you said confuses me
> again.

> > That's not quite true. What it means is that they cannot be
> > names in other TU's. If your compiler supports export, they can
> > be seen and used by template instantiations, when the template
> > has been defined in another TU. (That is, in fact, part of the
> > reason why the anonymous namespace was invented.)

> > Note for example:

> > template< int& ri > class T{} ;

> > static int i1 ;
> > T< i1 > t1 ; // Illegal...

> > namespace { int i2 ; } ;
> > T< i2 > t2 ; // Legal...

> I understand why using "i1" is illegal, but would you explain why
> using unnamed namespace is legal again?

The difference is simple: using static forces internal linkage,
and the standard says that you cannot instantiate a template
over something that has internal linkage. Roughly speaking, the
entity being named cannot be accessed outside of the translation
unit (and the "translation unit" in which template instantiation
takes place is distinct from the one which triggers the
instantiation, at least when the template is exported). An
anonymous namespace has no impact on linkage. The entity has
external linkage, exactly as if it had been declared in a named
namespace, or globally. What protects it from accidental
conflicts in other translation units is that you can't name the
namespace it's in. You can't name it, but the compiler still
knows, and can use it in the instantiation of a template.

> And what is this "export"
> thing btw......

A standard (but not widely implemented) feature which allows you
to define the templates in a separate translation unit, so that
you don't accidentally pick up unwanted local definitions.

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34