A Small Look at Constructor Data-member Evaluation Order (C++)

I have a habbit of regularly going back to basics and doing a form of high-speed review of whatever in relation to general programming. I tend to forget small details, but if left for too long, these items add up and people can end up subconsiously forgetting entire topics and/or functionalities.

One interesting thing that may be a small and rather overlooked feature of C++ would be the way the constructor, or rather the compiler would package data memebers of a constructor in the order the class member variables are listed.

 Ctor::Ctor( GameType& gtRef )  
      :  
      randomizer( rand() ),  
     gameObj0(x(randomizer), y(randomizer)),  
     gameObj1(x(randomizer), y(randomizer))  
 {       
      flag = false;  
 }  

In the above example, everything seems fine, however in the class body, there was something wrong when debugging the issue.

 private:  
      MainWindow& wnd;  
      Graphics gfx;  
      // Game Objects  
     GameObject gameObj0;  
     GameObject gameObj1;  
     // flags  
      bool flag;       
      // num generator  
      std::random randomizer;   

I don't remember this issue popping up as much for me, but it ended up being one of those flashback Eureka moments. This is a very simplified, psuedo-code version of my original list, but hopefully it should be descriptive.

I think this is one those things people usually bump over early on, but to me it was significant enough to write about as a blog post.

Ofcourse, the correct solution is to list the member variables so that either the variable or Ctor data members would be both in the correct order.

 private:  
      MainWindow& wnd;  
      Graphics gfx;  

       // num generator  
       std::random randomizer;   

      // Game Objects  
     GameObject gameObj0;  
     GameObject gameObj1;  
     // flags  
      bool flag;       

This is officially in the official standard (pg. 290, 12.16.2 (in section 13.3)), though it's a rather small mention, but again, it's always these small things that people tend to miss and it's the type of human error that might keep people busy even in larger teams.