shared_ptr proposal

From: Christian Thäter (chth_at_[hidden])
Date: 2001-07-11 23:43:44

I was up to write my own 'shared_ptr' class for resource-sharing as it came in mind that i first look up what boost provides. So I found the boost smart_ptr's. Mhmm ... but stop ... whats that .. doh .. not the semantics i need, resetting and assigning a boost::shared_ptr doesn't update all pointers which belong to the object, mhm .. and it might throw a exception. Ok, there we go, i took the boost interface and hacked my own idea by using a cyclic single linked list, instead a reference counter. 

How about the performance? Just curious I wrote a very small benchmark.
Updating the entire pointer-chain takes O(N) time for N pointers, boost::shared_ptr uses O(1) algos but calls 'new long' and needs to dereference the reference-counter sometimes, so "How many (chain-) dereferences weighting an average 'new long' call?". Also it's clear that the 2 beasts are not really compareable because of the diffrent semantics. I just run it, see some hand-drawn chart at http://home.t-online.de/home/cehteh/sp.png . Well, the tests are more biased to the boost::shared_ptr cause they use up to 128 copies of the pointer, there you should not compare an O(1) with an O(N) algorithm. How many copies of a shared_ptr do You usually use on a average? I need them for 2 to 8 copies usually. I want to propose this new pointer-class for the boost/smart_ptr.hpp library either by a new name or by modifying boost::shared_ptr (has anyone code which would be broken by the semantic change?).  

Ah here are my test-sources: http://home.t-online.de/home/cehteh/sp.tar.gz

Short conclusion of features:
Pro's:
        never throws 
        never allocates memory by itself
        new semantics: reset() and operator= affect all pointers according to the resource
        predictable timing behaviour
        faster than boost::shared_ptr when used with less than lets say 8 to 16 copies

Con's:
        dtor, copy, assign and use_count using O(N) algorithms instead O(1) like boost::shared_ptr
        which decreases performance when many copies are in use.

Notes:
        dereferencing the shared_ptr itself is the same with both kinds. 
        By using a double linked list, the dtor can have O(1) complexity too (space tradeoff),
        changing copy and assign to O(1) is not trivial because of the changed semantics

greetings Christian

PS: will boost use exception-specifications in the future, because some compilers honor it when optimizing?