On 27/12/2013 07:27, Quoth Eugenio Bargiacchi:
However, if my problem can be solved by simply destroying the map before unloading all shared libraries, I am content. What I am most concerned about is whether every single time a module destroys a value it needs to somehow give control back to the module that created it so that it can destroy it, or if that is handled automatically when a destructor is called.
If the type explicitly defines a non-inline destructor, then it will actually call the destructor in the module. If you use an inline destructor or compiler-generated destructor then it might or might not depending on how the compiler was feeling at the time. The peril doesn't end there though. Even if you guarantee that it will call the destructor in the module, two different modules might not have the same memory allocator (especially if there's a chance they might be compiled with different compilers or even different versions), and weird things may happen if you allocate memory in one module and try to deallocate it in another. Some smart pointer objects (eg. shared_ptr) let you provide an explicit "deleter" function that gets called when the pointee needs to be destroyed, which can help mitigate some cases of objects passing between modules. But there still be dragons.