[boost] Re: Misc library documentation issues

From: Jon Jagger (Jon.Jagger_at_[hidden])
Date: 1999-07-14 12:17:34

Hi everyone,
I've been lurking for a while, but I'm feeling rash so I've decided to open
my mouth...I guess I should introduce myself - my name is Jon Jagger (JJ).
I'm married with three small kids and live in rural Somerset in England.
I'm the C and C++ product manager for QA training and was the/an individual
that Kevlin was speaking to about the shared_ptr optimisation.

I think the question really boils down to whether we want to support this
as an idiom...

     shared_ptr<widget> sp(new widget(...));

The problem is that given...

     template<typename T>
     class shared_ptr
     {
     public:
          explicit shared_ptr(T * p = 0) : px(p), pn(new long(1)) {}
          ...
     private:
          T * px;
          mutable long * pn;
     };

then if  new long(1) throws bad_alloc then the client has a memory-leak.
Remember that shared_ptr<> does not now how big this leak is because T is a
template parameter... It is possible to rewrite the shared_ptr declaration
to plug the leak but of course the idiom is then lost... I think Kevlin's
idea is worth using. It's also possible to hoist the count stuff into a
base class...

     struct shared_ptr_hoist
     {
          mutable long * pn;
          static const long one;
     };

     template<typename T>
     class shared_ptr : private shared_ptr_hoist
     {
     ...
     private:
          T * px;
     };

and from this it's a short step to...

     template<typename integer>
     struct shared_ptr_hoist
     {
          mutable integer * pn;
          static const integer one;
     };

     template<typename T, typename integer=long>
     class shared_ptr : private shared_ptr_hoist<integer>
     {
     ...
     private:
          T * px;
     };

This seems a nice design because all the count stuff can be factored out
into the hoist, allowing for further new/delete optimisation of the count
allocations...

Cheers
JJ
<shuts mouth>

"Kevlin Henney" <Kevlin.Henney_at_[hidden]> on 14/07/99 12:50:57

Please respond to boost_at_[hidden]

To:   boost_at_[hidden]
cc:    (bcc: Jon Jagger/QA Training Ltd)
Subject:  [boost] Re: Misc library documentation issues

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.

Thoughts?

Kevlin

Reid Sweatman <reids_at_[hidden]> on 13/07/99 18:45:47

Please respond to boost_at_[hidden]

To:   "'boost_at_[hidden]'" <boost_at_[hidden]>
cc:    (bcc: Kevlin Henney/QA Training Ltd)
Subject:  [boost] Re: Misc library documentation issues

>    However, returning to the point, the idea of adding a
> nocount is not
>    really adding a new type of smart ptr at all. It simply allows more
>    flexible use of the library. The introduction of a shared
> count for 1
>    allows a simple optimisation for a common case, and a
> resolution of the
>    construction problem (ctors would then never fail).

I agree with all your other points.  However, couldn't a CTOR failure with
this mechanism result in a zombie?

------------------------------------------------------------------------
Just Tell Us What You Want...
Respond.com - Shopping the World for You!
http://clickhere.egroups.com/click/390

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

------------------------------------------------------------------------
Just Tell Us What You Want...
Respond.com - Shopping the World for You!
http://clickhere.egroups.com/click/390

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

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

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