I decided to do a test with computed gotos and local statics
void g() { std::cout << "init "; }
void f() {
int z = 0;
y: z++;
static int x =
(g(), z == 1 ? ({ goto *&&y; 0; }) : 0);
}
int main() { f(); std::cout << "!"; f(); }
I wanted to see whether the output would be "init init !". But to my surprise I didn't get that output, but instead GCC handled it gracefully, outputting at runtime:
init terminated by recursive_init_error: exception
What's that exception? Is it a Standard exception? C++03 or C++0x? Thanks for any explanation.
It's caused by what is stated in C++03 §6.7/4:
... Otherwise such an object is initialized the first time control passes through its declaration; such an object is considered initialized upon the completion of its initialization. If the initialization exits by throwing an exception, the initialization is not complete, so it will be tried again the next time control enters the declaration. If control re-enters the declaration (recursively) while the object is being initialized, the behavior is undefined. [Example:
int foo(int i)
{
static int s = foo(2*i); // recursive call – undefined
return i+1;
}
--end example]
GCC throws an exception in that case. Here's some documentation about it.
C++11 update: The following wording was added in C++11, just before the text about the recursive case:
If control enters the declaration concurrently while the variable is being initialized, the concurrent execution shall wait for completion of the initialization.88
88 The implementation must not introduce any deadlock around execution of the initializer.
Doesn't change the problem here, but does make this construct thread-safe when there is no recursion.
Related
class IA
{
public:
virtual void Print() = 0;
}
IA* GetA();
class A : public IA
{
public:
int num = 10;
A()
{
GetA()->Print();
}
void Print()
{
std::cout << num << std::endl;
}
}
IA* GetA()
{
static A a;
return &a;
}
int main()
{
GetA();
std::cout << "End" << std::endl;
getchar();
return 0;
}
Obviously, class A's constructor function calls itself.
"static A a" will get stuck in a loop.
On VS2013, this code can get out from the loop and print "End" on the console.
On VS2017, this code gets stuck in a loop.
**What does VS2013 do for this code?
Nothing in particular has to happen. According to the C++ standard:
[stmt.dcl] (emphasis mine)
4 Dynamic initialization of a block-scope variable with static storage
duration or thread storage duration is performed the first time
control passes through its declaration; such a variable is considered
initialized upon the completion of its initialization. If the
initialization exits by throwing an exception, the initialization is
not complete, so it will be tried again the next time control enters
the declaration. If control enters the declaration concurrently while
the variable is being initialized, the concurrent execution shall wait
for completion of the initialization. If control re-enters the
declaration recursively while the variable is being initialized, the
behavior is undefined. [ Example:
int foo(int i) {
static int s = foo(2*i); // recursive call - undefined
return i+1;
}
— end example ]
The statement I emboldened is exactly what happens in your program. It's also what the standard's example shows as undefined. The language specification says an implementation can do whatever it deems appropriate. So it could cause an infinite loop, or it may not, depending on the synchronization primitives your implementation uses to prevent concurrent reentry into the block (the initialization has to be thread safe).
Even before C++11, the behavior of recursive reentry was undefined. An implementation could do anything to make sure an object is initialized only once, which in turn could produce different results.
But you can't expect anything specific to happen portably. Not to mention undefined behavior always leaves room for a small chance of nasal demons.
The behaviour is undefined. The reason it "worked" in Visual Studio 2013 is that it didn't implement thread safe initialisation of function statics. What is probably happening is that the first call to GetA() creates a and calls the constructor. The second call to GetA() then just returns the partially constructed a. As the body of your constructor doesn't initialise anything calling Print() doesn't crash.
Visual Studio 2017 does implement thread safe initialisation. and presumably locks some mutex on entry to GetA() if a is not initialised, the second call to GetA() then encounters the locked mutex and deadlocks.
Note in both cases this is just my guess from the observed behaviour, the actual behaviour is undefined, for example GetA() may end up creating 2 instances of A.
This question already has answers here:
Why does initialization of local static objects use hidden guard flags?
(2 answers)
Closed 4 years ago.
As in the title - how does program know, that foo is already initialized when function is called second time:
int getFoo()
{
static int foo = 30;
return foo;
}
int main()
{
getFoo();
getFoo();
}
I want to know, whether the program stores some additional information about which static variable was already initialized.
Edit:
I found an answer here:
Why does initialization of local static objects use hidden guard flags?
Like I guessed - most compilers store additional "guard variable".
Have a look at [stmt.dcl]/4:
Dynamic initialization of a block-scope variable with static storage duration or thread storage duration is performed the first time control passes through its declaration; such a variable is considered initialized upon the completion of its initialization. If the initialization exits by throwing an exception, the initialization is not complete, so it will be tried again the next time control enters the declaration. If control enters the declaration concurrently while the variable is being initialized, the concurrent execution shall wait for completion of the initialization.94 If control re-enters the declaration recursively while the variable is being initialized, the behavior is undefined.
You have to be careful here. Primitive statics are initialised at compile time (as long as the initialisation value is a compile-time contant, as Peter points out), so in your example, GetFoo just, in effect, returns a constant.
HOWEVER...
statics which initialise an object (or initialise a primitive by calling a function) perform said initialisation when the scope in which they are declared is entered for the first time.
Furthermore, as of C++ 11 this has to be done in a threadsafe way, which generates a lot of extra code (although not much runtime overhead, after the first time through) and that might be an issue on, say, a micro-controller where code size often matters.
Here's a concrete example:
#include <iostream>
struct X
{
X () { std::cout << "Initialising m\n"; m = 7; }
int m;
};
void init_x ()
{
static X x;
}
int main () {
std::cout << "main called\n";
init_x ();
std::cout << "init_x returned\n";
}
Output:
main called
Initialising m
init_x returned
Live demo: https://wandbox.org/permlink/NZApcYYGwK36vRD4
Generated code: https://godbolt.org/z/UUcL9s
If I have
atomic<int> cnt=0;
int get_int() noexcept
{
cnt++;
return rand();
}
and then:
void func()
{
static const auto value = get_int();
}
I know that there will be no race condition on initialization of value, but I don't know if
get_int() will be called once, or in my example will cnt be 1 (and not 2, 3, 4, or 5).
Assume multiple threads enter func() and get_int has only 1 callsite in func().
C++11 guarantees that there will be no race condition N3797 - §6.7/4:
An implementation is permitted to perform early initialization of other block-scope variables with static or
thread storage duration under the same conditions that an implementation is permitted to statically initialize
a variable with static or thread storage duration in namespace scope (3.6.2). Otherwise such a variable is
initialized the first time control passes through its declaration; such a variable is considered initialized upon
the completion of its initialization. If the initialization exits by throwing an exception, the initialization
is not complete, so it will be tried again the next time control enters the declaration. If control enters
the declaration concurrently while the variable is being initialized, the concurrent execution shall wait for
completion of the initialization.92 If control re-enters the declaration recursively while the variable is being
initialized, the behavior is undefined. [ Example:
int foo(int i) {
static int s = foo(2*i); // recursive call - undefined
return i+1;
}
- end example ]
It's not re-entrant but thread-safe. Make sure there will not be other parts of the code that will call get_int() before func() anyway.
get_int() will be called only once from that line , but given your code, get_int() could be called beforehand from different locations in the code.
Consider the following code:
#include <iostream>
struct X{
X(){
throw 0;
}
};
void f(){
static X x;
}
int main(){
try {
f();
}
catch(int) {
std::cout << "Caught first time" << std::endl;
}
try {
f();
}
catch(int) {
std::cout << "Caught second time" << std::endl;
}
}
The output of this program is
Caught first time
Caught second time
So, is it guaranteed by the standard that the constructor of a static object is going to be called over and over again until it's successfully completed? I can't find the place in the standard where it is mentioned, so a quote or a reference to chapter and verse are very much welcome.
Or is there any undefined behavior involved in my example?
It is guaranteed that the construction will be attempted as long as it fails.
It's caused by what is stated in C++03 §6.7/4:
... Otherwise such an object is initialized the first time control passes through its declaration; such an object is considered initialized upon the completion of its initialization. If the initialization exits by throwing an exception, the initialization is not complete, so it will be tried again the next time control enters the declaration. If control re-enters the declaration (recursively) while the object is being initialized, the behavior is undefined. [Example:
int foo(int i)
{
static int s = foo(2*i); // recursive call – undefined
return i+1;
}
--end example]
I will note that gcc throws an exception in case of recursive initialization attempt, see litb's related question as for my source.
I'm wondering, for no other purpose than pure curiosity (because no one SHOULD EVER write code like this!) about how the behavior of RAII meshes with the use of goto (lovely idea isn't it).
class Two
{
public:
~Two()
{
printf("2,");
}
};
class Ghost
{
public:
~Ghost()
{
printf(" BOO! ");
}
};
void foo()
{
{
Two t;
printf("1,");
goto JUMP;
}
Ghost g;
JUMP:
printf("3");
}
int main()
{
foo();
}
When running the following code in Visual Studio 2005 I get the following output.
1,2,3 BOO!
However I imagined, guessed, hoped that 'BOO!' wouldn't actually appear as the Ghost should have never been instantiated (IMHO, because I don't know the actual expected behavior of this code).
What's up?
I just realized that if I instantiate an explicit constructor for Ghost the code doesn't compile...
class Ghost
{
public:
Ghost()
{
printf(" HAHAHA! ");
}
~Ghost()
{
printf(" BOO! ");
}
};
Ah, the mystery ...
The standard talks about this explicitly - with an example; 6.7/3 "Declaration statement" (emphasis added by me):
Variables with automatic storage duration are initialized each time their declaration-statement is executed. Variables with automatic storage duration declared in the block are destroyed on exit from the block.
It is possible to transfer into a block, but not in a way that bypasses declarations with initialization. A program that jumps from a point where a local variable with automatic storage duration is not in scope to a point where it is in scope is ill-formed unless the variable has POD type and is declared without an initializer.
[Example:
void f()
{
//...
goto lx; //ill-formed: jump into scope of a
//...
ly:
X a = 1;
//...
lx:
goto ly; //OK, jump implies destructor
//call for a, followed by construction
//again immediately following label ly
}
—end example]
So it seems to me that MSVC's behavior is not standards compliant - Ghost is not a POD type, so the compiler should issue an error when the the goto statement is coded to jump past it.
A couple other compilers I tried (GCC and Digital Mars) issue errors. Comeau issues a warning (but in fairness, my build script for Comeau has it configured for high MSVC compatibility, so it might be following Microsoft's lead intentionally).
Goto isn't radioactive. Leaving by goto is little different from leaving by exception. Entering by goto should be dictated by convenience, not the limits of the language. Not knowing whether the ghost is constructed or not is a good reason not to do that.
Jump in before the constructor. If you want to jump in after some object is already constructed, enclose it in a new scope or otherwise resolve its lifetime yourself.
In this scenario, I have found following approach useful.
void foo()
{
{
Two t;
printf("1,");
goto JUMP;
}
{
Ghost g;
// operations that use g.
}
// g is out of scope, so following JUMP is allowed.
JUMP:
printf("3");
}
Confining the scope of variable g in your foo() function, will make the goto jump legal. Now, we are not jumping from a place where g is not initialized to a place where g is expected to be initialized.