C++Talk.NET

Andrei Alexandrescu (See · Guest

Actually, after that whole discussion about shared_ptr, I've had an idea
on making shared_ptr support intrusive reference counting directly
without an extra memory allocation.

So, shared_ptr currently holds two pointers in-situ: one pointer to the
pointee object, and one to the bookeeping structure sp_counted_base. A
problem is that sp_counted_base (actually a subtype thereof) must be
allocated dynamically.

So I was thinking, let's imagine a class Widget wants to implement
intrusive refcounting. So what it does it inherits sp_counted_base itself:

class Widget : public sp_counted_base {
...
};

Now, when creating a shared_ptr<T>, let's say shared_ptr's constructor
looks to see whether T inherits sp_counted_base. If it doesn't, then
it's business as usual and a second dynamic allocation is performed.

But it T does inherit sp_counted_base, then shared_ptr will store the
same pointer in *both* of its fields - the pointee field and the
bookkeeping field!

Now that's pretty cool. There's no second hit for a dynamic allocation,
and nicely enough, during destruction, a simple comparison between the
two fields will tell whether or not the refcounting was intrusive or
not. So now the overhead can be reduced a lot, plus, very nicely,
shared_ptr has passed on to the pointee class the decision on whether
the refcounting is multithreaded or not.

Of course, there's a ton of details to be figured out, such as casts,
offsets, and all that jazz. But I believe it can be made to work. How
would that play with the other features of shared_ptr?

Andrei

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Andrew Koenig · Guest

"Andrei Alexandrescu (See Website for Email)"
<SeeWebsiteForEmail (AT) moderncppdesign (DOT) com> wrote

David Abrahams · Guest

"Andrei Alexandrescu (See Website for Email)" <SeeWebsiteForEmail (AT) moderncppdesign (DOT) com> writes:

Peter Dimov · Guest

Andrei Alexandrescu (See Website for Email) wrote:

Dave Harris · Guest

[email]SeeWebsiteForEmail (AT) moderncppdesign (DOT) com[/email] (Andrei Alexandrescu (See Website
for Email)) wrote (abridged):

Larry Evans · Guest

On 03/24/2005 06:01 AM, Andrei Alexandrescu (See Website for Email) wrote:
[snip]

arketype@myrealbox.com · Guest

What happens here?

class Interface { };

class Concrete1 : public Interface,
public ?virtual? sp_counted_base { };

class Concrete2 : public Interface { };

shared_ptr<Interface> ptr = shared_ptr<Concrete1>(concrete1Ptr);

ptr = shared_ptr<Concrete2>(concrete2Ptr);

Or many variations thereof. I am currently using your excellent
Loki::SmartPtr to manage such a heirarchy with some custom policies
(Thanks BTW). I need to be confident of the ref counting policy in many
contexts and the smart pointer you describe subverts some of the
explicitness and static checks I enjoy with your Loki::SmartPtr.

Jeremy Jurksztowicz

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Jonathan Turkanis · Guest

Andrei Alexandrescu (See Website for Email) wrote:

lancediduck@nyc.rr.com · Guest

There is an easy modification to make, in boost/detail/shared_count.hpp
(1.32)

Change line 340 from
pi_ = new sp_counted_base_impl<P, D>(p, d);
To
pi_ =sp_create_function_select<P,D>::make(p, d);

And somewhere in the file add (inside scope of boost::detail)
template <class P,class D>
boost::detail::sp_counted_base*
sp_make_counted_base(P const&p,D const&d,void*){
return new detail::sp_counted_base_impl<P,D>(p,d);
}
template <class P,class D>
struct sp_create_function_select{
static boost::detail::sp_counted_base*
make(P const&p,D const&d){
return sp_make_counted_base(p,d,static_cast<D*>(0));
}
};

Now you have a way of specializing the create function, on either T or
D, for the guts of shared_ptr, but the default is the same as it ever
was.
For example, in the case that P is already inherited from
sp_counted_base, in your file you would write
namespace boost{
namespace detail{
boost::detail::sp_counted_base*
sp_make_counted_base(sp_counted_base*p,void*,void*){
return p;
}

}}
Or something like that ( I didn't try THIS particular overload out.
That is an exercize for the reader)
OK you got me. This violates the Open/Closed Principle. If
sp_counted_base were not in "detail" then it wouldn't. But this
may be useful to hash out some ideas while we spend the next several
years figuring out what the real answer is.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Dave Harris · Guest

[email]dave (AT) boost-consulting (DOT) com[/email] (David Abrahams) wrote (abridged):

Roshan Naik · Guest