Boost logo

Boost :

From: Reid Sweatman (reids_at_[hidden])
Date: 1999-07-14 19:23:37


> Yes, a ctor failure could be designed to result in a zombie
> (and if nocount
> were also implemented, that would offer a possible route to a usable
> zombie). However, this would imply that the user would have
> to explicitly
> check the state of the object after construction to see whether it
> succeeded or not (eg by calling use_count), which leads us
> right back to
> the purpose of exceptions in simplifying such control flow!
>
> The count of 1 could be introduced as a static and would be
> the initial
> value for any given pointer. The only operations that could
> lead to failure
> would be copying operations (ie cp ctor and op=), but in such
> cases failure
> would not result in the loss of the held object, only the
> failure to share
> it:
>
> template<typename T>
> class shared_ptr
> {
> public:
> explicit shared_ptr(T* p = 0) : px(p),
> pn(const_cast<long *>(&one))
> {}
> shared_ptr(const shared_ptr& r)
> : px(r.px), pn(r.pn == &one ? (r.pn = new long(1)) : r.pn) {
> ++*pn; }
> ...
> private:
> ...
> mutable long* pn;
> static const long one = 1; // initialised here for
> exposition only
> };
>
> With some refactoring of the count manipulation code in
> shared_ptr this
> would be trivial to introduce.

I didn't mean that you could *force* a zombie (why'd you ever want to,
anyway?), but that if count could go to zero without invoking the object
DTOR, you'd get one anyway. Here you say that count would initialize at
one, which seems to contradict the post I originally responded to. In this
case, I don't see zombies happening without, as you say, some effort to get
them. So long as count can't legitimately drop to zero without destructing
the object, I withdraw the objection.

 

------------------------------------------------------------------------

eGroups.com home: http://www.egroups.com/group/boost
http://www.egroups.com - Simplifying group communications


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk