Re: [Boost-Users] Four Questions on boost::shared_ptr

From: Darin Adler (darin_at_[hidden])
Date: 2002-02-04 03:28:32

On 2/3/02 11:54 PM, "Jon Wang" <webmaster_at_[hidden]> wrote:

> 1. Mr Stroustrup said that there wasn't a need for auto_array, for "a better
> solution is to use a vector". So, should we use vector or
> scoped_array/shared_array?

You should normally use std::vector unless you have some special reason to
use boost:: scoped_array and boost::shared_array. Those classes are provided
both for completeness, and because occasionally there are such special
reasons. But not often.

> 2. In the document, four implementations are said to have been discussed:
> Direct detached, Indirect detached, Embedded detached and Placement detached.
> I've tried to describle them (Are I right? See the attached file), but I don't
> understand the Placement detached. Could someone please tell me what it's
> like?

The concept here is that the object is allocated in a special way, which
require use of placement, so the count is in a header before the object.
This is a form of the "embedded attached" scheme that does not require
changes to the original object's class, but it does require a special form
of new, so you couldn't just call the normal "new" and then give the object
to such a smart pointer.

[Note: There was no attached file.]

> 3. In the file smart_ptr.hpp, we can see the private function
> shared_ptr::share.
>
> I'm sorry that I don't understand that reason why ++*rpn should be done before
> dispose(). Would someone please give me an example? Or is it like this?

This function is gone from the latest implementation of shared_ptr slated
for the next boost release, so it's probably not worthwhile to discuss this
particular aspect of the old implementation in detail. The code you enclosed
looks something like the kind of code that caused trouble -- the key is that
deleting the old object pointed to can end up deleting the new shared
pointer in some cases, and this must not happen before incrementing the
reference count.

The new implementation avoids this issue by using the well-known "copy and
swap" idiom for implementing assignment, and is easier to understand.

> 4. Why not use policies? I'm afraid that the word "parameterization will
> discourage users" might not be always true, for we can use default parameters.

We'll probably be using policies in future version, if we can work out all
the issues. Andrei Alexandrescu is considering submitting his smart pointer
class template from his Loki library to Boost for formal review, which is
the most likely candidate for a Boost policy-based smart pointer. If it
turns out well enough, it may replace all the existing smart pointer class
templates.

    -- Darin