Jump to content
  • Advertisement
Sign in to follow this  
pauls_1979

C++ Program Entry Point Before Static Initialisers

This topic is 3470 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 have been using my own global memory management routines and overriding the new and delete operators in my engine for some time now, and the system seems to work pretty well for me. I develop games for several platforms including DS and IPhone, so it's nice have full control over how much memory is available, how it is allocated and so on, even when developing on PC. Unfortunately, because my memory manager in initialised in the main entry point (WinMain or whatever the platform equivalent might be) any attempts to allocate memory at the static initialisation stage are doomed to failure (or worse). Here's a quick example:
// Fails because memory manager has not yet been initialised.
static std::string appName = "Demo App";
Does anyone know of a good way for me to initialise my memory manager before static initialisation occurs? If not do you have other suggestions as to how I might get round this problem? Thanks in advance.

Share this post


Link to post
Share on other sites
Advertisement
If you're on MSVC, you can use

#pragma init_seg

to put your code in a specific initalization segment. The memory manager that I use puts itself into init_seg(compiler), and I haven't had any issues with it failing on static initalizations.

However, the only portable solution would be to completely avoid static initalization, perfering initlization on first use, or other workarounds.

Share this post


Link to post
Share on other sites
Thanks bobofjoe, that's exactly what I was after, I'll give it a go and see if I can find equivalent pragmas for other platforms.
Personally I try to avoid static initialisation, and like you say it is the only truly platform independant solution, but I work in a team and I'd rather avoid imposing such limitations... everyone has their own way of doing things.

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.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!