Jump to content
  • Advertisement
Sign in to follow this  
Norman Barrows

Constructor gotcha's?

This topic is 1259 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

Recently i've been thinking about what form an oo-ish implementation of my typical game architecture would look like. so far, the mapping from procedural to oo code has been amazingly lucid, with some interesting organizational insights gained along the way such as camera.cansee(location) where location includes a bbox or bsphere radius, or AABrect dimensions. in the procedural code there are inits (and some uninits) for many things such as: program, game, generic_graphics_engine, generic_audio_engine, asset pools, etc. naturally, these are prime candidates for custom constructors and destructors. 

 

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?

 

 

 

 

Share this post


Link to post
Share on other sites
Advertisement

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. dry.png

 

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.

Edited by Servant of the Lord

Share this post


Link to post
Share on other sites

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.

Edited by Randy Gaul

Share this post


Link to post
Share on other sites


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

 

that leads to a related constructor question i've had with regard to this "oo port".

 

i only need one entity list at the program level that i can re-init with each run of the game, not one i create with each game instance i run.

 

IE in non OO engish:  i have an entity list. i only need to declare it once at program start then init it each time i run a new game or load a saved game. i don't need to new it for each game then dispose it when the game ends. this would indicate the need for an explicit init method, rater than using the constructor. is this how its usually done? 

Share this post


Link to post
Share on other sites


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.

 

aside: in college, my roomies had a calender with quotes for the day, one of which was "I've already forgotten what you'll never even know." pretty harsh huh? <g>

 


Avoid overly long parameter lists (prefer passing in structures or pointer/references to structures.

 

yet another point of question in my "OO-port".   all i need to do is create one entity list, one generic_graphics_engine, one camera, etc at program start (typically). so the program object would own them, then pass them to a game object. and in general, things that used to be global would be declared at a higher level, and passed as parameters to lower level code. this could mean a lot of parameters. so i was thinking about using pointers to parameter structs the way d3d does. is this considered the best way to pass around such "globals" ?

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.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!