test_shared_ptr: derived_deleter should take a derived*, not base*. concrete should use virtual inheritance. test_bind: All function tests use bind( &test_proc... ), bind( test_proc... ) should be tested too. -- Peter Dimov http://www.pdimov.com
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.
John Maddock wrote:
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.
What are the exact errors that you get?
What are the exact errors that you get?
"g++" -c -Wall -ftemplate-depth-255 -DTEST_STD_HEADERS=1 -g -O0 -fno-inline -I"/u/troy/boost-regressions/results/bin/boost/libs/tr1/test" -I"/u/troy/boost-regressions/boost/boost/tr1/tr1/bcc32" -I "/u/troy/boost-regressions/boost/boost/tr1/tr1" -I "/u/troy/boost-regressions/boost" -o "/u/troy/boost-regressions/results/bin/boost/libs/tr1/test/std_run_complex_overloads.test/gcc/debug/run_complex_overloads.o" "/u/troy/boost-regressions/boost/libs/tr1/test/run_complex_overloads.cpp" In file included from /u/troy/boost-regressions/boost/boost/tr1/memory.hpp:57, from /u/troy/boost-regressions/boost/boost/tr1/tr1/memory:28, from /u/troy/boost-regressions/boost/boost/detail/sp_counted_impl.hpp:34, from /u/troy/boost-regressions/boost/boost/detail/shared_count.hpp:30, from /u/troy/boost-regressions/boost/boost/shared_ptr.hpp:26, from /u/troy/boost-regressions/boost/boost/test/predicate_result.hpp:24, from /u/troy/boost-regressions/boost/boost/test/test_tools.hpp:19, from /u/troy/boost-regressions/boost/libs/tr1/test/run_complex_overloads.cpp:12: /u/troy/boost-regressions/boost/boost/weak_ptr.hpp:166: error: field `pn' has incomplete type /u/troy/boost-regressions/boost/boost/weak_ptr.hpp: In constructor `boost::weak_ptr<T>::weak_ptr()': /u/troy/boost-regressions/boost/boost/weak_ptr.hpp:37: error: class `boost::weak_ptr<T>' does not have any field named `pn' /u/troy/boost-regressions/boost/boost/weak_ptr.hpp: In constructor `boost::weak_ptr<T>::weak_ptr(const boost::weak_ptr<Y>&)': /u/troy/boost-regressions/boost/boost/weak_ptr.hpp:62: error: class `boost::weak_ptr<T>' does not have any field named `pn' /u/troy/boost-regressions/boost/boost/weak_ptr.hpp: In constructor `boost::weak_ptr<T>::weak_ptr(const boost::shared_ptr<Y>&)': /u/troy/boost-regressions/boost/boost/weak_ptr.hpp:68: error: class `boost::weak_ptr<T>' does not have any field named `pn' /u/troy/boost-regressions/boost/boost/weak_ptr.hpp: In member function `boost::weak_ptr<T>& boost::weak_ptr<T>::operator=(const boost::weak_ptr<Y>&)': /u/troy/boost-regressions/boost/boost/weak_ptr.hpp:78: error: `pn' undeclared (first use this function) /u/troy/boost-regressions/boost/boost/weak_ptr.hpp:78: error: (Each undeclared identifier is reported only once for each function it appears in.) /u/troy/boost-regressions/boost/boost/weak_ptr.hpp: In member function `boost::weak_ptr<T>& boost::weak_ptr<T>::operator=(const boost::shared_ptr<Y>&)': /u/troy/boost-regressions/boost/boost/weak_ptr.hpp:86: error: `pn' undeclared (first use this function) /u/troy/boost-regressions/boost/boost/weak_ptr.hpp: In member function `long int boost::weak_ptr<T>::use_count() const': /u/troy/boost-regressions/boost/boost/weak_ptr.hpp:123: error: `pn' undeclared (first use this function) /u/troy/boost-regressions/boost/boost/weak_ptr.hpp: In member function `bool boost::weak_ptr<T>::expired() const': /u/troy/boost-regressions/boost/boost/weak_ptr.hpp:128: error: `pn' undeclared (first use this function) /u/troy/boost-regressions/boost/boost/weak_ptr.hpp: In member function `void boost::weak_ptr<T>::swap(boost::weak_ptr<T>&)': /u/troy/boost-regressions/boost/boost/weak_ptr.hpp:139: error: `pn' undeclared (first use this function) /u/troy/boost-regressions/boost/boost/weak_ptr.hpp: In member function `void boost::weak_ptr<T>::_internal_assign(T*, const boost::detail::shared_count&)': /u/troy/boost-regressions/boost/boost/weak_ptr.hpp:145: error: `pn' undeclared (first use this function) /u/troy/boost-regressions/boost/boost/weak_ptr.hpp: In member function `bool boost::weak_ptr<T>::_internal_less(const boost::weak_ptr<Y>&) const': /u/troy/boost-regressions/boost/boost/weak_ptr.hpp:150: error: `pn' undeclared (first use this function)
John Maddock wrote:
What are the exact errors that you get?
"g++" -c -Wall -ftemplate-depth-255 -DTEST_STD_HEADERS=1 -g -O0 -fno-inline -I"/u/troy/boost-regressions/results/bin/boost/libs/tr1/test" -I"/u/troy/boost-regressions/boost/boost/tr1/tr1/bcc32" -I "/u/troy/boost-regressions/boost/boost/tr1/tr1" -I "/u/troy/boost-regressions/boost" -o "/u/troy/boost-regressions/results/bin/boost/libs/tr1/test/std_run_complex_overloads.test/gcc/debug/run_complex_overloads.o" "/u/troy/boost-regressions/boost/libs/tr1/test/run_complex_overloads.cpp"
In file included from /u/troy/boost-regressions/boost/boost/tr1/memory.hpp:57, from /u/troy/boost-regressions/boost/boost/tr1/tr1/memory:28, from /u/troy/boost-regressions/boost/boost/detail/sp_counted_impl.hpp:34,
Can you try guarding this #include like so: #if defined(BOOST_SP_USE_STD_ALLOCATOR) #include <memory> // std::allocator #endif and see if this fixes the problem?
Can you try guarding this #include like so:
#if defined(BOOST_SP_USE_STD_ALLOCATOR) #include <memory> // std::allocator #endif
and see if this fixes the problem?
Which #include? In shared_ptr.hpp and associated headers? Isn't the include needed for auto_ptr interoperability regardless of whether std::allocator is used? In any case the code should work regardless of whether BOOST_SP_USE_STD_ALLOCATOR is defined. John.
John Maddock wrote:
Can you try guarding this #include like so:
#if defined(BOOST_SP_USE_STD_ALLOCATOR) #include <memory> // std::allocator #endif
and see if this fixes the problem?
Which #include?
from /u/troy/boost-regressions/boost/boost/detail/sp_counted_impl.hpp:34,
_This_ #include.
Peter Dimov wrote:
John Maddock wrote:
Can you try guarding this #include like so:
#if defined(BOOST_SP_USE_STD_ALLOCATOR) #include <memory> // std::allocator #endif
and see if this fixes the problem?
Which #include?
from /u/troy/boost-regressions/boost/boost/detail/sp_counted_impl.hpp:34,
_This_ #include.
BTW: I can't reproduce the problem here, but my Cygwin g++ is a bit old (3.4).
and see if this fixes the problem?
Which #include?
from /u/troy/boost-regressions/boost/boost/detail/sp_counted_impl.hpp:34,
_This_ #include.
BTW: I can't reproduce the problem here, but my Cygwin g++ is a bit old (3.4).
No that doesn't make any difference (I see the same errors): in order to make that fix work, you would have to stop shared_ptr.hpp weak_ptr.hpp and *all their dependents* from including <memory>. Which is basically what I was suggesting before (it stops the TR1 version being included anyway). My cygwin gcc is 3.4.4 and you can reproduce with: cd libs/tr1/test bjam std_test_random shared_ptr then gets included via the unit-test-suite and that triggers the error, strangely if I have a file that just includes shared_ptr directly it doesn't *seem* to trigger the problem (but I haven't tried that hard to boil down a test case). In any case the compiler is right to complain in this situation: it's just that *some* compilers take a more relaxed attitude to parsing templates, and don't seem to mind if some [non-template-] members are incomplete at the point the template is seen. John.
John Maddock wrote:
My cygwin gcc is 3.4.4 and you can reproduce with:
cd libs/tr1/test bjam std_test_random
This doesn't work for me. C:\Documents and Settings\pdimov\cvs\boost\libs\tr1\test>bjam -sTOOLS=gcc std_test_random ...found 541 targets... ...updating 2 targets... gcc-C++-action ..\..\..\bin\boost\libs\tr1\test\std_test_random.test\gcc\debug\std_test_random.obj spawn: Invalid argument C:\Documents and Settings\pdimov\cvs\boost\libs\tr1\test>g++ --version g++ (GCC) 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125) Copyright (C) 2004 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
John Maddock wrote:
My cygwin gcc is 3.4.4 and you can reproduce with:
cd libs/tr1/test bjam std_test_random
This, however: C:\Documents and Settings\pdimov\My Documents\Projects\temp>g++ -I ..\..\..\cvs\ boost -I ..\..\..\boost\tr1\tr1 ..\..\..\cvs\boost\libs\tr1\test\run_random.cpp Compiles, runs and passes. Ditto for the other run_* test.
John Maddock wrote:
and see if this fixes the problem?
Which #include?
from /u/troy/boost-regressions/boost/boost/detail/sp_counted_impl.hpp:34,
_This_ #include.
BTW: I can't reproduce the problem here, but my Cygwin g++ is a bit old (3.4).
No that doesn't make any difference (I see the same errors):
That's unpossible :-) since sp_counted_impl.hpp no longer includes <memory>. Can you please post the new error?
in order to make that fix work, you would have to stop shared_ptr.hpp weak_ptr.hpp and *all their dependents* from including <memory>.
No, I don't. :-)
Peter Dimov wrote:
John Maddock wrote:
and see if this fixes the problem?
Which #include?
from /u/troy/boost-regressions/boost/boost/detail/sp_counted_impl.hpp:34,
_This_ #include.
BTW: I can't reproduce the problem here, but my Cygwin g++ is a bit old (3.4).
No that doesn't make any difference (I see the same errors):
That's unpossible :-) since sp_counted_impl.hpp no longer includes <memory>. Can you please post the new error?
Never mind, I finally got it to fail. I had to #define TEST_STD_HEADERS.
in order to make that fix work, you would have to stop shared_ptr.hpp weak_ptr.hpp and *all their dependents* from including <memory>.
No, I don't. :-)
This is what needs to be done: In shared_ptr.hpp, move #include <memory> to the top. In weak_ptr.hpp, add #include <memory> #include <boost/detail/shared_count.hpp> above #include <boost/shared_ptr.hpp>. I'll commit these fixes when the CVS starts working again.
This is what needs to be done:
In shared_ptr.hpp, move #include <memory> to the top.
In weak_ptr.hpp, add
#include <memory> #include <boost/detail/shared_count.hpp>
above
#include <boost/shared_ptr.hpp>.
I'll commit these fixes when the CVS starts working again.
Amazing! Thanks, I didn't think that one was going to be solvable! John.
John Maddock wrote:
This is what needs to be done:
In shared_ptr.hpp, move #include <memory> to the top.
In weak_ptr.hpp, add
#include <memory> #include <boost/detail/shared_count.hpp>
above
#include <boost/shared_ptr.hpp>.
I'll commit these fixes when the CVS starts working again.
Amazing! Thanks, I didn't think that one was going to be solvable!
It's obvious now (in hindsight) that shared_ptr ought to have resided in <tr1/shared_ptr> or <tr1/memory>, isn't it. Unfortunately it may be too late now to fix that. But you still may want to raise the issue on the stdlib reflector.
participants (2)
-
John Maddock -
Peter Dimov