i'm aware that statically declared objects are initialized in an order not under your direct control. other than that, are there any "gotcha!"s to look out for? IE issues - things you don't want to do for some reason in a custom constructor or destructor?

I've had several of annoyances with static variables. Not just initialization order, but also weird issues when trying to use them across library boundaries (if you want to seperate your engine into a library).

Also, it's not just the initialization order of your classes, but also the initialization order of your classes relative to the APIs you might be using. As an example, accidentally loading assets prior to the OpenGL context being created, or trying to output an error message prior to your logger class being initialized.

To enforce an initialization order, you can put them all in a struct - for me, my 'GameStructure' class holds the asset pools and graphics engine and etc... 'GameStructure' being bare-bones owner (composition-wise) of everything except the globals (and I've been removing more and more of the globals, so there's only two or three left).

To enforce a specific initialization time, I explicitly construct the GameStructure after control is actually handed to my program.

I hate that you can't take a pointer to constructors and destructors. Also a lot of the time there's a huge separation between allocation and initialization, though constructors attempt to package this into a single piece of code. Lastly C++ sucks when you define a constructor and yet want to create an array of your object on the stack and you get the error saying that's not possible without a trivial default constructor.

It seems like the moment you start really using constructors and destructors you have to subscribe to a bunch of other OO nonsense. At least, this is my own opinion.

Edit: Whoops lots of downvotes. I'll try to be more clear next time! I agree with all the corrections everyone made below. It's not that I don't understand how C++ works or why it is the way it is, I just disagree with it. Please take a look at the below posts responding to this one.

It seems like the moment you start really using constructors and destructors you have to subscribe to a bunch of other OO nonsense. At least, this is my own opinion

No, you have to subscribe to some C++ "nonsense" (also known as philosophy) It's not "OO" at all, in the same way that just because you use the "class" keyword to make an aggregate type doesn't mean you are using an OO paradigm in your code.

I hate that you can't take a pointer to constructors and destructors

For good reason, as this would allow you to break some fairly fundamental rules of the language.

Lastly C++ sucks when you define a constructor and yet want to create an array of your object on the stack and you get the error saying that's not possible without a trivial default constructor.

the order of initialization in constructor initializer lists is the *member declaration order*, not the order in which members are lexically arranged in the initialization list.

so if i have member variables:

int a;

int b;

and in my constructor i say:

b=5;

a=b*2;

it will process a=b*2 first?

don't recall if i heard of that one before or not. then again, i first learned c++ syntax when it first came out, and haven't really used it much since. so maybe its just yet another thing that i've already forgotten.

No, that is assignment but Josh is talking about initialization and the initializer list.

struct foo {
    foo() : b(5), a(b*2) {}
 
    int a;
    int b;
};

In this class, a is declared before b and therefore a is also initialized with twice the value of b, before b has been initializer. Code in the constructor is executed top-down, but that code is executed after the initializer list.