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