VAR, STL and a custom allocator?

I’m looking into memory management techniques for use with VAR allocated memory. I think I’d like to stick with the STL - has anyone tried using STL with custom allocators to manage VAR memory?

Don’t go there. STL typically does all its memory management in-line, i e it would use the VAR memory for storing information ABOUT the memory, too.

Not to mention allocators are not portable between different STL implementations. A real problem, that.

Because only vertex data goes into VAR memory, and you can live with some rounding up of size, I suggest chopping your VAR in 1k sized chunks, and storing a byte per chunk in regular memory to store whether the page is in use (non-0) or not (0). The byte then contains the size of the allocation you use out of the VAR memory in chunks, which allows you up to 255 kB single allocations.

If you don’t need to deallocate single chunks, or can pass in the size when you deallocate, you can scale down to a single bit per page. If you load everything in a level at once, you can just allocate by moving a “top” pointer up as you allocate, and then re-set it to the bottom when the next level starts and you start re-loading stuff.

Hope this gives some ideas about how to allocate and manage VAR memory.

jwatte is probably correct in cautioning you, but I had the same idea recently (just bought Effective STL by Scott Meyers) so I won’t add any more.

One thing that would be nice of an STL VAR allocator is that you can have one allocator class that is responsible for allocating memory for all your containers. The best thing is probably just to make your own global VAR memory allocator to encapsulate VAR memory access, and have the STL VAR allocator use that. Granted, it’s probably not worth it in the end.

One place, however, where the STL VAR allocator would very likely work is for std::vector. Typically, what it stores is a bunch of pointers (beginning of vector, end of vector, end of memory capacity) to some allocator-allocated memory. Granted, this sort of thing has the tendency to be platform and implementation dependent (the allocator might just get ignored, and it certainly does for certain containers in certain implementations of STL). You might be able to sleep better if you fixed on a standard version of STL, such as STLport (which you might want to anyway, for different reasons) but then again you might be just setting yourself up for an even bigger fall.

Sorry for my pitiful advice, but as you can tell, I’ve all but abandoned the idea already. I love STL, but sometimes you just have to let go. You can write your own custom STL-compatible container and then you could still use the great STL algoirthms, although I don’t know why you’d want to in VAR memory.