global variable vs static member initialization order

[n.torrey.pines]

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();

[n.torrey.pines]

On Mar 14, 5:33 pm, [e-mail] 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();

[Alf P. Steinbach]

* 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?

[n.torrey.pines]

On Mar 14, 5:53 pm, "Alf P. Steinbach" <[e-mail]:

* [e-mail]:

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).

[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.

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

[Alf P. Steinbach]

* 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?

[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. 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

[Alf P. Steinbach]

* 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?

[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...

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

[Alf P. Steinbach]

* 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?

[Victor Bazarov]

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