On Tue, Aug 28, 2007 at 12:45:57PM +0200, Tommaso Cucinotta wrote: > 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."
Right. Nevertheless the optimizer can't throw them out because they have external linkage. > 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. Exactly. > 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. I doubt this ever will/can be declared 'unsupported' as this would break backwards compatibility and compatibility to C. Given the general reluctance of the Committee to do so even where it would make sense Apart from that, a static -> anon namespace change is a 15 line perl script or so. So even if C++ 2022 decides to kick out 'static' no real harm is done. > 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. Funny reasoning without technical merits. C++ is already an awful language from a didactic point of view... > 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. I don't see what should stop me to access the "uniquely mangled" name that's present in the object file using a linker of my own. This treats a "some linkers can't do X" against a "no linker can't, but in the futuer someone might". > Do these arguments sound convincing? Not at all ;-) > 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." Andre'
