What does it exactly mean when the Standard states
$7.3.1.1/2 - "The use of the static
keyword is deprecated when declaring
variables in a namespace scope (see
annex D); the unnamed-namespace
provides a superior alternative."
I have referred this but it does not cover what I am looking for.
Is there an example where the superiority is clearly demonstrated.
NB: I know about how unnamed namespaces can make extern variables visible in the translation unit and yet hide them from other translation units. But the point of this post is about 'static namespace scope' names (e.g global static variables)
What does it exactly mean?
Technically deprecated means that a future standard may remove the feature.
In practice that isn't going to happen, because of the need to support old code.
So in practice it means, "strongly discouraged".
Example of superiority of unnamed namespace
An unnamed namespace is generally superior because what you have in that namespace can have external linkage.
In C++98 external linkage is necessary for things that can be template parameters, e.g., if you want to templatize on a char const*, it must be pointer to char that has external linkage.
#include <iostream>
// Compile with "-D LINKAGE=static" to see problem with "static"
#ifndef LINKAGE
# define LINKAGE extern
#endif
template< char const* s >
void foo()
{
std::cout << s << std::endl;
}
namespace {
LINKAGE char const message[] = "Hello, world!";
} // namespace anon
int main()
{
foo<message>();
}
That said, it's a bit inconsistent that static isn't also deprecated for functions.
This:
static int func_for_this_file_only() { ... }
is "as good as" this:
namespace { int func_for_this_file_only() { ... } }
but static can't be used for this:
namespace { class class_for_this_file_only { ... } }
Therefore, anonymous namespaces in C++ are more versatile and superior to static.
(I'm sure someone will argue with that conclusion, but as a C hacker I think the anonymous namespace solution is better.)
Interestingly, ISO/IEC 14882:2011 (C++11) removed this language (in fact, it removes the whole paragraph §7.3.1.1/2). It also removes the mention of static from Annex D.
Thus, using the storage class specifier static to give a name internal linkage still works (§3.5/3) and is no longer deprecated.
The goal is to define a symbol that exists only within your own translation unit. This can be "translation unit global" and may be a variable or a function.
This is commonly used in a class definition file as an alternative to private static class members as the static members have to be declared in the header, but a free-function does not have to be (unless it has to be a friend, which it virtual never actually needs to be, by the way).
The use of static would be:
static size_t BUFSIZE = 2048; // assume not const for this example
static int myCallback( void * ptr );
The use of an anonymous namespace is
namespace {
size_t BUFSIZE = 2048;
int myCallback( void * ptr );
}
The standard is saying that the second construct is preferred. We have found that sometimes it is advantageous still to use static in addition to the anonymous namespace to actually reduce the binary size.
Related
I am in a discussion in one of the code review sessions.
The debate is about if the functions in the anonymous namespace should be declared static or not. As an example, I am being told the square3 function which declared with "static" keyword has advantages.
namespace {
int square2(int num) {
return num * num;
}
static int square3(int num) {
return num * num;
}
}
I have told by my colleagues static is beneficial because:
A static function does not require an entry in the function table and
thus does not require time or memory when linking.
static means it is not exposed when linking. It improves linking time
and reduces memory usage when linking. Anonymous namespace does not
provide this.
I think by "function table" my colleagues mean "symbol table". I couldn't find any documentation about that except the least upvoted answer of another S.O question which says
It is usually better to prefer static linkage, as that doesn't
pollute the symbol table
I am trying to see if that info is true or not by using compiler explorer. But I couldn't find a way to get to the symbol table. All I see the function names and everything is mangled in the same way.
So I have two questions:
1 - Is using a function with static keyword in the anonymous namespace helps with memory/linking time?
2 - Is there a way to check the symbol table in compiler explorer?
It improves linking time and reduces memory usage when linking.
Even if this were to be true for a given implementation, from a pure language perspective, a static function in an unnamed namespace is redundant and arguably an anti-pattern that is likely to confuse other developers; whom may already struggle with the way C++ has overloaded what static means in terms of linkage and the entirely orthogonal storage duration.
// .cpp
namespace top {
int a{}; // external linkage, static storage duration
const int b{}; // internal linkage, static storage duration
static int c{}; // internal linkage, static storage duration
namespace {
int d{}; // internal linkage, static storage duration
const int e{}; // internal linkage, static storage duration
static int f{}; // internal linkage, static storage duration
// ^^^ static is redundant (-> and may confuse devs)
int g() {} // internal linkage
static int h() {} // internal linkage
// ^^^ static is redundant (-> and may confuse devs)
} // namespace
int k() {} // external linkage
static int l() {} // internal linkage
} // namespace top
[...] except the least upvoted answer of another S.O question which says
It is usually better to prefer static linkage, as that doesn't pollute the symbol table
The answer you refer to was based on C++03, where entities in unnamed namespace did not have internal linkage per default. Meaning that in C++03, even if an entity in an unnamed namespace was not accessible to other translation units (due to the unique naming nature of the unnamed namespace), it could still have external linkage and thus end up in the symbol table.
From C++11 and onwards entities in an unnamed namespace have internal linkage. Meaning that, from the C++ language perspective w.r.t. linkage, the examples above (with internal linkage) are equivalent, and it could arguably even be the case that your colleague mixes these concepts (as is common due to their overloaded meaning) or that you colleagues' argument is based on the state of affairs prior to C++11.
1 - Is using a function with static keyword in the anonymous namespace helps with memory/linking time?
Static does not affect functions in anonymous namespace as far as the language is concerned. This is because being in an anonymous namespace already achieves the same thing as declaring the function static achieves. (Note that declaring a member function static has an entirely different meaning).
2 - Is there a way to check the symbol table in compiler explorer?
I don't know of compiler explorer, but you can use for example the nm program to list symbols: http://coliru.stacked-crooked.com/a/0281bc487044ec02
namespace {
void foo1(){} // internal linkage
static void foo2(){} // internal linkage
}
void foo3(){} // external linkage
static void foo4(){} // internal linkage
command:
nm main.o | c++filt
output:
0000000000000000 T foo3()
I read in the below link that unnamed(anonymous) class should not have static data memebers in it. Could anyone please let me know the reason for it?
https://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.cbclx01/cplr038.htm
says the below..
You can only have one definition of a static member in a program.
Unnamed classes, classes contained within unnamed classes, and local
classes cannot have static data members.
All static member data, if they are ODR-used, must be defined outside the class/struct.
struct Foo
{
static int d;
};
int Foo::d = 0;
If the class/struct is unnamed, there is no way to define the member outside the class.
int ::d = 0;
cannot be used to define the static member of an unnamed class.
Update for C++17
If you are able to use C++17 or newer, you may use
static inline int d = 10;
That will allow a static member variable to be defined in an anonymous class/struct.
Sample code to demonstrate that a static member variable need not be defined outside the class definition:
#include <iostream>
struct foo
{
static inline int d = 10;
};
int main()
{
auto ptr = &foo::d;
std::cout << *ptr << std::endl;
}
Command to build:
g++ -std=c++17 -Wall socc.cc -o socc
Output of running the program:
10
Thanks are due to #Jean-MichaëlCelerier for the suggestion for the update.
Are you sure that the standard actually forbids this?
As mentioned the problem arises as you need to have an actual definition of the static member. The language provides for no method to define it. There is no other problems in referring to it as we can do it from within the struct or via an instance of it.
However GCC for example will accept the following:
static struct {
static int j;
} a;
int main() {
return a.j; // Here we actually refers to the static variable
}
but it can't be linked as a.j refers to an undefined symbol (._0::j), but there's a way to get around this. By defining it in assembler or by using compiler extensions you could. For example adding the line
int j asm("_ZN3._01jE") = 42;
Will make it work. _ZN3._01jE is the real mangled name of the static variable in this case, neither the mangled or unmangled name can be used directly as a identifier in standard C++ (but it can via GCC extension or assembler).
As you must probably realize this would only work with specific compilers. Other compilers would mangle the name in other ways (or even do other things that may make the trick not work at all).
You should really question why you would like to use this trick. If you can do the work using standard methods you should most probably chose that. For example you could reduce the visibility by using anonymous namespace instead for example:
namespace {
static struct Fubar {
static int j;
} a;
Fubar::a = 0;
}
Now Fubar is not really anonymous, but it will at least be confined to the translation unit.
When C++ was standardized, unnamed classes could not have static data members, as there was no way to define/instantiate them. However, this problem has been solved with C++11, as it added the decltype operator:
struct {
static int j;
} a;
// Declare the static member of the unnamed struct:
int decltype(a)::j = 42;
int main() {
return a.j == 42 ? 0 : 1; // Use the static member
}
So, in principle, there could be unnamed classes or structs with static data members. But the C++ standard makers deliberately did not allow this syntax, as the compiler doesn't know, which name it should give to that decltype(a)::j thing for linking. So most (all?) compilers - including current versions of GCC in normal mode - refuse to compile this.
In -fpermissive mode, GCC-9 und GCC-10 accept this code and compile it fine. However, if the declaration of a is moved to a header file, that is included from different source files, they still fail at the linking stage.
So unnamed classes can only be used inside a single translation unit. To avoid polluting the global namespace, just put anything, that needs to stay local, inside an anonymous namespace. So:
namespace {
struct whatever {
static int j;
} a;
int whatever::j = 42;
}
int main() {
return a.j == 42 ? 0 : 1;
}
compiles fine, doesn't pollute global namespace, and even doesn't lead to problems, if the name whatever clashes with a name from another header file.
When should I consider using static functions defined at file scope?
I typically use them when the task done in one such function doesn't really belong in member functions of any class and when such a task is only needed (repeatedly) in a certain source file.
Is my usage in line with why this feature exists? Or am I hijacking a concept that's intended for something else?
That's a perfectly valid use of file-scope static functions, but keep in mind that this usage of static has been deprecated for quite some time. It's generally preferred to use anonymous namespaces instead.
I do a similar thing when it make sense to have functions and/of data that are not part of the class interface but rather an implementation detail.
But I don't use the keyword static. Instead, I put the functions and/or data in an unnamed namespace.
First off, the term you are looking for is internal linkage. Your question really should be: "Which entities should have internal linkage?" The static keyword, or alternatively unnamed namespaces, are just implementation mechanisms to achieve internal linkage.
Now the answer should be obvious: All entities that are only required inside one single translation unit may be given internal linkage, and there are benefits in doing so: One is that the compiler can make use of the information that an entity cannot ever be seen by any other translation unit, so it can for example avoid emitting code that might be required otherwise, or inline more aggressively. Another reason is that you minimize the risk of accidental ODR violations if you happen to pick a name that is also used locally in some other TU.
A typical example is like this:
my_lib.hpp:
#ifndef H_MY_LIB
#define H_MY_LIB
namespace foo
{
void do_an_awesome_thing(void * p, std::size_t n);
}
#endif
my_lib.cpp:
#include "my_lib.hpp"
namespace foo
{
namespace
{
void helper(void * p) { /* ... */ }
bool aux(std::size_t n, float f) { /* ... */ }
constexpr char usage[] = R"(This is how you do it...)";
constexpr float some_factor = 1.25;
}
void do_an_awesome_thing(void *p, std::size_t n)
{
if (!aux(n, some_factor)) { LOG_AND_DIE(usage); }
helper(p);
}
}
Now your can be sure that your translation unit does not impose any undue link-time burden on the remainder of your program.
The placement of the unnamed namespace is a matter of taste; you can either have it inside your usual namespace, or at the top level. The effect is the same.
namespace N
{
static int x = 5;
}
What could be the importance/use-cases of declaring having a static variable at namespace scope?
static variable at namespace scope (global or otherwise) has internal linkage. That means, it cannot be accessed from other translation units. It is internal to the translation unit in which it is declared.
Annex D (Compatibility features) [C++03]
D2: The use of the static keyword is deprecated when declaring objects in namespace scope.
Use unnamed namespaces instead as mentioned in this post.
static keyword imparts internal linkage to variables/objects in C as well as in C++ in namespace scope as others have mentioned in their posts.
P.S:
Thie feature has been undeprecated as per the latest draft (n3290). In n3225 §7.3.1.1/2 is present but striked out.
I agree with Nawaz's answer: static keyword is not totally useless in namespaces : it defines that the variable is of internal linkage to the translation unit.
For example :
header.h
namespace test{
static int i = 5;//definition is here.And there will be no multiple definition!
void set_i();
void print_i();
}
header.cpp
#include "header.h"
#include "iostream"
void test::set_i()
{
i = 10;
return;
}
void test:print_i()
{
using namespace std;
cout << "print_i is " << i << endl;
return;
}
main.cpp
#include "header.h"
#include "iostream"
using std::cout;
int main()
{
test::i = 20;
test::set_i();
cout << "i is " << test::i << endl;
test::print_i();
return 0;
}
Use g++ -std=c++11 header.cpp main.cpp to compile it, and you won't get multiple definition error.If you remove the static keyword and compile it, it is definitely multiple definition error. And please do run the program and observe the result and you may be surprised.
static keyword makes every cpp implementation file(translation unit) which includes the interface header that contains namespace declaration has a internal-linkage copy of the static variable. So even you define that variable in namespace, if it is static keyworded, there will be no multiple definition error.(The same for const with no extern preceding it which define variable of internal linkage, and that's how macros can be discarded in C++) So the saying that variables defined in namespace are implicitly static is wrong and static are not totally useless in namespace. Because every translation unit have one copy of that variable, space is consumed.
However, unnamed namespace can make class declaration inside it inaccessible from other translation unit while static keyword can not "attribute" a class, so that is one advantage of unnamed namespace. Besides, you can use unnamed namespace in nested namespace for variable access restriction. Unnamed namespace are designed for protecting locality rather than offering interface.
C++ Standard §7.3.1.1/2:
The use of the static keyword is
deprecated when declaring objects in a
namespace scope (see annex D); the
unnamed-namespace provides a superior
alternative.
Unless the unnamed namespace provides a superior alternative in the future Standard it will be undeprecated to achieve C compatibility.
Same as that of declaring a static in a global namespace but just local to a particular namespace.
What others already said, with an additional subtlety: static introduces internal linkage, and anonymous namespaces do not.
const static int foo = 42;
I saw this in some code here on StackOverflow and I couldn't figure out what it does. Then I saw some confused answers on other forums. My best guess is that it's used in C to hide the constant foo from other modules. Is this correct? If so, why would anyone use it in a C++ context where you can just make it private?
A lot of people gave the basic answer but nobody pointed out that in C++ const defaults to static at namespace level (and some gave wrong information). See the C++98 standard section 3.5.3.
First some background:
Translation unit: A source file after the pre-processor (recursively) included all its include files.
Static linkage: A symbol is only available within its translation unit.
External linkage: A symbol is available from other translation units.
At namespace level
This includes the global namespace aka global variables.
static const int sci = 0; // sci is explicitly static
const int ci = 1; // ci is implicitly static
extern const int eci = 2; // eci is explicitly extern
extern int ei = 3; // ei is explicitly extern
int i = 4; // i is implicitly extern
static int si = 5; // si is explicitly static
At function level
static means the value is maintained between function calls.
The semantics of function static variables is similar to global variables in that they reside in the program's data-segment (and not the stack or the heap), see this question for more details about static variables' lifetime.
At class level
static means the value is shared between all instances of the class and const means it doesn't change.
It has uses in both C and C++.
As you guessed, the static part limits its scope to that compilation unit. It also provides for static initialization. const just tells the compiler to not let anybody modify it. This variable is either put in the data or bss segment depending on the architecture, and might be in memory marked read-only.
All that is how C treats these variables (or how C++ treats namespace variables). In C++, a member marked static is shared by all instances of a given class. Whether it's private or not doesn't affect the fact that one variable is shared by multiple instances. Having const on there will warn you if any code would try to modify that.
If it was strictly private, then each instance of the class would get its own version (optimizer notwithstanding).
That line of code can actually appear in several different contexts and alghough it behaves approximately the same, there are small differences.
Namespace Scope
// foo.h
static const int i = 0;
'i' will be visible in every translation unit that includes the header. However, unless you actually use the address of the object (for example. '&i'), I'm pretty sure that the compiler will treat 'i' simply as a type safe 0. Where two more more translation units take the '&i' then the address will be different for each translation unit.
// foo.cc
static const int i = 0;
'i' has internal linkage, and so cannot be referred to from outside of this translation unit. However, again unless you use its address it will most likely be treated as a type-safe 0.
One thing worth pointing out, is that the following declaration:
const int i1 = 0;
is exactly the same as static const int i = 0. A variable in a namespace declared with const and not explicitly declared with extern is implicitly static. If you think about this, it was the intention of the C++ committee to allow const variables to be declared in header files without always needing the static keyword to avoid breaking the ODR.
Class Scope
class A {
public:
static const int i = 0;
};
In the above example, the standard explicitly specifies that 'i' does not need to be defined if its address is not required. In other words if you only use 'i' as a type-safe 0 then the compiler will not define it. One difference between the class and namespace versions is that the address of 'i' (if used in two ore more translation units) will be the same for the class member. Where the address is used, you must have a definition for it:
// a.h
class A {
public:
static const int i = 0;
};
// a.cc
#include "a.h"
const int A::i; // Definition so that we can take the address
It's a small space optimization.
When you say
const int foo = 42;
You're not defining a constant, but creating a read-only variable. The compiler is smart enough to use 42 whenever it sees foo, but it will also allocate space in the initialized data area for it. This is done because, as defined, foo has external linkage. Another compilation unit can say:
extern const int foo;
To get access to its value. That's not a good practice since that compilation unit has no idea what the value of foo is. It just knows it's a const int and has to reload the value from memory whenever it is used.
Now, by declaring that it is static:
static const int foo = 42;
The compiler can do its usual optimization, but it can also say "hey, nobody outside this compilation unit can see foo and I know it's always 42 so there is no need to allocate any space for it."
I should also note that in C++, the preferred way to prevent names from escaping the current compilation unit is to use an anonymous namespace:
namespace {
const int foo = 42; // same as static definition above
}
It's missing an 'int'. It should be:
const static int foo = 42;
In C and C++, it declares an integer constant with local file scope of value 42.
Why 42? If you don't already know (and it's hard to believe you don't), it's a refernce to the Answer to Life, the Universe, and Everything.
C++17 inline variables
If you Googled "C++ const static", then this is very likely what you really want to use are C++17 inline variables.
This awesome C++17 feature allow us to:
conveniently use just a single memory address for each constant
store it as a constexpr: How to declare constexpr extern?
do it in a single line from one header
main.cpp
#include <cassert>
#include "notmain.hpp"
int main() {
// Both files see the same memory address.
assert(¬main_i == notmain_func());
assert(notmain_i == 42);
}
notmain.hpp
#ifndef NOTMAIN_HPP
#define NOTMAIN_HPP
inline constexpr int notmain_i = 42;
const int* notmain_func();
#endif
notmain.cpp
#include "notmain.hpp"
const int* notmain_func() {
return ¬main_i;
}
Compile and run:
g++ -c -o notmain.o -std=c++17 -Wall -Wextra -pedantic notmain.cpp
g++ -c -o main.o -std=c++17 -Wall -Wextra -pedantic main.cpp
g++ -o main -std=c++17 -Wall -Wextra -pedantic main.o notmain.o
./main
GitHub upstream.
See also: How do inline variables work?
C++ standard on inline variables
The C++ standard guarantees that the addresses will be the same. C++17 N4659 standard draft
10.1.6 "The inline specifier":
6 An inline function or variable with external linkage shall have the same address in all translation units.
cppreference https://en.cppreference.com/w/cpp/language/inline explains that if static is not given, then it has external linkage.
GCC inline variable implementation
We can observe how it is implemented with:
nm main.o notmain.o
which contains:
main.o:
U _GLOBAL_OFFSET_TABLE_
U _Z12notmain_funcv
0000000000000028 r _ZZ4mainE19__PRETTY_FUNCTION__
U __assert_fail
0000000000000000 T main
0000000000000000 u notmain_i
notmain.o:
0000000000000000 T _Z12notmain_funcv
0000000000000000 u notmain_i
and man nm says about u:
"u" The symbol is a unique global symbol. This is a GNU extension to the standard set of ELF symbol bindings. For such a symbol the dynamic linker will make sure that in the entire process
there is just one symbol with this name and type in use.
so we see that there is a dedicated ELF extension for this.
Pre-C++ 17: extern const
Before C++ 17, and in C, we can achieve a very similar effect with an extern const, which will lead to a single memory location being used.
The downsides over inline are:
it is not possible to make the variable constexpr with this technique, only inline allows that: How to declare constexpr extern?
it is less elegant as you have to declare and define the variable separately in the header and cpp file
main.cpp
#include <cassert>
#include "notmain.hpp"
int main() {
// Both files see the same memory address.
assert(¬main_i == notmain_func());
assert(notmain_i == 42);
}
notmain.cpp
#include "notmain.hpp"
const int notmain_i = 42;
const int* notmain_func() {
return ¬main_i;
}
notmain.hpp
#ifndef NOTMAIN_HPP
#define NOTMAIN_HPP
extern const int notmain_i;
const int* notmain_func();
#endif
GitHub upstream.
Pre-C++17 header only alternatives
These are not as good as the extern solution, but they work and only take up a single memory location:
A constexpr function, because constexpr implies inline and inline allows (forces) the definition to appear on every translation unit:
constexpr int shared_inline_constexpr() { return 42; }
and I bet that any decent compiler will inline the call.
You can also use a const or constexpr static variable as in:
#include <iostream>
struct MyClass {
static constexpr int i = 42;
};
int main() {
std::cout << MyClass::i << std::endl;
// undefined reference to `MyClass::i'
//std::cout << &MyClass::i << std::endl;
}
but you can't do things like taking its address, or else it becomes odr-used, see also: Defining constexpr static data members
C
In C the situation is the same as C++ pre C++ 17, I've uploaded an example at: What does "static" mean in C?
The only difference is that in C++, const implies static for globals, but it does not in C: C++ semantics of `static const` vs `const`
Any way to fully inline it?
TODO: is there any way to fully inline the variable, without using any memory at all?
Much like what the preprocessor does.
This would require somehow:
forbidding or detecting if the address of the variable is taken
add that information to the ELF object files, and let LTO optimize it up
Related:
C++11 enum with class members and constexpr link-time optimization
Tested in Ubuntu 18.10, GCC 8.2.0.
According to C99/GNU99 specification:
static
is storage-class specifier
objects of file level scope by default has external linkage
objects of file level scope with static specifier has internal linkage
const
is type-qualifier (is a part of type)
keyword applied to immediate left instance - i.e.
MyObj const * myVar; - unqualified pointer to const qualified object type
MyObj * const myVar; - const qualified pointer to unqualified object type
Leftmost usage - applied to the object type, not variable
const MyObj * myVar; - unqualified pointer to const qualified object type
THUS:
static NSString * const myVar; - constant pointer to immutable string with internal linkage.
Absence of the static keyword will make variable name global and might lead to name conflicts within the application.
In C++,
static const int foo = 42;
is the preferred way to define & use constants. I.e. use this rather than
#define foo 42
because it doesn't subvert the type-safety system.
To all the great answers, I want to add a small detail:
If You write plugins (e.g. DLLs or .so libraries to be loaded by a CAD system), then static is a life saver that avoids name collisions like this one:
The CAD system loads a plugin A, which has a "const int foo = 42;" in it.
The system loads a plugin B, which has "const int foo = 23;" in it.
As a result, plugin B will use the value 42 for foo, because the plugin loader will realize, that there is already a "foo" with external linkage.
Even worse: Step 3 may behave differently depending on compiler optimization, plugin load mechanism, etc.
I had this issue once with two helper functions (same name, different behaviour) in two plugins. Declaring them static solved the problem.
Yes, it hides a variable in a module from other modules. In C++, I use it when I don't want/need to change a .h file that will trigger an unnecessary rebuild of other files. Also, I put the static first:
static const int foo = 42;
Also, depending on its use, the compiler won't even allocate storage for it and simply "inline" the value where it's used. Without the static, the compiler can't assume it's not being used elsewhere and can't inline.
This ia s global constant visible/accessible only in the compilation module (.cpp file). BTW using static for this purpose is deprecated. Better use an anonymous namespace and an enum:
namespace
{
enum
{
foo = 42
};
}
Making it private would still mean it appears in the header. I tend to use "the weakest" way that works. See this classic article by Scott Meyers: http://www.ddj.com/cpp/184401197 (it's about functions, but can be applied here as well).