Boost logo

Boost :

Subject: Re: [boost] Curiousity question
From: Edward Diener (eldiener_at_[hidden])
Date: 2016-10-14 13:42:15

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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at