[boost] Re: new approach to smart ptrs -- no new()s is good n ews

From: Borgerding, Mark A. (MarkAB_at_[hidden])
Date: 2000-01-28 13:44:36

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> -----Original Message-----
> From: Gavin Collings [mailto:gcollings_at_[hidden]]
> Sent: Friday, January 28, 2000 12:17 PM
> To: boost_at_[hidden]
> Subject: [boost] Re: new approach to smart ptrs -- no new()s is
> good news
> 
> I have this implemented as a template with minor differences: -

I suspected that I might not be the first.  

In college, I sometimes worked hard to discover something new and
better, usually to learn that my theory was to be covered in the next
chapter of the book or the next course in the level :)  Still -- it
is a good way to understand the concepts more fully.

> 
> -  I set the "unique" pointer values to point to self to avoid null
> tests

I'm not sure I understand this. Can you elaborate?
Would there need to be additional code to check for circular
references?

>   
> -  I think there's a bug in your swap function - you need to 
> adjust the
> back pointer in other objects to reflect that this now collaborates
> with a different set of smart pointers.

Oops, yes. You are right. I apologize. I put the swap function in as
an afterthought.

I am feeling a bit sleepy after a big lunch, so for now, the fix is
the uininventive and unoptimized
   void baseswap(linked_ptr_base & other)
   {
      if (other.ptr != ptr){
         linked_ptr_base tmp(other);// tmp shares other's ptr
         other = *this;// other shares *this's ptr
         *this = tmp;// *this shares other's original ptr
      }
   }

> 
> -  I have the list pointers as mutable to reflect the fact 
> that they may
> be changed by other objects.

I have waffled back and forth whether I want copies/assignments to
take const or non-const references.
My current feeling is to use non-const, since there could be
synchronization repurcussions long after the operation completes. 
But I have barely won this argument with myself, so I don't expect
anyone else to be terribly swayed.

> 
> I've done timing tests which agree with yours,  I also tried to
> characterize the speed advantage against set size and found that
> there's a cross over at about 25-50 members -i.e. the current
> implementation becomes more efficient when greater than that number
> share a single pointer.
> 

I thought size didn't matter :(

I'm not sure why the number of objects should affect an individual
operation's speed.  A particular linked_ptr object only communicates
with its 2 closest neighbors. So adding or releasing references
should be constant complexity.

Likewise, for a shared_ptr, individual operations should be constant
complexity.

Is it possible you are seeing a non-linearity introduced by the
compiler's malloc/new?

Can you send me some demo code?

> There is also an additional benefit of better exception guarantees.
>  I'm all for it.

Yes, I don't think a class T could override any operator that could
affect how linked_ptr<T> behaves.  Still, I want to review each
function in depth before I place a throw() specification on the
declarations.

Cheers,
Mark

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.2 for non-commercial use <http://www.pgp.com>

iQA/AwUBOJHjlP9Ej8AEXMygEQIYrgCeKztn89Tn6/GLM8eiZViy21CpzGUAoP5E
A+57uzPsQvHc9RvkBb7fAJye
=4CqM
-----END PGP SIGNATURE-----