Take the 2-minute tour ×

It's been bothering me for a while but I didn't find any good resource about this matter. I have some global variables in my code. It's obvious that they are initialized in some order but is the memmory needed for all those objects reserved before any initialization take place?

here is the simple example of what might go wrong in my code and how I can use the answer:

I had a map<RTTI, object*> objectPool which holds samples of every class in my code, which i used to load objects from a file. To create those samples I use some global variables just to introduce class instance to objectPool. But sometimes those sample instances were initialized before ObjectPool itself. And that generated runtime error.

To fix that error I used some delayed initializer map<RTTI,object*>* lateInitializedObjectPool;. Now every instance first check if the objectPool is initialized and initilize it if not and then intoduce itself to the object pool. It seems to work fine but I'm worried if even the memmory needed for object pool pointer is not reserved before other classes begin to introduce themselves and that may cause access violation.

share|improve this question
AFAIK, memory for global objects is allocated on stack, which means the moment the application starts. Correct me if I'm wrong. –  Violet Giraffe Jun 28 '11 at 10:02
@Violet: not right... the stack's just for local variables normally, though I guess the implementation's free to do something unusual if it wants to.... –  Tony D Jun 28 '11 at 10:06
@Violet: I'm pretty sure global objects don't get memory from the stack. Indeed, I know for a fact at least one compiler platform where this certainly does not happen, and I'd be surprised if there were many where it did. –  Nicol Bolas Jun 28 '11 at 10:07
Global objects are statically allocated, i.e. allocated at load-time. Initialization is a different, higher-level matter, see the answers. –  Kerrek SB Jun 28 '11 at 10:10
There is a common misconception that globals are allocated in the stack, while I see that this has already been cleared out, a simple way of thinking about it so that it is easy to remember is that each thread in a program has a different stack, but globals (I am not talking about thread-local storage) are shared across the different threads. If you keep in mind the fact that different threads have different stacks, the fact that globals cannot be stack allocated is a natural consequence. –  David Rodríguez - dribeas Jun 28 '11 at 11:25
show 3 more comments

3 Answers

up vote 6 down vote accepted

Variables declared at namespace scope (as opposed to in classes or functions) have the space for the objects themselves (sizeof(ObjectType)) allocated by the executable (or DLL) loader. If the object is a POD that uses aggregate initialization, then it typically gets its values set by having the linker write those values directly into the executable and the exe's loader simply blasting all of those into memory. Objects that don't use aggregate initialization get their values zeroed out initially.

After all of that, if any of these objects have constructors, then those constructors are executed before main is run. Thus, if any of those constructors dynamically allocate memory, that is when they do it. After the executable is loaded, but before main is run.

share|improve this answer
So if I got your answer you mean a program has 3 phases : memory initilizing for global variables -> premain function calls -> main function call? which means all the premain function calls are happening after all of the static memory allocations? –  Ali.S Jun 28 '11 at 10:13
@Gajet: Yes, but remember: just because memory was allocated doesn't mean that those objects have been initialized (constructed). They're just dead memory until they get a constructor. If they are PODs, then that's fine, but if they are actual objects with constructors that get called, then you can't touch them. And the order of global object initialization is undefined. –  Nicol Bolas Jun 28 '11 at 10:27
And I would just add that the order of constructor calls before main is undefined, which can lead to all sorts of nifty bugs (parashift.com/c++-faq-lite/ctors.html#faq-10.14) –  Gilad Naor Jun 28 '11 at 11:01
@Gilad The order of constructor calls is defined within a single translation unit. The order of the translation units isn't specified, however. –  James Kanze Jun 28 '11 at 11:18
@James thanks for the correction. –  Gilad Naor Jun 28 '11 at 11:31
add comment

There's usually separate memory areas for variables that the compiler:

  • worked out initially contain all 0s - perhaps with a pre-main() constructor running to change their content
  • predetermined have a specific non-0 value, such that they can be written in a pre-constructed form into the executable image and page faulted in ready for use.

When I say a "separate memory area", I mean some memory the OS executable loader arranges for the process, just as per the stack or heap, but different in that these areas are of fixed pre-determined size. In UNIX, the all-0 memory region mentioned above is commonly known as the "BSS", the non-0 initialised area as "data" - see http://en.wikipedia.org/wiki/Data_segment for details.

share|improve this answer
add comment

C++ has the notion of "static storage duration". This refers to all kinds of variables that will take up a fixed amount of space during the execution of a program. These include not just globals, but also static variables at namespace, class and function level.

Note that the memory allocation in all cases can be done before main, but that the actual initialization differs. Also, some of them are zero-initialized before they're normally initialized. Precisely how all this happens is unspecified: the compiler may add a hidden function call, or the OS just happens to zero the process space anyway, etc.

share|improve this answer
add comment

Your Answer


