1

The C++98 language standard states: (My emphasis)

3.6.2 Initialization of nonlocal objects

£1 [...] Zeroinitialization and initialization with a constant expression are collectively called static initialization; all other initialization is dynamic initialization. [...]

£3 [...] It is implementationdefined whether or not the dynamic initialization (8.5, 9.4, 12.1, 12.6.1) of an object of namespace scope is done before the first statement of main. If the initialization is deferred to some point in time after the first statement of main, it shall occur before the first use of any function or object defined in the same translation unit as the object to be initialized. [...]

In my office, we have got two interpretations of the boldface passage...

My question is: There is a class has a whole bunch of static methods and dynamically initialized static data members. Can it (or can't it) happen that static methods in this class are called from another translation unit, before dynamic initialization has been completed?

Thanks!

[Edit:]

Perhaps this boils down to the reading of "it shall occur" as:

  1. Shall have begun
  2. Shall have been completed
Adam
  • 45
  • 5
  • What are the two interpretations? I can really only see one possible interpretation. It would be helpful to know what the other one is. – jalf Mar 14 '14 at 17:39
  • 1: Can happen. 2: Cannot happen. – Adam Mar 14 '14 at 17:48
  • The way some colleagues read this is like "use within the class" or "use from outside". – Adam Mar 14 '14 at 17:50
  • but it says *use of*. Not *use within* or *use from*. It talks about any time a function or class from this TU is used, regardless of *how*, *when* and *by whom* it is used. – jalf Mar 14 '14 at 18:09

1 Answers1

2

Can it (or can't it) happen that static methods in this class are called from another translation unit, before dynamic initialization has been completed?

The bolded passage is pretty clear, isn't it? Initialization of such data is guaranteed to happen before first use of any function or class defined in its translation unit. It doesn't matter where a function is called from. The guarantee is that initialization happens before the first use of any functions in the translation unit. Of course they may be called from another translation unit, but that doesn't make any difference. Before a function defined in this translation unit is entered, initialization must have been performed.

In other words, you're safe.

...

assuming single-threaded execution, that is. C++98 provides no guarantees in a multithreaded environment, so for a threaded application, the above guarantee typically just means that initialization will be performed by the first thread to use a function or class from this translation unit. And then you have a race condition while this initialization is being performed, where other threads might hit the partially-initialized data.

jalf
  • 243,077
  • 51
  • 345
  • 550
  • I understand your description of the race condition. But the standard does not make any statement about threads at all. So how can one be sure that a race condition may occur. I would say it boils down to if you read "shall occur" as "shall have begun" or "shall have been completed" – Adam Mar 14 '14 at 17:55
  • @Adam you can't be *sure* that a race condition occurs. That's the point, the standard says nothing about threads, so *if* you have multiple threads, all bets are off. It only guarantees what happens in a purely sequential program flow (effectively, if you have a single thread). *Then* initialization will be done before first use of any function defined in the same TU. If you have multiple threads, then anything may happen, and what I describe is just typical behavior on compilers that don't offer additional guarantees – jalf Mar 14 '14 at 18:06
  • In a sequential execution, then "shall occur" implies *both* "shall have begun" and "shall have been completed". And in a non-sequential execution (multiple threads), all bets are off. – jalf Mar 14 '14 at 18:09
  • Thanks Jalf, for bothering to answer in so much detail! – Adam Mar 17 '14 at 13:52