From: John Maddock (john_at_[hidden])
Date: 2005-11-10 11:05:17
> derived_deleter should take a derived*, not base*. concrete should use
> virtual inheritance.
Yep, will fix.
> 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
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
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
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
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,
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk