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
> 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
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
> it, of course. It's a relatively new feature; perhaps not much code
> on it yet.
FWIW, in Python, you get this:
>>> y = weakref.proxy(x)
<__main__.X instance at 0x00938B88>
>>> del x
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
> 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.
David Abrahams * Boost Consulting
dave_at_[hidden] * http://www.boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk