I understand that memory allocations made in one dll then subsequently free\'d in another can cause all sort of problems, especially regarding the CRT. These sorts of probl
Ironically enough, the Adobe Source Libraries has a adobe::capture_allocator class that was written specifically with this kind of DLL safety in mind. The way it works is to capture the local new
and delete
at this point it is instantiated, and to carry them both around for the lifetime of the object. (See adobe::new_delete_t for details on how it does this, especially the implementation here.) Deallocations take place with the captured delete
routine, guaranteeing that no matter where you are you are deleting with the proper delete
.
You can see capture_allocator
used throughout the version_1 types in the Adobe Source Libraries, such as adobe::any_regular_t and adobe::copy_on_write. capture_allocator
should be compatible with all STL container types as well.
Update: capture_allocator
is not standard-compliant because it retains state. This should not be a big hindrance to its usability, but it does mean its use is not guaranteed to work with standard-compliant containers.