Infact, a few weeks ago, I was told LyX were using unnamed
namespaces instead of statics, so I've got to the usual
TIC++vone.pdf, where it says:
"If you put local names in an unnamed namespace, you don’t
need to give them internal linkage by making them static.
C++ deprecates the use of file statics in favor of the unnamed
namespace."
This didn't actually satisfy me, so a further google/search provided
the following:
[...] the new C++ Standard reads in section 7.3.1.1 Unnamed Spaces,
paragraph 2: "The use of the static keyword is deprecated when declaring
objects in a namespace scope, the unnamed namespace provides a superior
alternative."
And also:
[...] Article 7.3.1.1/1 of the C++ standard says: "[a]lthough 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."
And the discussion at http://www.thescripts.com/forum/thread62059.html
also highlights the external linkage of (identifier declared within) unnamed
namespaces, claiming it could be useful for merging template instanciations
by the linker.
Other discussions on the Internet also highlight that:
-) compiled objects with unnamed namespaces do have space-overhead
w.r.t. statics.
-) there is no reason for which the compiler cannot optimize the use of
those
identifiers, but...
-) the compiler will have to keep a copy of the functions in the object
files, as
they actually have external linkage.
From what I've read, the standard deprecates statics, so there seems to be
no choice, although some people have doubts on the meaning of the
"deprecate"
verb within the standard itself !?! However, as long as statics are
supported
by compilers, they would seem to be actually better as long as no templates
are involved.
Also, another interesting contribution from:
http://www.informit.com/guides/content.aspx?g=cplusplus&seqNum=210&rl=1
"Readers have asked me several times why the C++ standards committee
frowned at namespace scope static declarations. The first problem was
didactic. The keyword static was already overloaded in C; C++ added to
this confusion the concept of static data members and static member
functions. The committee felt that static was becoming a Swiss army
knife: a single keyword that does too many different things.
Another problem was more subtle. Not all implementations truly support
internal linkage. Therefore, the "internal-linkage" promise couldn't be
fulfilled in certain environments; hackers familiar with the
inner-workings of such implementations could access allegedly-invisible
functions and data declared in other translation units. An unnamed
namespace, of course, doesn't cure broken linkers; however, it is more
honest about its capabilities.
Article 7.3.1.1/1 of the C++ standard says: "[a]lthough 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." Put differently, an
unnamed namespace restricts the visibility of its members to the scope
of the translation unit by means of name mangling; it doesn't
necessarily guarantee internal linkage, though.
Do these arguments sound convincing? In the next installment I will show
that standard C++ itself forces programmers to violate this normative
recommendation in one case. Additionally, I will discuss the
initialization phases of non-POD objects with static storage type, as
well as static class members."
bye,
T.
--
Tommaso Cucinotta, Computer Engineering PhD, Researcher
ReTiS Lab, Scuola Superiore Sant'Anna, Pisa, Italy
Tel +39 050 882 024, Fax +39 050 882 003
http://feanor.sssup.it/~tommaso
