Re: [boost] intrusive_ptr ?

From: Jim Grandy (jgrandy_at_[hidden])
Date: 2002-11-25 19:05:14

From: "Peter Dimov" <pdimov_at_[hidden]>
> From: "Jim Grandy" <jgrandy_at_[hidden]>
>> On 11/25/02 10:06 AM, "Peter Dimov" <pdimov_at_[hidden]> wrote:
>> 
> [...]
>>>> This would allow one to use this style of code:
>>>> 
>>>>     intrusive_ptr<OpaqueRefCountedString> s =
>>>>         dont_addref(CopyMenuTitle(m));
>>> 
>>> intrusive_ptr<OpaqueRefCountedString> s = CopyMenuTitle(m);
>>> s->Release(); // or however it's spelled
>>> 
>>> ?
>>> 
[...]
>> Additionally, this idiom is so common in certain OS's that a clear
> one-line
>> solution would be preferable. Perhaps "reuse_ref" would be a better choice
>> than "dont_addref"?
> 
> OK, here is the one-line solution:
> 
> template<class T> intrusive_ptr<T> dont_addref(T * p)
> {
>   intrusive_ptr<T> pt(p);
>   intrusive_ptr_release(p);
>   return pt;
> }
> 
> To expand on that a bit, yes, I considered providing a "no addref"
> constructor, and decided against doing so. Constructing an intrusive_ptr
> without an addref is indeed a common task when using some C-like interfaces
> (COM) but in my experience, once you start using a smart pointer to talk to
> these libraries, earlier or later you find yourself wrapping it in a smart
> pointer-friendly, C++ style interface, and at that point the "no addref" is
> really an implementation detail. The users of _your_ wrapped interface
> should never need the "no addref" option.
> 

I'm not sure this addresses the efficiency concern I raised earlier. You
still incur an extra addref and release call inside your C++ wrapper
interface for every API call, which can easily be an unacceptable
performance hit. Since intrusive_ptr is hermetically sealed, there is no way
around the unnecessary two calls (short of adding a constructor).

Sort of as an aside, in projects I've worked on we've rarely had the
opportunity to create C++ wrappers for absolutely everything. Instead, we
tend to build wrappers for common abstractions and fill them in as we go.
Not very structured, I know, but a pragmatic approach given the speed with
which a lot of APIs change. In this sort of environment, you don't have a
designated person designing the C++ wrappers and throwing them over the
transom to the rest of the team; instead, members of the team participate in
wrapper building as they have the time and the inclination. This makes the
kind of code discussed above much more "visible" to the group.

Anyway, intrusive_ptr is a small enough (and simple enough) class that I
don't mind copying it and making my own version with the desired extra
feature.

thanks,

jim