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 acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk