Reputation: 21518
Are there any drawbacks to having a symbol with external linkage (other then global namespace clutter/collision)? For instance, I would think that if I have a function witch I never call, if it has internal linkage, the compiler can just discard it, but if it is external the compiler has to leave that code in because someone might link to it later. Is this correct? Are there any other drawbacks?
I am asking because I know unnamed namespaces are recommended instead of the static keyword, but since symbols in an unnamed namespace still have external linkage, they would suffer from the above mentioned drawback (if I am right about it), and so are not totally better than static functions like the standard says.
Upvotes: 2
Views: 62
Reputation: 791989
The fact that functions in unnamed namespaces have external linkage is almost entirely a technicality. Because they have a "secret" translation unit dependent unique identifier it is impossible to name them from a different translation unit. This means that compiler can assume that they are never called by name from another translation unit. Most implementations that I know of turn functions in unnamed namespaces into local symbols and not global symbols, just like functions with true internal linkage.
A function in an unnamed namespace can be discarded without affecting a program if it is never called from the translation unit in which it is defined and it never has its address taken and passed out of the translation unit which might lead to it being called other than be a direct named function call.
Upvotes: 2