c++ - How to control memory allocation strategy in third party library code? -

previous header: "must replace global operators new , delete change memory allocation strategy in third party code?"

short story: need replace memory allocation technique in third-party library without changing source code.

long story:

consider memory-bound application makes huge dynamic allocations (perhaps, available system memory). use specialized allocators, , use them everywhere (shared_ptr's, containers etc.). have total control , power on every single byte of memory allocated in our application.

also, need link against third-party helper library. nasty guy makes allocations in standard way, using default operators new, new[], delete , delete[] or malloc or else non-standard (let's generalize , don't know how library manages it's heap allocation).

if helper library makes allocation big enough can hdd thrashing, memory fragmentation , alignments issues, out-of-memory bad_allocs , sorts of problems.

we can not (or not want) change library source code.

first attempt:

we never had such unholy "hacks" in release builds before. first test overriding operator new works fine, except that:

• we not know gotchas wait in future (and awful)
• our users (and our allocators) have allocate same way do

questions:

1. are there ways hook these allocations without overloading global operators? (local lib-only hooks?)
2. ...and if don't know uses: malloc or new?

3. is list of signatures complete? (and there no other things must implement):

   void* operator new (std::size_t size) throw (std::bad_alloc); void* operator new (std::size_t size, const std::nothrow_t& nothrow_value) throw(); void* operator new (std::size_t size, void* ptr) throw(); void* operator new[] (std::size_t size) throw (std::bad_alloc); void* operator new[] (std::size_t size, const std::nothrow_t& nothrow_value) throw(); void* operator new[] (std::size_t size, void* ptr) throw();  void operator delete (void* ptr) throw(); void operator delete (void* ptr, const std::nothrow_t& nothrow_constant) throw(); void operator delete (void* ptr, void* voidptr2) throw(); void operator delete[] (void* ptr) throw(); void operator delete[] (void* ptr, const std::nothrow_t& nothrow_constant) throw(); void operator delete[] (void* ptr, void* voidptr2) throw(); 

4. something different if library dynamic?

edit #1

cross-platform solution preferable if possible (looks not possible). if not, our major platforms:

• windows x86/x64 (msvc 10)
• linux x86/x64 (gcc 4.6)

edit #2

almost 2 years have passed, few os , compiler versions have evolved, curious if there new , unexplored in area? standard proposals? os-specifics? hacks? how write memory-thirsty applications today? please share experience.

ugh, sympathy. going depend lot on compiler, libc, etc. rubber-meets-road strategies have "worked" varying degrees in past (/me braces downvotes) are:

• the operator new / operator delete overloads suggested -- although note compilers picky not having throw() specs, want them, want them new not delete, etc (i have giant platform-specific #if/#elif block of 4+ platforms we're working on now).
• also worth noting: can ignore placement versions, don't allocate.
• look @ __malloc_hook , friends -- note these deprecated , have thread race conditions -- they're nice in new/delete tend implemented in terms of malloc (but not always).
• providing replacement malloc, calloc, realloc, , free , getting linker args in right order overrides take place (this gcc recommends these days, although i've had situations impossible do, , had use deprecated __malloc_hook) -- again, new , delete tend implemented in terms of these, not always.
• avoiding standard allocation methods (operator new, malloc, etc) in "our code" , using custom functions instead -- not easy existing codebase.
• tracking down library author , delivering savage beating polite request or patch change library allow specify different allocator (it may faster doing yourself) -- think has lead cardinal rule of "client specifies allocator or allocation" libraries write.

please note not answer in terms of standards should happen, experience. i've worked more few buggy/broken compilers , libc implementations in past, ymmv. have luxury of working on "sealed systems", , not being worried portability specific application.

regarding dynamic libraries: i'm in bit of pinch in regard myself; our "app" gets loaded dynamic .so , have pretty careful pass delete/free requests default allocator if didn't come us. current solution cordon off our allocations specific area: if delete/free within address range, dispatch our handler, otherwise default... i've toyed (horrors) idea of checking caller address see if it's in our address space. (the probability of going boom increases such hacks, though.)

this may useful strategy if process lead , you're using outside library: tag or restrict or otherwise identify own allocs somehow (even going far keep list of allocs know about), , pass on unknowns. of has ugly side-effects , limitations, though.

(looking forward other answers!)