Re: [boost] [shared_ptr] Was: Some notes on TR1 tests

From: John Maddock (john_at_[hidden])
Date: 2005-11-10 11:05:17

> test_shared_ptr:
>
> derived_deleter should take a derived*, not base*. concrete should use
> virtual inheritance.

Yep, will fix.

> test_bind:
>
> All function tests use bind( &test_proc... ), bind( test_proc... )
> should be tested too.

Will also fix.  I suspect there are other tests that could be added (extern 
"C" functions, overloaded functions etc), but I didn't want to push too far 
too soon :-)

~~~~~~

While I have your attention, I have a problem getting the TR1 version of 
<memory> to work, the basic problem is:

Some boost header includes <boost/shared_ptr.hpp>
.... includes <memory> and finds the Boost.TR1 version
....  Tries to include shared_ptr.hpp and associated headers, but gets no 
actual contents because we're within the shared_ptr include guards, but 
haven't actually declared anything yet.

I thought I had managed to get this working by forward-declaring the 
contents of shared_ptr.hpp, weak_ptr.hpp etc in the TR1 header, and this 
does actually work on some compilers (VC++ for example).  However on other 
"stricter" compilers (gcc is the prime example), the compiler chokes on the 
declaration of weak_ptr, because some of it's data members are still 
incomplete types at the time weak_ptr.hpp gets included (which is after 
shared_ptr.hpp is included, but *before* it's contents get fully declared. 
I hope I'm descibing this horrible cyclic dependency in a way that makes 
sense.

So... is there a solution?  Well I have one: ensure that when shared_ptr and 
associated headers include <memory>, they only get the real std version and 
not the Boost.TR1 version.  The Tr1 lib has a macro: BOOST_TR1_NO_RECURSION 
that stops this recursive behaviour, but it's tricky to use, because you 
have to #undef it after use, *only* if you were the one who set it in the 
first place.

So....  I've put some workaround headers for the "poisoned" TR1 headers 
under boost/config/no_tr1/*.  Boost.Config uses these to prevent cyclic 
dependencies between itself and TR1.

So....  would it be acceptible to change occurances of #include <memory> in 
shared_ptr.hpp (and associated headers) to #include 
<boost/config/no_tr1/memory.hpp> ?

It's not an ideal solution because it involves changing shared_ptr for no 
reason, except to keep some other library happy.  It's a rather fragile 
solution as well, since it's not shared_ptr that will break if a future 
change causes a regression.  But for now, it's the only solution I can think 
of.

And a note for TR2: please don't change existing std headers, it's a really 
serious pain in the you-know-where !

Thanks for reading this far,

John.