OutpostUniverse / OPHD

OutpostHD - Open source remake of Sierra On-Line's Outpost
BSD 3-Clause "New" or "Revised" License
110 stars 21 forks source link

Refactor/population panel constructor #1443

Closed oscar139 closed 8 months ago

oscar139 commented 9 months ago

Initial attempt to address issue #1442.

DanRStevens commented 8 months ago

Looks like constructor init list items don't match the order of the fields in the class. We have a warning flag enabled that checks for that.

Member fields are always initialized in their declaration order, not the order they appear in the init list. Hence putting them out of order in the init list can be misleading. One of the reasons for that is a class can have many constructors, which means it can have many init list orderings. The class definition only appears once though, so the order specified there is what is used.

Initialization order is important in the case of exceptions, since the exception handler must destruct all objects in the reverse order they were constructed (and only for the objects that completed construction). If a constructor fails with an exception part way through, some set of member fields may need to be destructed, depending on how far into construction the class got.

I'm not entirely sure why all constructors need to initialize objects in the same order, though if all constructors initialize objects in the same order, than they can all share the same exception handling code to destruct objects in the same order.


Ahh, the section under "Initialization Order" has an answer: https://en.cppreference.com/w/cpp/language/constructor

(Note: if initialization order was controlled by the appearance in the member initializer lists of different constructors, then the destructor wouldn't be able to ensure that the order of destruction is the reverse of the order of construction.)

It's because all constructors share the same destructor, and it needs to destruct objects in a set order, which must be the reverse of the construction order.