473,383 Members | 1,798 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,383 software developers and data experts.

global variable vs static member initialization order

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
10 4164
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
* 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
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
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
* 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
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
* 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
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
* 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
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 thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

1
by: Francesco Monica | last post by:
Hello. This (example) code will compile correctly with gcc <= 3.3.0, but doesn't compile with gcc 3.3.1 (under linux): ------------------------------------------------------------- template <...
5
by: gbs | last post by:
Isn't this legal code to initialize a static member of a template class? template <class T> class TemplatedClassT { static int staticMember_; };
6
by: shendaras | last post by:
Hello, I have a quick question about the syntax I should use to initialize a static member variable which is non-copyable (boost::noncopyable, in fact). class non_copyable : private...
11
by: ALiX | last post by:
Hi! My template class has a const static data member, which is used by the constructor. It seems that the program does not produce the correct result. Either it is the fault of the compiler (gcc...
2
by: Frank Neuhaus | last post by:
(Sorry I accidently submitted the question twice) Hi I've got a question on the initialization of static member variables. I have some class that has a static member variable (some...
1
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...
0
by: aa123db | last post by:
Variable and constants Use var or let for variables and const fror constants. Var foo ='bar'; Let foo ='bar';const baz ='bar'; Functions function $name$ ($parameters$) { } ...
0
by: ryjfgjl | last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
0
by: ryjfgjl | last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
0
by: emmanuelkatto | last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud. Please let me know. Thanks! Emmanuel
1
by: nemocccc | last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
0
by: Hystou | last post by:
There are some requirements for setting up RAID: 1. The motherboard and BIOS support RAID configuration. 2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.