Hi, I have recently started a project, where I want to use dll's for modularity/plugins and code re-use. In earlier projects I've used boost::smart_ptr to ensure that objects wouldn't be deleted, before "everyone" was finished using them. But the problem in this project may arise in the fact that operator delete will only be called, once a smart_ptr is no longer in use. If the smart_ptr is allocated in the exe and the dll wants to use it longer than the exe (ie. it goes out of scope in the exe, while it still remains in-scope in the dll), it will be deallocated in the dll, right? As of my understanding that's no good ('new' in exe, 'delete' in dll and vice versa) and can cause problems any given day, which is why I seek a new solution to this problem. I'm just curious to know how such this problem might be solved and still ensure the safety of smart pointers? Any comments and/or thoughts will be greatly appreciated :) My own thoughts on this subject... boost::weak_ptr's seems to eliminate the problem if I have a manager of some sort to create/delete the objects based on the factory pattern (so that other deriatives of a specific class can made), contain the smart pointers within the manager and then delegate weak_ptr's to the rest of the program. My current sub-goal of the project who needs a solution to this problem is my little kernel who's tasks could either be created/deleted in the exe or dll's, so naturally I want to get this solution somewhat right from the start.

Quote:Original post by Evil Steve
If both your DLL and EXE link to the DLL version of the CRT (which it does as standard in VC2005), then there's no issue in allocating memory in the EXE and freeing it in the DLL, or vice versa. That's probably your best solution.

That sounds like a good solution, I'll link with that straight away :D
I've located the library, libcrtdll.a, which must the one you're talking about, so linking is not an issue.
But if I link this file to my project, am I then guaranteed that my exe/dll will make use of the dll version or do I have to enable some preprocessor steps to make that happen?

Quote:Original post by Nitage
You could also have the smart pointers use a custom deleter, which calls a function in the dll which in turn calls delete from the dll.

Yup, that would also be an option, but wouldn't that essentially be the same as the first suggestion with some indirect calls to reach deallocation if I don't need the extra layer? (although this might be a good idea if I ever need a simple memory manager that only collected statistics, not allocated/deallocated manually)

Thanks for answers so far ;)

Oh sorry, I forgot to write GCC ;)