Tommaso Cucinotta wrote:
[...] 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."
Superior how - is the question. If all we get is a bigger file . . . :-(
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.
Why do it "have to"? After all, nobody can link to the "unique" names
unless they extract them from the object file in the first place?
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.
Seems like statics is deprecated for a worse solution.
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.
That's a really stupid argument. Thw word "static" has too many meanings,
so lets disable some of them ??? The sane thing would be a
clean rename from "static" to several new keywords - one for each
use. And to keep the existing nice functionality.
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
So what? Some broken implementations exists - therefore lets
remove a feature that others gets right? A non-argument.
Of course, a hacker can call functions with internal linkage anyway,
he just have more work figuring out the exact address. . .
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?
Not at all - C++ development now seems strange. There may be
good arguments for the anonymous namespace, but none of these.
And none of these is an argument for not using static either.
If a standard is stupid at some point, don't follow it there.
Helge Hafting
