Why is Static Initialization Order Fiasco called this way?

176 views Asked by At

Since Static Initialization concerns Zero-initialization and initialization with a constant expression, according the C++03 standard, I cannot see which fiasco could arise there.

So, SO, why such a name, instead of eg "[Dynamic] Initialization Order Fiasco" ?

Edit:

It is actually a rhetorical question, but I find my English too weak to self-answer. I also loosely use "static initialization" as a short-cut for "all initialization happening before main()". But as 'static' term is already overloaded, I wrote down this question :

  • As a reminder that "static initialization" has a formal definition in the standard.
  • To collect any historical or anecdotal reason for this wording.
  • For anyone genuinely confused by the seeming paradox.
3

There are 3 answers

0
Mike Seymour On BEST ANSWER

"Static" here refers (somewhat ambiguously, and not entirely accurately) to variables with static storage duration, not the static initialisation of non-local variables.

You're correct that the fiasco only occurs with dynamic initialisation of non-local variables.

why such a name?

As with any colloquial expression, people use it because other people use and understand it, even if it's not the best possible way of expressing the concept.

0
Kerrek SB On

Because C++ terminology is difficult, and the technical term often conflicts with the colloquial way of saying things.

  • "Static initialization" in the standard is what you said, but people usually use it to refer to "the initialization of named objects at namespace scope with static storage duration".

  • Another example: People say "a function returns a reference", but that's not really true: Rather, the evaluation of a function call always produces a value, and values are never references. The difference is whether the value is an lvalue, xvalue or prvalue, which depends on the declared return type of the function. But that's more of a mouthful to say.

0
Pete Becker On

It's because programmers typically fall for the fallacy of the excluded middle. Most common symptom: if it isn't perfect it's useless. Another common symptom: give something that causes problems if it isn't well understood a tendentious name, as in "static initialization order fiasco".