Printable View
Does the following code produce undefined behaviour?
Im talking specifically about the the constructor of X which uses std::cout. cout and "static X x" are both global objects and class X uses cout in its constructor before main is entered. In other words, can I always depend on cout being constructed properly before use?Code:#include <iostream>
class X
{
public:
X() { std::cout << "X" << std::endl;
};
static X x;
int main()
{
X x2;
return 0;
}
Yes.
It will not work for your own classes, but `std::cout' is a guaranteed entity.
Soma
Edit: Nevermind. Misread the question.
So, here it it. Correctly now:
It can. For instance,Quote:
It will not work for your own classes,
test.hpp
main.cppCode:class foo {
public:
foo(): val_(12) {}
int getval() { return val_; }
private:
int val_;
};
static foo bar;
Code:#include <iostream>
#include "test.hpp"
class X {
public:
X() { value_ = bar.getval(); }
int getvalue() { return value_; }
private:
int value_;
};
static X x;
int main() {
X x2;
std::cout << x.getvalue();
return 0;
}
Of course it can, but it isn't guaranteed that bar is properly constructed before x. Therefore, it's undefined behavior and bad to rely on.
Why not? Isn't the order defined within the same compilation unit?
Is it? I'm under the impression it is not.
Only across different compilation units. And even so you can control it through things like (according to the previous example):Quote:
Originally Posted by Elysia
hide.hpp
test.cppCode:class foo {
public:
foo(): val_(12) {}
int getval() { return val_; }
private:
int val_;
};
test.hppCode:#include "hide.hpp"
foo& getfoo() {
static foo bar;
return bar;
}
You then use test.hpp as your header file in main. This simple method guarantees you control over initialization order across different compilation units.Code:#include "hide.hpp"
foo& getfoo();
...
As for cout, this is simple because the C++ standard requires that cout, cin, cerr and its wide brothers and sisters be defined prior to any other user-defined objects. How it exactly goes about this, I'm unsure. Probably by having them already pre-compiled?
In any case, because of this you can even use cout and family on the destructors of your static objects on any compilation unit.
Ah, I see. Initialization is top to bottom in compilation units then? Or something else entirely?
Well, I never liked the analogy because it forgets to mention objects that may be being defined by other objects.
In any case, yes. Top to bottom, not moving forward until all types on a given branch have been defined.
MinGW's <iostream> header has these lines:Quote:
As for cout, this is simple because the C++ standard requires that cout, cin, cerr and its wide brothers and sisters be defined prior to any other user-defined objects. How it exactly goes about this, I'm unsure. Probably by having them already pre-compiled?
That is, the construction of this object somehow forces the constructors for streams to be called.Code:// For construction of filebuffers for cout, cin, cerr, clog et. al.
static ios_base::Init __ioinit;
It will not work for your own classes. You can't pretend otherwise by limiting yourself to a single translation unit or using the "accessor trick".
Soma
"accessor cheat". Cheat is more appropriate I guess, since what it is doing is giving the impression of a global object when in fact it is a local object.(*)Quote:
Originally Posted by phantomotap
It's quite irrelevant what you think on this matter, I'm afraid. All that it is being asked is how can I guarantee order of initialization of a static global object. Since I cannot tell the compiler to do something its patriotic allegiance to the standards forbids him of doing, the alternative is to offer sideways solutions.
Solutions that work. Solutions that, contrary to what your assertion seems to want to indicate, are used successfully and handle the problem on a daily basis. This is the realm of problem solving. And you can't solve a problem without compromising. Especially in your adherence to strict semantics.
(*) incidentally this is pretty much the makings of a singleton object. So one might want to take the next step and actually fully apply the pattern to the object, in doing so offering a more elegant and reusable solution.
>> "accessor cheat". Cheat is more appropriate I guess...
I was always under the impression this was known as the "construct on first use" idiom. I wouldn't call it a trick or a cheat; I think idiom suits it nicely.
Ah, thanks bithub. I was struggling to remember the proper name. It was driving me nuts particularly on this last post when it seemed to me would be more proper.
Long time away from the books and a preliminary search on google didn't reveal me any hints.
Why will it (what?) not work for your own classes. The standard seems to prescribe in detail how it should be implemented for cout etc and it seems that the implementation uses only normal language rules. For example, GCC's comment on ios_base::Init:Quote:
It will not work for your own classes, but `std::cout' is a guaranteed entity.
I also seem to remember an article that demonstrates a better way which hadn't been discovered by the time iostreams were invented.Code:// 27.4.2.1.6 Class ios_base::Init
// Used to initialize standard streams. In theory, g++ could use
// -finit-priority to order this stuff correctly without going
// through these machinations.
The only requirements I can find for the 8 <iostream> objects, are that they have to be constructed 1) before or during the first ios_base::Init construction, 2) before main.Quote:
Originally Posted by Mario F.
Every translation unit that includes <iostream> will get its own __ioinit global.
The MSCRT from VS 2008 uses it's #pragma init_seg(compiler) support.
gg