Storage class specifiers - cppreference.com (original) (raw)

The storage class specifiers are a part of the decl-specifier-seq of a name's declaration syntax. Together with the scope of the name, they control two independent properties of the name: its storage duration and its linkage.

Contents

[edit] Storage duration

The storage duration is the property of an object that defines the minimum potential lifetime of the storage containing the object. The storage duration is determined by the construct used to create the object and is one of the following:

thread storage duration (also known as thread-local storage duration) (since C++11)

Static, thread,(since C++11) and automatic storage durations are associated with objects introduced by declarations and with temporary objects. The dynamic storage duration is associated with objects created by a new expression or with implicitly created objects.

The storage duration categories apply to references as well.

The storage duration of subobjects and reference members is that of their complete object.

[edit] Specifiers

The following keywords are storage class specifiers :

auto (until C++11)
register (until C++17)
thread_local (since C++11)

In a decl-specifier-seq, there can be at most one storage class specifier, except that thread_local may appear with static or extern(since C++11).

mutable has no effect on storage duration. For its usage, see const/volatile.

Other storage class specifiers can appear in the decl-specifier-seq s of the following declarations:

Specifier Can appear in the decl-specifier-seq s of
Variable declarations Function declarations Structured binding declarations(since C++17)
Non-member Member Non-member Member
Non-parameter Function parameter Non-static Static Non-static Static
auto Block scope only Yes No No No No No N/A
register Block scope only Yes No No No No No N/A
static Yes No Declares static Namespace scope only Declares static Yes
thread_local Yes No No Yes No No No Yes
extern Yes No No No Yes No No No

Anonymous unions can also be declared with static.

register is a hint that the variable so declared will be heavily used, so that its value can be stored in a CPU register. The hint can be ignored, and in most implementations it will be ignored if the address of the variable is taken. This use is deprecated. (until C++17)

[edit] Static storage duration

A variable satisfying all following conditions has static storage duration :

It does not have thread storage duration. (since C++11)

The storage for these entities lasts for the duration of the program.

Thread storage duration All variables declared with thread_local have thread storage duration.The storage for these entities lasts for the duration of the thread in which they are created. There is a distinct object or reference per thread, and use of the declared name refers to the entity associated with the current thread. (since C++11)

[edit] Automatic storage duration

The following variables have automatic storage duration :

[edit] Dynamic storage duration

Objects created by the following methods during program execution have dynamic storage duration :

[edit] Linkage

A name can have external linkage , module linkage(since C++20), internal linkage, or no linkage:

An entity whose name has module linkage can be redeclared in another translation unit, as long as the redeclaration is attached to the same module. (since C++20)

The following linkages are recognized:

[edit] No linkage

Any of the following names declared at block scope have no linkage:

Names not specified with external, module,(since C++20) or internal linkage also have no linkage, regardless of which scope they are declared in.

[edit] Internal linkage

Any of the following names declared at namespace scope have internal linkage:

In addition, all names declared in unnamed namespaces or a namespace within an unnamed namespace, even ones explicitly declared extern, have internal linkage. (since C++11)

[edit] External linkage

Variables and functions with external linkage also have language linkage, which makes it possible to link translation units written in different programming languages.

Any of the following names declared at namespace scope have external linkage, unless they are declared in an unnamed namespace or their declarations are attached to a named module and are not exported(since C++20):

Any of the following names first declared at block scope have external linkage:

Module linkage Names declared at namespace scope have module linkage if their declarations are attached to a named module and are not exported, and do not have internal linkage. (since C++20)

[edit] Static block variables

Block variables with static or thread(since C++11) storage duration are initialized the first time control passes through their declaration (unless their initialization is zero- or constant-initialization, which can be performed before the block is first entered). On all further calls, the declaration is skipped.

If multiple threads attempt to initialize the same static local variable concurrently, the initialization occurs exactly once (similar behavior can be obtained for arbitrary functions with std::call_once). Usual implementations of this feature use variants of the double-checked locking pattern, which reduces runtime overhead for already-initialized local statics to a single non-atomic boolean comparison. (since C++11)

The destructor for a block variable with static storage duration is called at program exit, but only if the initialization took place successfully.

Variables with static storage duration in all definitions of the same inline function (which may be implicitly inline) all refer to the same object defined in one translation unit, as long as the function has external linkage.

[edit] Translation-unit-local entities

The concept of translation-unit-local entities is standardized in C++20, see this page for more details.

An entity is translation-unit-local (or TU-local for short) if

Bad things (usually violation of ODR) can happen if the type of a non-TU-local entity depends on a TU-local entity, or if a declaration of, or a deduction guide for,(since C++17) a non-TU-local entity names a TU-local entity outside its

Such uses are disallowed in a module interface unit (outside its private-module-fragment, if any) or a module partition, and are deprecated in any other context.A declaration that appears in one translation unit cannot name a TU-local entity declared in another translation unit that is not a header unit. A declaration instantiated for a template appears at the point of instantiation of the specialization. (since C++20)

[edit] Notes

Names at the top-level namespace scope (file scope in C) that are const and not extern have external linkage in C, but internal linkage in C++.

Since C++11, auto is no longer a storage class specifier; it is used to indicate type deduction.

In C, the address of a register variable cannot be taken, but in C++, a variable declared register is semantically indistinguishable from a variable declared without any storage class specifiers. (until C++17)
In C++, unlike C, variables cannot be declared register. (since C++17)

Names of thread_local variables with internal or external linkage referred from different scopes may refer to the same or to different instances depending on whether the code is executing in the same or in different threads.

The extern keyword can also be used to specify language linkage and explicit template instantiation declarations, but it's not a storage class specifier in those cases (except when a declaration is directly contained in a language linkage specification, in which case the declaration is treated as if it contains the extern specifier).

Storage class specifiers, except for thread_local, are not allowed on explicit specializations and explicit instantiations:

template struct S { thread_local static int tlm; };   template<> thread_local int S::tlm = 0; // "static" does not appear here

A const (may be implied by constexpr) variable template used to have internal linkage by default, which was inconsistent with other templated entities. Defect report CWG2387 corrected this. (since C++14)
inline acts as a workaround for CWG2387 by giving external linkage by default. This is why the inline was added to many variable templates and then removed after having CWG2387 accepted. Standard library implementations also need to use inline as long as a supported compiler has not get CWG2387 implemented. See GCC Bugzilla #109126 and MSVC STL PR #4546. (since C++17)
Feature-test macro Value Std Feature
__cpp_threadsafe_static_init 200806L (C++11) Dynamic initialization and destruction with concurrency

[edit] Keywords

auto,register,static,extern,thread_local,mutable

[edit] Example

#include #include #include #include   thread_local unsigned int rage = 1; std::mutex cout_mutex;   void increase_rage(const std::string& thread_name) { ++rage; // modifying outside a lock is okay; this is a thread-local variable std::lock_guard<std::mutex> lock(cout_mutex); std::cout << "Rage counter for " << thread_name << ": " << rage << '\n'; }   int main() { std::thread a(increase_rage, "a"), b(increase_rage, "b");   { std::lock_guard<std::mutex> lock(cout_mutex); std::cout << "Rage counter for main: " << rage << '\n'; }   a.join(); b.join(); }

Possible output:

Rage counter for a: 2 Rage counter for main: 1 Rage counter for b: 2

[edit] Defect reports

The following behavior-changing defect reports were applied retroactively to previously published C++ standards.

DR Applied to Behavior as published Correct behavior
CWG 216 C++98 unnamed class and enumeration in class scope havedifferent linkage from those in namespace scope they all have externallinkage in these scopes
CWG 389 C++98 a name with no linkage should not beused to declare an entity with linkage a type without linkage shall not be usedas the type of a variable or functionwith linkage, unless the variableor function has C language linkage
CWG 426 C++98 an entity could be declared with both internaland external linkage in the same translation unit the program is ill-formed in this case
CWG 527 C++98 the type restriction introduced by the resolution of CWG389 was also applied to variables and functions thatcannot be named outside their own translation units the restriction is lifted for thesevariables and functions (i.e. with nolinkage or internal linkage, or declaredwithin unnamed namespaces)
CWG 809 C++98 register served very little function deprecated
CWG 1648 C++11 static was implied even ifthread_local is combined with extern implied only if no other storageclass specifier is present
CWG 1686 C++98C++11 the name of a non-static variable declared in namespacescope had internal linkage only if it is explicitlydeclared const (C++98) or constexpr (C++11) only required the typeto be const-qualified
CWG 2019 C++98 the storage duration of referencemembers were unspecified same as their complete object
CWG 2387 C++14 unclear whether const-qualified variabletemplate have internal linkage by default const qualifier does not affectthe linkage of variabletemplates or their instances
CWG 2533 C++98 the storage duration of implicitly-created objects were unclear made clear
CWG 2850 C++98 it was unclear when the storage forfunction parameters are deallocated made clear
CWG 2872 C++98 the meaning of “can be referred to” was unclear improved wording
P2788R0 C++20 declaring a const-qualified variable in a namespacegave it internal linkage even in a module unit internal linkage is not given

[edit] References

[edit] See also