Jump to content
  • Advertisement
Sign in to follow this  
remdul

constructor weirdness

This topic is 4164 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I noticed something weird. It probably has to do with the order in which constructors are called, but I don't understand why. I have a class: class CMyClass { public: int i; }; It has a constructor: CMyClass::CMyClass() { i = 0; } I define a global instance of this class: CMyClass ClassA; I have another class: class CYourClass It has a constructor: CYourClass::CYourClass() { ClassA.i = 666; }; Later in the program I create 2 instances of CYourClass: bla = new CYourClass; Later in the program I read back ClassA.i and it == 0! Somehow the ClassA constructor is triggered late, and overwrites the value 'i'. I'm sure of this, because when I put a MessageBox() in the constructors, CYourClass is triggered 2 times, BEFORE the CMyClass constructor is triggered. I can even read back the value of 'i' and display it in a MessageBox and it == 666. I would assume the ClassA constructor is triggered BEFORE the first time CYourClass constructor is triggered? You know, because, I reference ClassA inside the CYourClass constructor...

Share this post


Link to post
Share on other sites
Advertisement
Ok. I assumed that constructors would be triggered the first time they where referenced. Why wouldn't a compiler put constructors in the order I described? In other words; what kind of cool stuff is this behavior useful for?

Share this post


Link to post
Share on other sites
Quote:
Original post by remdul
Ok. I assumed that constructors would be triggered the first time they where referenced. Why wouldn't a compiler put constructors in the order I described? In other words; what kind of cool stuff is this behavior useful for?


Because there is no prescribed order in which these objects are constructed.

The cool stuff here includes:
- breaking huge code-bases (see log4cpp, same problem)
- spending hours, days, weeks, months on this type of problem
- learning why static references are bad, and why RAII is godsend
- C++'s way of teaching programmers humility

But there's no benefit from this. It just falls in a very long list of topics covered under "undefined behaviour".

Share this post


Link to post
Share on other sites
Ahh yes, that kind of cool stuff. :)

It just didn't make much sense to me. Perhaps a compiler warning would have been sweet (if it is possible to detect at all).

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!