Re: [boost] Smart Pointers documentation/questions

From: David Abrahams (dave_at_[hidden])
Date: 2002-09-16 17:00:55

From: "Peter Dimov" <pdimov_at_[hidden]>

> > > The italicized/bracketed notes are mostly for my own use, although
> > > they might be of interest to others as well. A dedicated "future
> > > directions" section simply will not work.
> >
> > Why not?
>
> Because to keep a separate section in sync requires more effort, and I
know
> that I'll unavoidably let it decay over time. Fact of life. The notes are
> easy enough to maintain so they'll stay reasonably current and relevant.
> Without them I tend to use flying pieces of paper that often mysteriously
> disappear.

I know what you mean. When my windows are open my office is so windy I
can't keep track of anything!

> > > > - A parenthesized note mentions "A free function shared_from_this"
> > > > which I don't see documented anywhere else. Why "from_this"? Is
> > > > there something special about a this pointer in this case? And how
> > > > is that different from shared_ptr<T>(x)?
> > >
> > > shared_from_this is not yet official. It is supposed to be called
> > > only from within a member function
> >
> > Why? What's special about being within a member function?
>
> Nothing in particular; this is simply the intent of shared_from_this, it
> solves the specific "how do I obtain a shared_ptr from this" problem.

I would prefer "shared_from_raw", since it can just as legitimately be used
outside a member function.

> > > > - I think "use_count_is_zero" is an unintuitive name for that
> > > > exception.  IMO it should be something like "no_shared_object" or
> > > > "shared_object_deleted"... or something.
> > >
> > > I've never been good at intuitive naming.
> >
> > Can we have a discussion of what a good name might be before this gets
> > too solid? Or is it already too solid?
>
> I don't mind seeing use_count_is_zero renamed if this is what you ask;
> whether the name is "too solid" depends on how many people are already
using
> it, of course. It's a relatively new feature; perhaps not much code
depends
> on it yet.

FWIW, in Python, you get this:

    >>> y = weakref.proxy(x)
    >>> y
    <__main__.X instance at 0x00938B88>
    >>> del x
    >>> y
    Traceback (most recent call last):
      File "<stdin>", line 1, in ?
    ReferenceError: weakly-referenced object no longer exists

So maybe dangling_weak_reference is the best name?

> > > Pass by value should be safe. shared_ptr is supposed to be as
> > > thread-safe as an int.
> >
> > I know that it's /supposed/ to be. The question has to do with the
> > mechanism for starting threads. I have *no* idea how this stuff works
> > in practice, so there may be no worry. However, imagine that it uses
> > something like the way I remember fork() works. If I recall correctly,
> > when you fork() you may get a second copy of your function using the
> > same memory image. If the shared_ptr was passed by-value into the
> > function calling fork, there would be a race condition because one
> > copy of the function would be trying to destroy the shared_ptr on
> > exit, while the other one would be trying to read it.
>
> I think that the scenario you are describing isn't allowed, as threads
must
> share memory.

I don't understand your remark. The scenario I describe is caused by
precisely this fact. It seems to me that either thread startup takes no
parameters at all, or at *some* point the starter and startee will have to
be holding references to the same shared_ptr.

-Dave

-----------------------------------------------------------
           David Abrahams * Boost Consulting
dave_at_[hidden] * http://www.boost-consulting.com