Use a smart pointer that understands the necessary protocol.what about pointers to objects created inside DLL's?
Soma
Use a smart pointer that understands the necessary protocol.what about pointers to objects created inside DLL's?
Soma
But most smart pointers don't care what module they are in when they clean up. I have not encountered any thus far that take any considerations prior to cleaning up save the ref count. It would be nice if they did understand the protocol but alas most do not. So if you return a pointer from a DLL you must be careful to put in mechanisms to guard these pointers so that when it is time to clean up the guard mechanism in place understand that the pointer must be cleaned up in the DLL that created it.Use a smart pointer that understands the necessary protocol.
It is not safe at all. Pretty much guaranteed heap corruption at some point.I don't think it's safe to delete a pointer that was allocated in another module like a DLL.
Last edited by VirtualAce; 01-20-2011 at 05:30 PM.
O_oI have not encountered any thus far that take any considerations prior to cleaning up save the ref count.
I can introduce you to dozens. Literally. In fact, I can introduce you to an infinite number considering that some of them are templates accepting templates as arguments.
Consider some of the smart pointers from Loki or Boost. Many, if not all by now, allow you to pass a specific function to use use as the cleanup routine. In other words, if the protocol is "call the member function `void class_type::kill(void)'" you simply code a routine that does exactly that and pass it along to the smart pointer with the raw pointer.
Some of Microsoft's own supplemental material has offered two that work specifically with some COM protocols taking a pair of functions to use on decrease/increase reference count operations.
All of this is of course besides the point, it doesn't matter what bizarre protocol a given DLL may demand, a smart pointer that guarantees the protocol will be followed at prescribed points is still far superior to any programmer attempting to do it by hand even if the smart pointer must be coded for this purpose.
If you happen to be worried about a given coder not properly using the API and the smart pointer correctly you could also wrap the relevant factory API in client code and return the properly crafted smart pointer instead.
This is true whether of not you associate the raw pointer with a smart pointer. The smart pointer just provides some guarantees that it happens at the prescribed places without programmer intervention.So if you return a pointer from a DLL you must be careful to put in mechanisms to guard these pointers so that when it is time to clean up the guard mechanism in place understand that the pointer must be cleaned up in the DLL that created it.
It can be much worse that that. If the relevant deallocating protocol is not followed the destructor may also not be called. That can cause all sorts of immediate problems.It is not safe at all. Pretty much guaranteed heap corruption at some point.
Soma
That comes down to how you define the interface to the DLL (i.e. what functions it exports, and the way users of the DLL are required to behave).Originally Posted by cpjust
The approach I use is that no pointers created inside the DLL are ever passed outside the DLL. That way, the DLL manages every object it creates internally.
That means, if a function outside the DLL requires data from inside the DLL, that it must provide and manage an appropriate buffer for that data to be copied to.
The trade-off of this approach is performance as all data must be copied in order to cross the DLL boundary, rather than the DLL simply exposing a pointer to its internal data.
However, there is no need for a "guard" protocol at all - if a caller provides a pointer, the callee knows is not allowed to deallocate.
To handle third-party DLLs then I simply write another DLL to act as an intermediary (eg a facade). That works for factories that are in a DLL.
It's a moot point if the overall application has some performance requirement that makes this approach prohibitive - if performance is that critical, I wouldn't explicitly be using any DLLs in the first place.
I don't claim this is perfect, but I find it works. It is certainly possible to find corner cases where it won't work, but the trick is avoiding or disallowing corner cases in the first place.
Last edited by grumpy; 01-21-2011 at 02:27 AM.
