global variable vs static member initialization order

Discussion in 'C++' started by n.torrey.pines@gmail.com, Mar 15, 2007.

  1. Guest

    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, 2007
    #1
    1. Advertising

  2. Guest

    On Mar 14, 5:33 pm, 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, 2007
    #2
    1. Advertising

  3. * :
    > 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?
     
    Alf P. Steinbach, Mar 15, 2007
    #3
  4. Guest

    On Mar 14, 5:53 pm, "Alf P. Steinbach" <> wrote:
    > * :
    >
    > > 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, 2007
    #4
  5. Alf P. Steinbach wrote:
    > * :
    >> 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
     
    Victor Bazarov, Mar 15, 2007
    #5
  6. * Victor Bazarov:
    > Alf P. Steinbach wrote:
    >> * :
    >>> 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?
     
    Alf P. Steinbach, Mar 15, 2007
    #6
  7. Alf P. Steinbach wrote:
    > * Victor Bazarov:
    >> Alf P. Steinbach wrote:
    >>> * :
    >>>> 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
     
    Victor Bazarov, Mar 15, 2007
    #7
  8. * Victor Bazarov:
    > Alf P. Steinbach wrote:
    >> * Victor Bazarov:
    >>> Alf P. Steinbach wrote:
    >>>> * :
    >>>>> 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?
     
    Alf P. Steinbach, Mar 15, 2007
    #8
  9. 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
     
    Victor Bazarov, Mar 15, 2007
    #9
  10. * 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?
     
    Alf P. Steinbach, Mar 15, 2007
    #10
  11. 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
     
    Victor Bazarov, Mar 15, 2007
    #11
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Marcin Vorbrodt

    Global static variable vs static method

    Marcin Vorbrodt, Sep 5, 2003, in forum: C++
    Replies:
    3
    Views:
    5,422
    Denis Perelyubskiy
    Sep 5, 2003
  2. dolphin
    Replies:
    3
    Views:
    1,348
    Pete Becker
    Dec 5, 2007
  3. aaragon
    Replies:
    2
    Views:
    620
    James Kanze
    Nov 2, 2008
  4. Suneel VLN

    Static member vs global variable

    Suneel VLN, Feb 3, 2010, in forum: C++
    Replies:
    9
    Views:
    1,291
    James Kanze
    Feb 4, 2010
  5. aakash
    Replies:
    2
    Views:
    249
    aakash
    Apr 23, 2011
Loading...

Share This Page