Thank you for the reply.
Most compilers have the option to increase heap space, although I was unable to find it after a quick glance of Visual Studio's settings. Unless you explicitly tell the compiler to change the amount of heap space and unless the OS honors the request, the code you wrote will either not compile or will crash hard
Would making one call to malloc for a gigabyte avoid heap space issues? FWIW Visual Studio 2015 didn't have an issue running my example.
Even if it worked, you'd be left with a GB of characters, not a GB of free space. Sure, you could access that space for other uses through clever pointer tricks, but God help you during debugging!
The intent is its a byte not a character, perhaps using int8_t would make that more clear.
It sounds like you want to make your own memory manager. That can be done, and often is, but never via the heap.
How would you do it without the heap?
Truthfully, with smart pointers and containers, the reasons for creating a memory manager are getting fewer and fewer. If this is what you're after, you should Google some examples. It is a non-trivial task.
My application (mostly) just needs frame allocators (AKA pointer bump allocators). The overall architecture, using a frame allocator, is simple:
1. Load resources that will always exist in memory at app start.
-> Remember the byte offset within the allocator at this point.
2. Load a level and all the resources that are needed for it.
3. When the level unloads, then restore the allocator back to the byte offset saved earlier and continue from step #2.
I'm more or less wondering if the .data segment is any different from the applications heap space. As in, is it less optimized, constantly paging, is this not portable, etc...? Obviously, if your not sure how much space you'll need until runtime, then you need to use malloc and friends. But in my case, I know how much space I need.