How to stop STL containers from calling call overloaded new

The problem here is as soon as you override the global news and deletes you're making your new versions the default. They're the court of last resort, if they fail the runtime library won't step in with another version: The new/delete you define will prevent the versions that come with your runtime library from even being linked.

Anyway, Here're three suggestions:

- Create a custom allocator and let the map use it. You could use malloc and free (ugh, spit, spit, ugh) or operating system features (double ugh, barf, barf, heave) to implement it. Allocators are a bit of a fiddly interface but it can be done.

- Turn the problem on it's head - don't override global new and delete. Instead override them on a class by class basis, which will give you a lot more control and perhaps efficiency as you can implement heaps or pools for different sized classes.

- Use a static data structure that doesn't resize itself. A sorted fix sized array of objects means you can access elements as fast using a binary search as a std::map. You'll have to profile your app to try and get a handle on what's the correct size for you.

My advice would be don't override any of the global news and deletes. You end up fiddling with pointers and "things man was not meant to know." Overriding anything global is a bit like having global state in a program - a pain in the bum to unit test. If you need to customise stuff try using class specific new/delete or a custom allocator for for collections.

You could give your new new a new name, such as my_new.
Then in the files where you want to use your own new use a macro...

#define new my_new

I think that would do it.

Technically you could create a library containing two functions default_new and default_delete, which internally call the default functions. Since you'd build the library without overloaded new/delete, it should work all right.

However, I suspect the performance loss you incur from calling upon a library may eat up much if not all of the gain you hoped to win from using a memory pool in the first place...

The better solution would be to not globally overload new/delete. Memory pools are most useful for lists and maps, so if you just provide special allocators for these that should cover most of your performance problems.