Relying on order of initialisation

Question

According to the C++ 14 standard, non-static member variables are initialised in the order they are declared in a class. The cut down code below relies on this rule to control a thread function.

class foo
{
     foo(): 
          keep_going{true},
          my_thread(&foo::go,this)
     {}

      void go()
      {
          while(keep_going)
             check a std::condition_variable and do some work;
      }
      bool keep_going;
      std::thread my_thread;
}

Note that keep_going is declared before the thread object and should be set to true by the time the thread enters the go function. This is fine and seems to work OK.

However, this is multithreaded code and it pays to be paranoid so I have two questions:

1 Is it safe to rely on the order of initialisation like this? My real object doesn't make sense without the processing thread so I want to set it going in the constructor.

2 Is it unsafe to give code to others when it relies on relatively obscure things like the order of initialisation?

order of initialization is not obscure, it's well defined and there is nothing wrong with this code. — Salgar, Sep 30 '15 at 15:47
1) yes order of initialisation is part of the specs, 2) yes - clear documentation might help — BeyelerStudios, Sep 30 '15 at 15:47
I would rely on it only with a good comment explaining. Follow the quote 'Always code like your code mantainer is a serial killer who knows where you live' — Lorenzo Belli, Sep 30 '15 at 15:49

score 5 · Accepted Answer · answered Sep 30 '15 at 15:48

5

Is is safe according to the standard.
Extremely unsafe. Few folk are aware of this, and someone maintaining your header file might reorder the members with disastrous consequences.

I wouldn't rely on it.

answered Sep 30 '15 at 15:48

Bathsheba

231,907
34
361
483

I put it in with some block cap warnings in the header file. – Oct 02 '15 at 08:25

score 4 · Answer 2 · edited May 23 '17 at 11:44

Although by the standard it is safe, I wouldn't go with it.

Anecdote: I wrote a customized ThreadPool on Windows OS using visual studio 2013. I declared the thread pool global. Of course by the standard, global objects are destructed after main has returned. the thread pool destructor tried to join each thread, but alas! a dead-lock. (you can read about this problem here: std::thread::join() hangs if called after main() exits when using VS2012 RC). The standard states very clearly that if a thread is joinable, there is no problem joining it, but as you can see, this wasn't perfectly implemented.

Why am I telling you this unrelated issue? Because even compilers and platforms have some bugs. Subtle things may not get implemented 100% correctly at the first few relevant-supporting compiler versions.

This is why I wouldn't go with this idea. As a work-around, I would declare the thread wrapped in std::unique_ptr and initialize it in the constructor body. That way there is no chance it will be initialized before keep_going.

foo(): 
  keep_going{true}
   { my_thread = std::make_unique<std::thread>(&foo::go,this); }

score 2 · Answer 3 · answered Sep 30 '15 at 15:57

I'd like to rewrite the code to make the code obvious even to a monkey.

Another potential problem here may occur when the class foo is the base class. The thread will start on non fully constructed object. What will happen if the constructor of the derived class fails? In this case it is better move thread execution out of the constructor to start() method.

Relying on order of initialisation

3 Answers3