By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
445,851 Members | 2,097 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 445,851 IT Pros & Developers. It's quick & easy.

global variable vs static member initialization order

P: n/a
Are global variables (and const's) guaranteed to be initialized before
static class members (and methods) ?
const int x = 19907;
int get_x() { return x; }

// another compilation unit:

int get_x();
static int my_class::y = get_x();

Mar 15 '07 #1
Share this Question
Share on Google+
10 Replies


P: n/a
On Mar 14, 5:33 pm, n.torrey.pi...@gmail.com wrote:
Are global variables (and const's) guaranteed to be initialized before
static class members (and methods) ?
corrected code example:

const int x = 19907;
int get_x() { return x; }

// another compilation unit:

int get_x();
struct my_class { static int y; };
int my_class::y = get_x();
Mar 15 '07 #2

P: n/a
* n.************@gmail.com:
Are global variables (and const's) guaranteed to be initialized before
static class members (and methods) ?
No, C++ does not make that distinction. Furthermore, "methods" (ITYM
member functions) require no initialization and are not initialized.
However, there is a distinction for initialization with POD type
constant expression.
const int x = 19907;
int get_x() { return x; }

// another compilation unit:

int get_x();
static int my_class::y = get_x();
See the FAQ item titled "What's the "static initialization order
fiasco"?", and the following items.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Mar 15 '07 #3

P: n/a
On Mar 14, 5:53 pm, "Alf P. Steinbach" <a...@start.nowrote:
* n.torrey.pi...@gmail.com:
Are global variables (and const's) guaranteed to be initialized before
static class members (and methods) ?

No, C++ does not make that distinction.
Between [const] global variables and [const] static members?
const int x = 19907;
int get_x() { return x; }
// another compilation unit:
int get_x();
static int my_class::y = get_x();
So is the behavior of the above code undefined?

Does it make a difference if
a. everything (x, y, get_x's return type) is const ?
b. x is int / other POD, such as a const array of plain structs?

See the FAQ item titled "What's the "static initialization order
fiasco"?", and the following items.
Thanks - I'd seen it, and just looked at it again. What the FAQ
suggests is not completely satisfactory because "construct on first
use" is not thread-safe. I think that moving the relevant
interdepedent code to a single compilation unit would be better (but
not ideal).

Mar 15 '07 #4

P: n/a
Alf P. Steinbach wrote:
* n.************@gmail.com:
>Are global variables (and const's) guaranteed to be initialized
before static class members (and methods) ?

No, C++ does not make that distinction. Furthermore, "methods" (ITYM
member functions) require no initialization and are not initialized.
However, there is a distinction for initialization with POD type
constant expression.
>const int x = 19907;
int get_x() { return x; }

// another compilation unit:

int get_x();
static int my_class::y = get_x();

See the FAQ item titled "What's the "static initialization order
fiasco"?", and the following items.
I do not believe any of this is relevant here. 'x' is a compile-time
constant. There is no initialisation, it's replaced with its value
in the body of 'get_x' function.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Mar 15 '07 #5

P: n/a
* Victor Bazarov:
Alf P. Steinbach wrote:
>* n.************@gmail.com:
>>Are global variables (and const's) guaranteed to be initialized
before static class members (and methods) ?
No, C++ does not make that distinction. Furthermore, "methods" (ITYM
member functions) require no initialization and are not initialized.
However, there is a distinction for initialization with POD type
constant expression.
>>const int x = 19907;
int get_x() { return x; }

// another compilation unit:

int get_x();
static int my_class::y = get_x();
See the FAQ item titled "What's the "static initialization order
fiasco"?", and the following items.

I do not believe any of this is relevant here. 'x' is a compile-time
constant. There is no initialisation, it's replaced with its value
in the body of 'get_x' function.
I'm not so sure of that. 'x' can serve as constant expression, yes.
The above code necessarily using 'x' as a compile time constant, well, I
don't see that anywhere in the holy standard (do you have a quote?).

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Mar 15 '07 #6

P: n/a
Alf P. Steinbach wrote:
* Victor Bazarov:
>Alf P. Steinbach wrote:
>>* n.************@gmail.com:
Are global variables (and const's) guaranteed to be initialized
before static class members (and methods) ?
No, C++ does not make that distinction. Furthermore, "methods"
(ITYM member functions) require no initialization and are not
initialized. However, there is a distinction for initialization
with POD type constant expression.

const int x = 19907;
int get_x() { return x; }

// another compilation unit:

int get_x();
static int my_class::y = get_x();
See the FAQ item titled "What's the "static initialization order
fiasco"?", and the following items.

I do not believe any of this is relevant here. 'x' is a compile-time
constant. There is no initialisation, it's replaced with its value
in the body of 'get_x' function.

I'm not so sure of that.
I wonder what makes you unsure. Have you *ever* seen anything to
suggest that the compiler does *not* replace accessing the variable
with a simple [immediate] value?
'x' can serve as constant expression, yes.
The above code necessarily using 'x' as a compile time constant,
well, I don't see that anywhere in the holy standard (do you have a
quote?).
No, I don't have a quote. My point is that "static initialisation
order fiasco" is applicable here with a *significantly* lower
probability than the use of the constant by replacing with its value.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Mar 15 '07 #7

P: n/a
* Victor Bazarov:
Alf P. Steinbach wrote:
>* Victor Bazarov:
>>Alf P. Steinbach wrote:
* n.************@gmail.com:
Are global variables (and const's) guaranteed to be initialized
before static class members (and methods) ?
No, C++ does not make that distinction. Furthermore, "methods"
(ITYM member functions) require no initialization and are not
initialized. However, there is a distinction for initialization
with POD type constant expression.

const int x = 19907;
int get_x() { return x; }
>
// another compilation unit:
>
int get_x();
static int my_class::y = get_x();
See the FAQ item titled "What's the "static initialization order
fiasco"?", and the following items.
I do not believe any of this is relevant here. 'x' is a compile-time
constant. There is no initialisation, it's replaced with its value
in the body of 'get_x' function.
I'm not so sure of that.

I wonder what makes you unsure.
Just what I wrote -- I cannot find any guarantee in the standard.

Have you *ever* seen anything to
suggest that the compiler does *not* replace accessing the variable
with a simple [immediate] value?
No, and I agree that with a quality implementation it's not a practical
problem.

> 'x' can serve as constant expression, yes.
The above code necessarily using 'x' as a compile time constant,
well, I don't see that anywhere in the holy standard (do you have a
quote?).

No, I don't have a quote. My point is that "static initialisation
order fiasco" is applicable here with a *significantly* lower
probability than the use of the constant by replacing with its value.
On that I think we can agree. However, until some guarantee is found in
the standard (if it exists), I think it's prudent to code as if there's
no such guarantee. I'd just provide that constant in a header file
(thus having its possible initialization in the compilation unit where
it's used), or perhaps used an enum, or, except for the naming scheme,

int get_x() { static int const x = 19907; return x; }
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Mar 15 '07 #8

P: n/a
Alf P. Steinbach wrote:
* Victor Bazarov:
>[..] My point is that "static initialisation
order fiasco" is applicable here with a *significantly* lower
probability than the use of the constant by replacing with its value.

On that I think we can agree. However, until some guarantee is found
in the standard (if it exists), I think it's prudent to code as if
there's no such guarantee. I'd just provide that constant in a
header file (thus having its possible initialization in the
compilation unit where it's used), or perhaps used an enum, or,
except for the naming scheme,
int get_x() { static int const x = 19907; return x; }
For that, why bother with 'x' at all? I understand that there can be
scientific curiosity, but wouldn't it be better to place 'get_x' in
the header and declare/define it like

inline int get_x() { return 19907; }

? Just a thought...

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Mar 15 '07 #9

P: n/a
* Victor Bazarov:
Alf P. Steinbach wrote:
>* Victor Bazarov:
>>[..] My point is that "static initialisation
order fiasco" is applicable here with a *significantly* lower
probability than the use of the constant by replacing with its value.
On that I think we can agree. However, until some guarantee is found
in the standard (if it exists), I think it's prudent to code as if
there's no such guarantee. I'd just provide that constant in a
header file (thus having its possible initialization in the
compilation unit where it's used), or perhaps used an enum, or,
except for the naming scheme,
int get_x() { static int const x = 19907; return x; }

For that, why bother with 'x' at all? I understand that there can be
scientific curiosity, but wouldn't it be better to place 'get_x' in
the header and declare/define it like

inline int get_x() { return 19907; }

? Just a thought...
As I wrote, and you quoted here, if it was my code, I'd just provide
that /constant/ in the header, no 'get_x'... ;-)

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Mar 15 '07 #10

P: n/a
Alf P. Steinbach wrote:
* Victor Bazarov:
>Alf P. Steinbach wrote:
>>* Victor Bazarov:
[..] My point is that "static initialisation
order fiasco" is applicable here with a *significantly* lower
probability than the use of the constant by replacing with its
value.
On that I think we can agree. However, until some guarantee is
found in the standard (if it exists), I think it's prudent to code
as if there's no such guarantee. I'd just provide that constant in
a header file (thus having its possible initialization in the
compilation unit where it's used), or perhaps used an enum, or,
except for the naming scheme,
int get_x() { static int const x = 19907; return x; }

For that, why bother with 'x' at all? I understand that there can be
scientific curiosity, but wouldn't it be better to place 'get_x' in
the header and declare/define it like

inline int get_x() { return 19907; }

? Just a thought...

As I wrote, and you quoted here, if it was my code, I'd just provide
that /constant/ in the header, no 'get_x'... ;-)
Interface (a function) can be a requirement. Template code often
requires functors, libraries require callbacks...

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Mar 15 '07 #11

This discussion thread is closed

Replies have been disabled for this discussion.