The storage class specifiers are a part of the decl-specifier-seq of a name's
. Together with the
of the name, they control two independent properties of the name: its storage duration and its linkage.
Storage duration
The storage duration is the property of an
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:
static storage duration
thread storage duration
(since C++11)automatic storage duration
dynamic storage duration
Static, thread,(since C++11) and automatic storage durations are associated with objects introduced by
and with
. The dynamic storage duration is associated with objects created by a
or with
.
The storage duration categories apply to references as well.
The storage duration of
and reference members is that of their complete object.
Specifiers
The following keywords are storage class specifiers :
auto
(until C++11)register
(until C++17)static
thread_local
(since C++11)extern
mutable
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
.
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 autoBlock scope onlyYesNoNo NoNoNoN/AregisterBlock scope onlyYesNoNo NoNoNoN/AstaticYesNoDeclares static Namespace scope onlyDeclares staticYes thread_localYesNoNoYes NoNoNoYes externYesNoNoNo YesNoNoNo
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)Static storage duration
A variable satisfying all following conditions has static storage duration :
It belongs to a
or are first declared with static or extern.
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)Automatic storage duration
The following variables have automatic storage duration :
Variables that belong to a
and are not explicitly declared static, thread_local,(since C++11) or extern. The storage for such variables lasts until the block in which they are created exits.
Variables that belong to a parameter scope (i.e. function parameters). The storage for a function parameter lasts until immediately after its
.
In addition,
also have an automatic storage duration.
Dynamic storage duration
Objects created by the following methods during program execution have dynamic storage duration :
. The storage for such objects is allocated by
and deallocated by
.
by other means. The storage for such objects overlaps with some existing storage.
. The storage for such objects is allocated and deallocated in an unspecified way.
Linkage
A name can have external linkage, module linkage(since C++20), internal linkage, or no linkage:
An entity whose name has external linkage can be
in another
, and the redeclaration can be
attached to a different module
(since C++20).
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)An entity whose name has internal linkage can be redeclared in another scope in the same translation unit.
An entity whose name has no linkage can only be redeclared in the same scope.
The following linkages are recognized:
No linkage
Any of the following names declared at block scope have no linkage:
variables that are not explicitly declared extern (regardless of the static modifier);
and their member functions;
other names declared at block scope such as typedefs, enumerations, and enumerators.
Names not specified with external, module,(since C++20) or internal linkage also have no linkage, regardless of which scope they are declared in.
Internal linkage
Any of the following names declared at namespace scope have internal linkage:
variables, variable templates(since C++14), functions, or function templates declared static;
non-template (since C++14)variables of non-volatile const-qualified type, unless
they are explicitly declared extern, or
they were previously declared and the prior declaration did not have internal linkage;
data members of
.
In addition, all names declared in
or a namespace within an unnamed namespace, even ones explicitly declared extern, have internal linkage.
(since C++11)External linkage
Variables and functions with external linkage also have
, 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):
variables and functions not listed above (that is, functions not declared static, non-const variables not declared static, and any variables declared extern);
enumerations;
names of classes, their member functions, static data members (const or not), nested classes and enumerations, and functions first introduced with
declarations inside class bodies;
names of all templates not listed above (that is, not function templates declared static).
Any of the following names first declared at block scope have external linkage:
names of variables declared extern;
names of functions.
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)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
or
, which can be performed before the block is first entered). On all further calls, the declaration is skipped.
If the initialization
, the variable is not considered to be initialized, and initialization will be attempted again the next time control passes through the declaration.
If the initialization recursively enters the block in which the variable is being initialized, the behavior is undefined.
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
).
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
, but only if the initialization took place successfully.
Variables with static storage duration in all definitions of the same
(which may be implicitly inline) all refer to the same object defined in one translation unit, as long as the function has external linkage.
Translation-unit-local entities
The concept of translation-unit-local entities is standardized in C++20, see
for more details.
An entity is translation-unit-local (or TU-local for short) if
it has a name with internal linkage, or
it does not have a name with linkage and is introduced within the definition of a TU-local entity, or
it is a template or template specialization whose template argument or template declaration uses a TU-local entity.
Bad things (usually violation of
) can happen if the type of a non-TU-local entity depends on a TU-local entity, or if a declaration of, or a
for,(since C++17) a non-TU-local entity names a TU-local entity outside its
function-body for a non-inline function or function template
initializer for a variable or variable template
friend declarations in a class definition
use of value of a variable, if the variable is
usable in constant expressions
Such uses are disallowed in a
(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
appears at the point of instantiation of the specialization.
(since C++20)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
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
and
:
template<classT>structS{thread_localstaticinttlm;};template<>thread_localintS<float>::tlm=0;// "static" does not appear hereA const (may be implied by constexpr) variable template used to have internal linkage by default, which was inconsistent with other templated entities. Defect report
corrected this.
(since C++14)
acts as a workaround for
by giving external linkage by default. This is why the inline was
to many variable templates and then
after having CWG2387 accepted. Standard library implementations also need to use inline as long as a supported compiler has not get CWG2387 implemented. See
and
.(since C++17)Feature-test macroValueStdFeature
(C++11)
Dynamic initialization and destruction with concurrency
Keywords
,
,
,
,
,
Example
Run this code
#include<iostream>#include<mutex>#include<string>#include<thread>thread_localunsignedintrage=1;std::mutexcout_mutex;voidincrease_rage(conststd::string&thread_name){++rage;// modifying outside a lock is okay; this is a thread-local variablestd::lock_guard<std::mutex>lock(cout_mutex);std::cout<<"Rage counter for "<<thread_name<<": "<<rage<<'\n';}intmain(){std::threada(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 Defect reports
The following behavior-changing defect reports were applied retroactively to previously published C++ standards.
DR Applied to Behavior as published Correct behavior
C++98 unnamed class and enumeration in class scope have
different linkage from those in namespace scope they all have external
linkage in these scopes
C++98 a name with no linkage should not be
used to declare an entity with linkage a type without linkage shall not be used
as the type of a variable or function
with linkage, unless the variable
or function has C language linkage
C++98 an entity could be declared with both internal
and external linkage in the same translation unit the program is ill-formed in this case
C++98 the type restriction introduced by the resolution of CWG
389 was also applied to variables and functions that
cannot be named outside their own translation units the restriction is lifted for these
variables and functions (i.e. with no
linkage or internal linkage, or declared
within unnamed namespaces)
C++98 register served very little function deprecated
C++11 static was implied even if
thread_local is combined with externimplied only if no other storage
class specifier is present
C++98
C++11 the name of a non-static variable declared in namespace
scope had internal linkage only if it is explicitly
declared const (C++98) or constexpr (C++11) only required the type
to be const-qualified
C++98 the storage duration of reference
members were unspecified same as their complete object
C++14 unclear whether const-qualified variable
template have internal linkage by default const qualifier does not affect
the linkage of variable
templates or their instances
C++98 the storage duration of implicitly-
created objects were unclear made clear
C++98 it was unclear when the storage for
function parameters are deallocated made clear
C++98 the meaning of “can be referred to” was unclear improved wording
C++20 declaring a const-qualified variable in a namespace
gave it internal linkage even in a module unit internal linkage is not given References
C++23 standard (ISO/IEC 14882:2024):
6.7.5 Storage duration [basic.stc]
C++20 standard (ISO/IEC 14882:2020):
6.7.5 Storage duration [basic.stc]
C++17 standard (ISO/IEC 14882:2017):
6.7 Storage duration [basic.stc]
C++14 standard (ISO/IEC 14882:2014):
3.7 Storage duration [basic.stc]
C++11 standard (ISO/IEC 14882:2011):
3.7 Storage duration [basic.stc]
C++03 standard (ISO/IEC 14882:2003):
3.7 Storage duration [basic.stc]
C++98 standard (ISO/IEC 14882:1998):
3.7 Storage duration [basic.stc]
See also