From: Peter Dimov (pdimov_at_[hidden])
Date: 2002-09-17 07:17:18
From: "David Abrahams" <dave_at_[hidden]>
> > > 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
> outside a member function.
shared_from_raw was one of the options. But it implies that raw-to-shared
conversions are universally needed, something that I don't agree with. I
have encountered the "shared_ptr from this" problem several times, and I was
forced to switch to a custom intrusive-counted pointer because of it; the
problem has also been reported by James Kanze as a major reason to avoid
boost::shared_ptr. I don't want to acknowledge the general case - "how do I
get a shared_ptr from an arbitrary raw pointer" - as a problem.
> 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?
dangling_weak_reference is good. Noted for the release after... but you know
> > 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.
True (this applies to any C++ class and not just shared_ptr, I think; even
fundamental types seem affected). But the implementation should guard
accesses with an internal mutex. See for example thread_param and
thread_proxy in libs/thread/src/thread.cpp.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk