By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
448,957 Members | 1,234 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 448,957 IT Pros & Developers. It's quick & easy.

Question about Unnamed Namespace

P: n/a
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.....)

Oct 15 '07 #1
Share this Question
Share on Google+
3 Replies


P: n/a
On Mon, 15 Oct 2007 03:15:53 -0000, CrazyJohn
<ga************@gmail.comwrote 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
Oct 15 '07 #2

P: n/a

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

Oct 15 '07 #3

P: n/a
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

Oct 15 '07 #4

This discussion thread is closed

Replies have been disabled for this discussion.