Why don't symbols (functions and variables) that are defined in an anonymous namespace have internal linkage as with static keyword? If a function is not visible/accessible outside, what is the reason to have external linkage?
In C++03, names with internal linkage were forbidden from being used as template arguments[*]. So, names of most things in unnamed namespaces had external linkage to allow their use with templates. You could explicitly give a name internal linkage in an unnamed namespace by declaring it static, same as in a named or global namespace.
Both things changed in C++11 -- names in unnamed namespaces have internal linkage by default (3.5/4), and names with internal linkage can be used as template arguments.
[*] for types, it must have external linkage. For objects and functions, it must have external linkage if its address is used as a template argument, although it's OK for example to use as a template argument the value of a const integer with internal linkage.
Related
According to the Linkage Section of this link,
If a variable, function, or another entity with the same name is declared in several scopes, but does not have sufficient linkage, then several instances of the entity are generated.
Any simple example for the does not have sufficient linkage case?
I know that template functions don't suffer of multiple definitions when linking, like member functions defined inside a class, which are inline by default. Also, constexpr objects have internal linkage, but template variables have external linkage (I mean at namespace scope and for C++14 in both cases).
What about?
template<class T>
constexpr T i_am_odr_safe{};
Does i_am_odr_safe have external or internal linkage in C++14? and is it safe regarding multiple-definitions like function templates?
In other words, is i_am_odr_safe odr-safe?
This is core issue 1713, the direction of which IIRC is that this variable template will have external linkage.
And no, this hasn't been resolved yet, which is why LWG decided to plaster inline all over the variable templates in the standard library when it adopted A+B2 of P0604R0.
3.5 [basic.link] paragraph 8 from N4567 says that
... A type is said to have linkage if and only if:
it is a class or enumeration type that is named (or has a name for linkage purposes (7.1.3)) and the name has linkage; or
...
which exclusively elaborates on linkage of types—one of the entities that a name can denote. However, it seems that there is no information in this paragraph whether the linkage that a type shall have is internal or external. Is it because there is no need to define it at all, or because it is already defined by other paragraphs?
The type either has linkage, or it doesn't. This paragraph is self-contained: the first half defines the notion of a type having linkage, and the second half describes restrictions on the use of types having no linkage. The notion of linkage of a type is not used anywhere else, as far as I can tell.
If global variables and objects have static storage duration and external linkage?
do functions have static storage duration and external linkage as well?
what about structs and classes and enumerators(has external linkage i know)/unions?
I figured they have no storage duration and have no linkage,but then i thought that (global)functions have external linkage by default,but in a class they have class scope do they have internal linkage or?
Storage duration and linkage are unrelated concepts.
Functions do not have "storage duration", since functions do not reside in storage. Only objects have storage duration. Types do not reside in storage either, which is why types do not have storage duration.
It is not correct to say that classes have no linkage in general. Named classes declared in namespace scope have external linkage. Member functions of classes with external linkage also have external linkage. Classes declared locally and nameless classes have no linkage.
Functions don't officially have a storage duration, but in essence they're static (i.e., every function exists for the entire duration of the program). They have internal linkage if you define them static or inside of an anonymous namespace, otherwise external linkage.
Storage class applies to an object, not a type definition like a class, struct or union. It's fairly common to have two objects of the same class, one with static storage duration, and another with auto storage duration.
Likewise, you could create one object with internal linkage and another with external linkage:
T x;
static T y;
The same goes for linkage of classes:
class X { }; // external linkage
namespace {
class Y {}; // internal linkage
};
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Unnamed/anonymous namespaces vs. static functions
Is this completely redundant, or may there be a reason to do this?
namespace {
static void f() {
...
}
}
It looks redundant to me -- either being declared static or being in an anonymous namespace means it has internal linkage.
§3.5/3:
A name having namespace scope (3.3.6) has internal linkage if it is the name of:
— a variable, function or function template that is explicitly declared static;
§3.5/4:
[...] An unnamed namespace or a namespace declared directly or indirectly within an unnamed namespace has internal linkage. [...] A name having namespace scope that has not
been given internal linkage above has the same linkage as the enclosing namespace if it is the name of
— a variable; or
— a function; or
So, as it is right now, it has internal linkage because it's explicitly declared static. If it wasn't explicitly declared static, it would have internal linkage because it's declared inside an unnamed namespace. Same effect either way.
Note that here I'm replying specifically about a function -- there are a few obscure cases where there's a difference when you're dealing with the name of a type (e.g., class/struct/union), but I don't know of any such thing that applies in the case of a function.
As far as what internal linkage really means, that's one of those places the standard is actually quite direct and clear. It's probably best to quote the definitions of all three possibilities (§3.5/2):
When a name has external linkage, the entity it denotes can be referred to by names from scopes of other translation units or from other scopes of the same translation unit.
When a name has internal linkage, the entity it denotes can be referred to by names from other scopes in the same translation unit.
When a name has no linkage, the entity it denotes cannot be referred to by names from other scopes.
Note that the italics above match those in the standard, which is its way of saying that these sentences define what those phrases mean throughout the rest of the standard.