On 10/14/2016 11:43 AM, Daniela Engert wrote:
Am 13.10.2016 um 20:01 schrieb Edward Diener:
On 10/13/2016 1:36 PM, Daniela Engert wrote:
Am 13.10.2016 um 00:58 schrieb Edward Diener:
4) Use neither, you roll your own shared pointer-like functionality
The last library that I designed also for use by external customers, I rolled my own 'handle' type which is completely opaque to users which see just a struct with no more than one single uintptr_t member. Under the covers it is a boost::intrusive_ptr. The idea is to prevent accidental misuse and not to force users taking a dependency on boost. The library itself is taking advantage of any boost functionality it sees fit.
OK, thanks ! I assume that actual implementation code for your opaque type is in the built portion of a non header-only library.
Exactly! These 'handles' refer to USB devices which may come and go. There's a 'weak handle' as well, which doesn't give access to a device but rather observes it's presence state and it's unique device instance name only. Users may construct handles only in the empty state, actual references to devices are handed out to client code by the library. And as long as there are any outstanding non-empty handles in client code, the DLL is kept locked in memory. Otherwise it may be unloaded from the process thereby freeing any remaining resources still lingering in the kernel's driver stack.
Ciao Dani
OK, thanks ! Many libraries are header-only libraries so the technique you describe would be more difficult, if not impossible, in such cases.