How to Control Memory Allocation Strategy in Third Party Library Code

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

Ugh, my sympathy. This is going to depend a lot on your compiler, your libc, etc. Some rubber-meets-road strategies that have "worked" to varying degrees for us in the past (/me braces for downvotes) are:

• The operator new / operator delete overloads you suggested -- although note that some compilers are picky about not having throw() specs, some really want them, some want them for new but not for delete, etc (I have a giant platform-specific #if/#elif block for all of the 4+ platforms we're working on now).
• Also worth noting: you can generally ignore the placement versions, they don't allocate.
• Look at __malloc_hook and friends -- note that these are deprecated and have thread race conditions -- but they're nice in that new/delete tend to be implemented in terms of malloc (but not always).
• Providing a replacement malloc, calloc, realloc, and free and getting your linker args in the right order so that the overrides take place (this is what gcc recommends these days, although I've had situations where it was impossible to do, and I had to use deprecated __malloc_hook) -- again, new and delete tend to be implemented in terms of these, but not always.
• Avoiding all the standard allocation methods (operator new, malloc, etc) in "our code" and using custom functions instead -- not very easy with existing codebase.
• Tracking down the library author and delivering a savage beating polite request or patch to change their library to allow you to specify a different allocator (it may be faster than doing this yourself) -- I think this has lead to a cardinal rule of "client always specifies the allocator or does the allocation" with any libraries I write.

Please note that this is not an answer in terms of what the standards say should happen, just my experience. I've worked with more than a few buggy/broken compilers and libc implementations in the past, so YMMV. I also have the luxury of working on fairly "sealed systems", and not being all that worried about portability for any specific application.

Regarding dynamic libraries: I'm currently in a bit of a pinch in this regard myself; our "app" gets loaded as a dynamic .so and we have to be pretty careful to pass any delete/free requests back to the default allocator if they didn't come from us. The current solution is to just cordon off our allocations to a specific area: if we get a delete/free from within that address range, we dispatch to our handler, otherwise back to the default... I've even toyed with (horrors) the idea of checking the caller address to see if it's in our address space. (The probability of going boom increases with such hacks, though.)

This may be a useful strategy even if you are the process lead and you're using an outside library: tag or restrict or otherwise identify your own allocs somehow (even going so far as to keep a list of allocs you know about), and then pass on any unknowns. All of this has ugly side-effects and limitations, though.

(Looking forward to other answers!)

How to avoid thrid party lib(no source codes) to allocate memory from physical memory?

For a regular C++ program or library there's no such thing as "allocating physical memory" or "allocating memory from hard disk" in Windows. All "normal" allocation requests are served by virtual memory. It is up to the operating system to decide which virtual memory region will reside in physical RAM and which will reside on disc at any given moment. Neither your program, not the third party library has any control over this.

In other words, the "problem" you seem to describe does not really exist. In a properly designed OS based on virtual memory, the physical RAM is always fully occupied. Unoccupied RAM is wasted RAM - this is the governing principle behind this. That means that the concept of "saving physical RAM" does not really exist in such OS: the physical RAM is always 100% occupied anyway.

In order to make data stored in virtual memory the OS first has to make sure that data is loaded into physical RAM. For this reason, any library that uses memory will have its data loaded inyto physical RAM, regardless of whether you want it or not. Otherwise that third party library simply won't be able to function at all.

Best way for memory allocation for a custom edit control?

I created a dynamically allocated c -style string class member(char*
szClassName). Then I initialized it in an initializer list as
szClassName("name of class").

No, you didn't. First, you created A POINTER to a char. Then you initialized the pointer with the address of the static literal string constant "name of class" (which the compiler would have allocated in the read-only data segment of the object file).

So, when your destructor called delete szClassName, you were trying to deallocate a block of memory in the read-only data segment rather than one that had been dynamically allocated with new (hence the error).

---

Related Topics