Quote:
Because every modern compiler supports COM, which relies on virtual tables. And you don't need to use COM in your application, I mean, you can create your own interfaces without inheriting IUnknown and you will be able to use them across dll boundaries.
It is a simple rule. If you allocate in the DLL, de-allocate in the DLL. Whatever constructs make this possible will work. Whatever constructs do not follow this will not work. Memory that is managed inside the DLL should not be exposed outside of the DLL unless there is a mechanism in place that allows clients to use said memory safely. Safely as in they are not allowed to clean it up. Pointers into DLLs work perfectly but the danger is that a client will call delete on the pointer. Obviously this would be stupid to do but the DLL should provide some abstractions that make this harder to do if it is going to provide public methods that return pointers to memory in the DLL.