Boost logo

Boost :

From: David Maisonave (dmaisonave_at_[hidden])
Date: 2006-01-13 14:48:37


Can the boost::shared_ptr be configured to use reference link instead of
reference counter?

If not, does boost have a smart pointer that uses reference link logic?

See following example:

http://code.axter.com/cow_ptr.h

 

The above smart pointer uses a reference linking logic instead of a
reference counter.

 

I originally had the above smart pointer using reference counting logic,
but it performed poorly during initialization, because of the call to
new. I notice boost::shared_ptr has similar poor performance during
initialization.

 

Other than the increase object size, does anyone know any other reason
why the boost::shared_ptr shouldn't be using reference link logic
instead of reference counting?

 

In another question, a couple of members recommended that I define
BOOST_SP_USE_QUICK_ALLOCATOR to increase the boost::shared_ptr
performance, and it did. It also increased the performance of the other
smart pointers.

If BOOST_SP_USE_QUICK_ALLOCATOR does such a good job in increasing
performance, why is it not defined by default? What is its down side?
(if any)

 

I notice a very odd result when testing on VC++ 7.1 using the build-in
STL library that comes with VC++ with the following test code:

http://code.axter.com/copy_ptr.h
http://code.axter.com/cow_ptr.h
http://code.axter.com/shape_test.h
http://code.axter.com/boost_ptr_containers/main.cpp

 

The above test code actually perform poorly when using vector ::
reserve.

It takes more time to populate the container when the reserve function
is called.

This happens with all the tested containers except vector<copy_ptr>

 

If I use STLport, than I get expected results, where the code calling
reserve performance better than the code not calling reserve.

 

Can anyone else test this to see if they get similar results, and if so,
does anyone have any idea what MS's STL code could be doing wrong?

 

Thanks

 


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