By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
458,088 Members | 1,501 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 458,088 IT Pros & Developers. It's quick & easy.

cleaning up in a different library

P: n/a
It is sort of open-ended question, thus pardon the clarity herein.

Let's say I have library (dll, .so, doesn't matter really), and I pass
it a pointer, to Foo (Foo *). How should that library know to clean up
after, what is the best design of this sort of a thing? I usually go
with two cases:
a) I pass it in a smart pointer
b) as a raw pointer

Let's say that b is mandatory, what should the strategy, or common
design be like?
Thanks

Aug 23 '07 #1
Share this Question
Share on Google+
1 Reply


P: n/a
"Alf P. Steinbach" <al***@start.nowrote in news:13cpl807inhj498
@corp.supernews.com:
* puzzlecracker:
>It is sort of open-ended question, thus pardon the clarity herein.

Let's say I have library (dll, .so, doesn't matter really), and I pass
it a pointer, to Foo (Foo *). How should that library know to clean up
after, what is the best design of this sort of a thing? I usually go
with two cases:
a) I pass it in a smart pointer
b) as a raw pointer

Let's say that b is mandatory, what should the strategy, or common
design be like?

Cleanup responsibility should never implicitly be passed across module
boundaries. Pass a cleanup function explicitly. That function can of
course be a class member if proper care is exercised (e.g. for Windows
dynamic libraries it should not be inline, because you want the executed
code to be in the original allocating library).
It turns out that at least under Windows and I believe everywhere, that if
you have virtual destructor, the deallocation always happens in the correct
place. Of course this mandates a vtbl or some such. Otherwise, as Alf
mentioned, you should provide a function to do the cleanup in the proper
module (Note: inline functions won't this).

joe
Aug 23 '07 #2

This discussion thread is closed

Replies have been disabled for this discussion.