When is the best time to initialize and/or allocate memory memory?

[WillofIrony]

The examples of assembly language for windows that I have seen so far do not require extensive, if any, initialisation of static memory. I am contemplating a program that will require the run-time initialisation of a a fairly large static byte array (its a maze described by randomly generated data). I am assuming that this will need to be completed before the message loop is entered in winmain. However, is it possible/advised to perfom this before the createwindow call? All the examples I have seen tend to begin with registering the class then creating the window - is it imperitive that these are the first actions performed by a windows program?

A second, more general question: were this array to be not static i.e. require allocation of memory, could this memory be allocated and initialised before the creation of the main window? I understand that no input/output (keyboard, mouse or graphics could be performed before the creation of the window.

Thanks in anticipation.

Michael

[Tight_Coder_Ex]

Anything that doesn't require user interaction in the way of keyboard or mouse can be done anytime in the program.  At times there is lots of processing going on even after the main window has been closed and the user can no longer interact with application.  ExitProcess is just one such example.

Without knowing exactly how large the file is or details about your needs it's pretty hard to speculate any sort of scenario. but a rule of thumb is whenever there is a large amount of information static or dynamic, it's better to create a memory block and then read it in from a file or resource.

[Tedd]

You can initialise your memory/arrays whenever it makes sense for you to do so - there's no particular limit or rule.

For generating the maze, a good time do that is in a function called from within the WM_CREATE handler - which is before the window actually shows, but has been fullly created. This gives you the option of returning -1 to indicate failure (not enough memory, file not found, etc) and cause window creation to fail (CreateWindow will return NULL and you can exit cleanly.)

That said, it's only my personal preference. You could do it before calling CreateWindow, or even before RegisterClass..
And you can allocate memory whenever you decide too :wink

[WillofIrony]

@ Tedd

Thanks for the WM_CREATE heads up, I like the idea of returning a value to indicate success or failure..

@Tight_Coder

Thanks for the advice. Unfortunately, the data are generated run-time (and differently on each run) so I cannot save them beforehand.

[Mark Jones]

Another thing to consider, if applicable, would be the use of threads. How about spawning a second (non-blocking) thread AFTER the window has been drawn. This gives the instant satisfaction of seeing the window open without having to wait. Plus, if the program was ran on a very old machine, or there was a problem calculating the bytes (it locked up) the program could still be closed (WM_CLOSE message sent to WndProc, in there terminate the 2nd thread.)

[hutch--]

Micheal,

I basically agree with Tedd's comments where you allocate in whatever context you like. The type of thing I would keep in mind is the scope of where you allocate memory so you can safely deallocate it. Just for example if you ned an array of zero initialised memory of more or less any size, use GlobalAlloc() with the zero flag set. If you need to rezero it all you can just whack it with a memfill procedure on a needs basis.

With static allocation, unless you specifcally need initialised values with something like a table, use the UNinitialised data section as it keeps you file size down.

If I need a single block of memory for the entire life of the application I allocate it right at the start of the app after the entry point label (typically "start:"), call the first procedure ("main" or similar) and deallocate it on exit once that procedure has terminated. Often its useful to create a memory handle or pointer in the .DATA? section so that you can allocate the memory where you need it using that handle as a reference to the memory.

You can then deallocate it anywhere you like but always make sure you DO deallocate it properly so you don't end up with a memory leak.

[ossama]

hello, sorry , it may be out of this topic discussion,
i am allocating the meory using this function :
CoTaskMemAlloc
and free it with
CoTaskMemFree

i am using these functiuon all the time in my programs, instead of using the other memory functions,
is it okay to use this function?

[hutch--]

ossama,

They are fine as long as they do the job you need. When you have time read up on others like VirtualAlloc, HeapAlloc and the old GlobalAlloc as long as you used the fixed flag. The idea is to pick the allocation strategy you need from the range available while remembering that there is a lot of overlap with different memory functions.