Re: [boost] Re: No more tree_traits<> dependencies under placed_ptr<>

From: Larry Evans (jcampbell3_at_[hidden])
Date: 2002-10-03 16:47:42

David B. Held wrote:
 > "Larry Evans" <jcampbell3_at_[hidden]> wrote in message
 > news:3D9C8EEF.4050609_at_prodigy.net...
 >
 >>[...]
 >>Based on the lack of response to my other postings about collecting
 >>cycles, I have my doubts whether boost would be interested in yet
 >>another smart pointer.  I could be wrong.
 >
 >
 > Well, Boost has been interested in cycles for a long time, as is evidenced
 > by Greg Colvin's cyclic_ptr, which has been in the files area for as long as
 > I can remember.  Probably the main factor is that cycles in shared_ptr<>
 > are currently handled by weak_ptr<>, and so that method has a lot of
 > momentum.  But if you can show another method of dealing with cycles
 > is compelling and advantageous, through the use of benchmarks and
 > use cases, then I don't see why they shouldn't be taken into consideration.
 >

The post at:
   http://aspn.activestate.com/ASPN/Mail/Message/boost/1150459
descibes a weakness of cyclic_ptr which the code announced at:
   http://aspn.activestate.com/ASPN/Mail/Message/1363851
overcomes.  The code is at:
   http://groups.yahoo.com/group/boost/files/shared_cyclic_ptr/
        
The file, iplimits.txt, compares the 2 internal pointer
enumeration (ip) methods and the output from the test driver in
the zip file demonstrates the weakness of cyclic_ptr's method of
ip enumeration (corresponding to the ip_assign_op_switch value of
enum ip_methods) compared to the ip_offset_iterator (another enum
ip_methods value) method.

I did have a benchmark comparing cyclic_ptr with an earlier
version of the ip_offset_iterator method, and ip_assign_op_switch
was clearly superior.  However, I've made what I hope were some
improvements which may make the difference a lot less.  OTOH, my
impression is that boost is more interested in "fewer suprises"
rather than speed, and, as mentioned above, the
ip_offset_iterator method doesn't have the "surprise" (or
weakness) described in the 1150459 post.

I'll be happy to resurrect the code, but I'd first like some
feedback on whether there's agreement on the merits of
ip_offset_iterator vs. ip_assign_op_switch.  I'll also be happy
to write a short user's guide on how to use ip_offset_iterator,
if booster's find reading the code too daunting (Maddock actually
asked me to do that way back for the old ip method, but I never
got around to it).