Allocate Memory

[dedndave]

if HeapAlloc (et al) returns a non-zero pointer, the memory was allocated

[rrr314159]

MichaelW:

Or you can just use the linker /STACK:reserve[,commit] option to make the stack whatever size you need

The only time I use the stack for largish mem blocks is in threads created by my main process. I don't think this linker option affects thread stack size? Can't seem to find answer on net. Actually I think u can allocate stack when u create the thread, but probing hasn't been too much of an issue ...

I tried uninitialized data for threads but that doesn't work so well. U have to make sure multiple threads aren't using data too near each other; they can "step on each other's toes", I guess because they lock a larger block than they write. Stack memory is usually already in cache and therefore is faster (so to speak), and of course it's much faster to allocate (0 nanoseconds). 

The reason I said it requires "more than usual care" is not any of that, rather that the stack is also being used for call/return and function parameters (of course), so ... but I can't cover all these points in a short post - or even a long one!

Hutch:

RE: GlobalAlloc(), there is another term for deprecated, its "stable" which means Microsoft will not stuff it up any longer.

Yes, now that u mention it - you're right! The heck with getting heap handles - I'm going back to GlobalAlloc (for main process). MS can deprecate my elbow, if they want.  :lol:

[jj2007]

The one thing I dislike with the linker /STACK:reserve[,commit] option is that you can't just post a snippet here, you'll have to explain how exactly the linker commandline has to be set etc - usually a messy action, especially but not only with new members. Using *Alloc is simpler.

But...
/stack:1980000000      ; stack pointer will be e.g. 1984298892
...works as expected. The higher the commit value, the higher the private working memory used initially - for a committed 1980000000 it is around 4.7MB on my Win7-64 machine; for the same stacksize but no commit value, it is only 932 kBytes. The management of committed pages costs a bit of space...

[MichaelW]

For CreateThread you must specify the stack size, and you can choose for it to be the executable stack size. A large commit is a bad idea if you're working under conditions where there are memory constraints, but for the typical conditions (at least for me), where you're not doing heavy multitasking, what does it matter? KISS, get the necessary memory by the easiest possible route.

But then again, maybe my simplistic use of a computer is not typical.

[rrr314159]

MichaelW

... maybe my simplistic use of a computer is not typical

Well, it's typical for me, so you're in bad company! Hutch makes a lot of service-type programs that people will run along with other software, so he (admirably) is careful with his bytes. In another routine (posted in the laboratory), to tokenize a text file, he counts the number of lines first, then allocates exactly that many dwords for pointers; whereas I would figure 100K ought to do it, so make it a meg and we're all set. If I ever do post a service-type routine, for general use, I'll try to emulate him.

[jj2007]

In another routine (posted in the laboratory), to tokenize a text file, he counts the number of lines first, then allocates exactly that many dwords for pointers

That was a nice thread indeed, see here. There is also the option (used in Recall) to allocate for the pointers sizeoffile/2 (=worst case, all crlf), and to reallocate the pointer table at the end.