August 2008 - Boost - lists.boost.org

[test] failure of basic_cstring_test with GNU libstdc++
by Gubenko, Boris 05 Aug '08

05 Aug '08

Boost.Test library test basic_cstring_test.cpp fails to compile on many (all?) platforms using GNU libstdc++. Follows reproducer and the results of compiling it with GNU 4.3.0 and 3.4.6. Replacing 'utf::basic_cstring<CharT>::size_type' with 'std::size_t' in libs/test/test/basic_cstring_test.cpp makes the problem go away. Is it a known problem in GNU libstdc++? Does the fact that the implementation does not have to provide specializations of basic_string<> other than for 'char' and 'wchar_t' makes x.cpp below illegal? Thanks, Boris x.cpp ----- #include <string> template<typename T> void foo(T) { std::basic_string<T>::size_type i = 1; } bash-2.03$ g++ -dumpversion ; g++ -c x.cpp 4.3.0 x.cpp: In function 'void foo(T)': x.cpp:4: error: expected `;' before 'i' bash-2.03$ bash-3.00$ g++ -dumpversion ; g++ -c x.cpp 3.4.6 x.cpp: In function `void foo(T)': x.cpp:4: error: expected `;' before "i" bash-3.00$

3 8

multithreading
by lakers fan 05 Aug '08

05 Aug '08

Hello, I m new to boost libraries. Can someone give an example or tutorial of using multithreading and the use of synchronization objects like mutex between threads. Thanks Bharani _________________________________________________________________ Got Game? Win Prizes in the Windows Live Hotmail Mobile Summer Games Trivia Contest http://www.gowindowslive.com/summergames?ocid=TXT_TAGHM

4 3

[asio] buffer.hpp include the boost/function.hpp for buffer debuging result a bug
by 邱宇舟 05 Aug '08

05 Aug '08

The macro BOOST_ASIO_DISABLE_BUFFER_DEBUGGING is not defined default.Then the boost/asio/buffer.hpp will include the boost/function.hpp with pack 8 in MSVC.If the golable envionment is using pack 4 and also use boost/function.hpp, then the class function_base maybe use different pack on different place in same project. It result crash which is hardly to find the reason. In order to resolve problem, I defined the BOOST_ASIO_DISABLE_BUFFER_DEBUGGING in my project. Then it's be ok. I consider the BOOST_ASIO_DISABLE_BUFFER_DEBUGGING should be defined by default, or there should be another resolution. Qiu Yuzhou Epic Games China MSN: qbowater(a)163.com Gtalk: qbowater(a)gmail.com

1 0

[pool] out-of-memory segfault
by Phil Bouchard 05 Aug '08

05 Aug '08

Oh this morning I assumed there was a bug in shifted_ptr but it turns out it's inside pool<>::ordered_malloc(). It sounds like there is an out-of-memory: #0 0x0804c668 in boost::simple_segregated_storage<unsigned int>::try_malloc_n (start=@0xbffe8a40, n=11, partition_size=4) at /usr/local/include/boost/pool/simple_segregated_storage.hpp:234 #1 0x0804b14f in boost::simple_segregated_storage<unsigned int>::malloc_n (this=0x806e320, n=12, partition_size=4) at /usr/local/include/boost/pool/simple_segregated_storage.hpp:256 #2 0x0804a26f in boost::pool<boost::default_user_allocator_new_delete>::ordered_malloc (this=0x806e320, n=48) at /usr/local/include/boost/pool/pool.hpp:511 #3 0x0804a116 in boost::detail::sh::pool::allocate (this=0x806e320, s=48) at ../../../boost/detail/sh_owned_base_nt.hpp:104 #4 0x0804f062 in boost::detail::sh::shifted<boost::array<char, 2u> >::operator new (s=48) at ../../../boost/detail/sh_owned_base_nt.hpp:214 #5 0x0804eb57 in create_type::operator()<mpl_::integral_c<int, 2> > (this=0xbffe8bcc) at shifted_ptr_test2.cpp:75 #6 0x0804e10b in boost::mpl::aux::for_each_impl<false>::execute<boost::mpl::r_iter<mpl_::integral_c<int, 2> >, boost::mpl::r_iter<mpl_::integral_c<int, 100> >, boost::mpl::identity<mpl_::na>, create_type> (f={<No data fields>}) at /usr/local/include/boost/mpl/for_each.hpp:73 #7 0x0804d45b in boost::mpl::aux::for_each_impl<false>::execute<boost::mpl::r_iter<mpl_::integral_c<int, 1> >, boost::mpl::r_iter<mpl_::integral_c<int, 100> >, boost::mpl::identity<mpl_::na>, create_type> (f={<No data fields>}) at /usr/local/include/boost/mpl/for_each.hpp:76 #8 0x0804c581 in boost::mpl::for_each<boost::mpl::range_c<int, 1, 100>, boost::mpl::identity<mpl_::na>, create_type> (f={<No data fields>}) at /usr/local/include/boost/mpl/for_each.hpp:96 #9 0x0804af56 in boost::mpl::for_each<boost::mpl::range_c<int, 1, 100>, create_type> (f={<No data fields>}) at /usr/local/include/boost/mpl/for_each.hpp:107 #10 0x080495bb in main () at shifted_ptr_test2.cpp:123 This is: shifted_ptr/libs/smart_ptr/example/shifted_ptr_test2.cpp, compiled with: -I ../../.. -Phil

1 0

Boost wiki site spammed.
by Jurko Gospodnetić 05 Aug '08

05 Aug '08

Hi all. The wiki page at http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?LibrariesUnd… has been changed by a spammer. However, when I tried to revert the change I get an error message: > 'Spam content found, page will not be saved.' Best regards, Jurko Gospodnetić

1 0

[pool] segfault
by Phil Bouchard 05 Aug '08

05 Aug '08

Oh this morning I assumed there was a bug in shifted_ptr but it turns out it's inside pool<>::ordered_malloc(). It sounds like there is an out-of-memory: #0 0x0804c668 in boost::simple_segregated_storage<unsigned int>::try_malloc_n (start=@0xbffe8a40, n=11, partition_size=4) at /usr/local/include/boost/pool/simple_segregated_storage.hpp:234 #1 0x0804b14f in boost::simple_segregated_storage<unsigned int>::malloc_n ( this=0x806e320, n=12, partition_size=4) at /usr/local/include/boost/pool/simple_segregated_storage.hpp:256 #2 0x0804a26f in boost::pool<boost::default_user_allocator_new_delete>::ordered_malloc (this=0x806e320, n=48) at /usr/local/include/boost/pool/pool.hpp:511 #3 0x0804a116 in boost::detail::sh::pool::allocate (this=0x806e320, s=48) at ../../../boost/detail/sh_owned_base_nt.hpp:104 #4 0x0804f062 in boost::detail::sh::shifted<boost::array<char, 2u> >::operator new (s=48) at ../../../boost/detail/sh_owned_base_nt.hpp:214 #5 0x0804eb57 in create_type::operator()<mpl_::integral_c<int, 2> > ( this=0xbffe8bcc) at shifted_ptr_test2.cpp:75 #6 0x0804e10b in boost::mpl::aux::for_each_impl<false>::execute<boost::mpl::r_iter<mpl_::integral_c<int, 2> >, boost::mpl::r_iter<mpl_::integral_c<int, 100> >, boost::mpl::identity<mpl_::na>, create_type> (f={<No data fields>}) at /usr/local/include/boost/mpl/for_each.hpp:73 #7 0x0804d45b in boost::mpl::aux::for_each_impl<false>::execute<boost::mpl::r_iter<mpl_::integral_c<int, 1> >, boost::mpl::r_iter<mpl_::integral_c<int, 100> >, boost::mpl::identity<mpl_::na>, create_type> (f={<No data fields>}) at /usr/local/include/boost/mpl/for_each.hpp:76 #8 0x0804c581 in boost::mpl::for_each<boost::mpl::range_c<int, 1, 100>, boost::mpl::identity<mpl_::na>, create_type> (f={<No data fields>}) at /usr/local/include/boost/mpl/for_each.hpp:96 #9 0x0804af56 in boost::mpl::for_each<boost::mpl::range_c<int, 1, 100>, create_type> (f={<No data fields>}) at /usr/local/include/boost/mpl/for_each.hpp:107 #10 0x080495bb in main () at shifted_ptr_test2.cpp:123 This is: shifted_ptr/libs/smart_ptr/example/shifted_ptr_test2.cpp, compiled with: -I ../../.. -Phil

1 0

variant invariant
by Emil Dotchevski 05 Aug '08

05 Aug '08

Reading boost::variant's documentation: "If any bounded type is nothrow default-constructible (as indicated by boost::has_nothrow_constructor), the library guarantees variant will use only single storage and in-place construction for every bounded type in the variant. Note, however, that in the event of assignment failure, an unspecified nothrow default-constructible bounded type will be default-constructed in the left-hand side operand so as to preserve the never-empty guarantee." Do I read correctly that in an attempt to assign one variant object to another, the left-hand object _might_ silently change its type? This makes it very difficult for the user to enforce some useful invariants for types that have boost::variant members, which in my mind is very important. Wouldn't it be better to guarantee that operator= either succeeds or doesn't change the observable state of the left-hand side operand, even at the cost of memory allocation? In that case the other behavior may still be provided through a separate function. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

7 18

[mpi] MPI 1.36 beta link problems on OSX
by Matthias Schabel 05 Aug '08

05 Aug '08

Using a clean build and default install of 1.36 release branch checked out today (r47978) on OSX 10.5.4 using gcc 4.0.1, I get the following linker error : Ld /Users/matthiasschabel/Projects/CGFFT/build/Release/CGFFT normal i386 cd /Users/matthiasschabel/Projects/CGFFT /Developer/usr/bin/g++-4.0 -arch i386 -isysroot /Developer/SDKs/ MacOSX10.5.sdk -L/Users/matthiasschabel/Projects/CGFFT/build/Release - L/Applications/MATLAB74/bin/maci -F/Users/matthiasschabel/Projects/ CGFFT/build/Release -filelist /Users/matthiasschabel/Projects/CGFFT/ build/CGFFT.build/Release/CGFFT.build/Objects-normal/i386/ CGFFT.LinkFileList -mmacosx-version-min=10.5 -lfftw3_threads -lgsl - lgslcblas -lfftw3 -lmpi -lboost_mpi-xgcc40-mt -lboost_serialization- xgcc40-mt -lboost_system-xgcc40-mt -lmpi_cxx -leng -lmx -lboost_thread- xgcc40-mt -o /Users/matthiasschabel/Projects/CGFFT/build/Release/CGFFT Undefined symbols: "boost ::serialization ::detail ::extended_type_info_typeid_0 ::less_than(boost::serialization::extended_type_info const&) const", referenced from: vtable for boost ::serialization ::detail::extended_type_info_typeid_1<std::complex<double> const>in test_cgfft.o vtable for boost ::serialization::detail::extended_type_info_typeid_1<std::pair<double, std::complex<double> > const>in test_cgfft.o "boost::mpi::detail::mpi_datatype_cache", referenced from: __ZN5boost3mpi6detail18mpi_datatype_cacheE$non_lazy_ptr in test_cgfft.o "boost::serialization::extended_type_info::self_register()", referenced from: boost ::serialization::detail::extended_type_info_typeid_1<std::pair<double, std::complex<double> > const>::extended_type_info_typeid_1()in test_cgfft.o boost ::serialization ::detail::extended_type_info_typeid_1<std::complex<double> const>::extended_type_info_typeid_1()in test_cgfft.o ld: symbol(s) not found collect2: ld returned 1 exit status Any ideas on what's happening here? Matthias

2 1

[phoenix] Explanation of some standard idioms
by Robert Jones 04 Aug '08

04 Aug '08

I have had some time recently to look through some of the Boost source code, and am finding it an absolute treasure trove of useful techniques and idioms. I'd just like to check out my understanding of afew things, and would appreciate feedback. In spirit\home\phoenix\stl\algorithm\transformation.hpp is this namespace boost { namespace phoenix { namespace impl { struct swap { template <class A, class B> struct result { typedef void type; }; template <class A, class B> void operator()(A& a, B& b) const { using std::swap; swap(a, b); } }; ... Am I correct in thinking that the purpose of this is is too present swap as a 'well-behaved' functor from a phoenix composition point of view, with a nested type member? Also in this snippet, the function operator does 'using std::swap;' then uses 'swap' without quaification, rather than explicitly invoking std::swap. The effect of this (I assume) is to perform full name resolution on swap. Why is this done for swap, but not for any other std identifiers, eg copy? Elsewhere in spirit\home\phoenix\stl\algorithm\detail\begin.hpp is this... namespace boost { namespace phoenix { namespace detail { template<class R> typename range_result_iterator<R>::type begin_(R& r) { return boost::begin(r); } } }} This seems to do nothing other than provide an 'indirection' to calling boost::begin. Is the purpose here to provide a possible opportunity for specialisation? It is, btw, a real pleasure to have the chance to see the code of genuine experts in the field. Thanks in advance, Rob

2 1

[swap] Workaround for ADL failures of MSVC 7.1 and Borland okay?
by Niels Dekker - mail address until 2008-12-31 04 Aug '08

04 Aug '08

The boost::swap utility (svn/boost/trunk/boost/utility/swap.hpp) still may call std::swap when the user has added a custom swap function to the namespace of the user's type, because of some compiler bugs regarding argument-dependent lookup (ADL). This issue will occur when using GCC 3.3.1, Intel C++ 8.1, MSVC 7.1, or Borland, as indicated by regression failures of "specialized_in_global" and/or "specialized_in_other" for those specific compilers: http://www.boost.org/development/tests/trunk/developer/utility-swap_.html Those compilers typically fail to do ADL within boost::swap's internal helper function, boost_swap_impl::swap_impl<T>: template<class T> void swap_impl(T& left, T& right) { using std::swap; swap(left,right); // <-- Some compiles don't do ADL here! } What about removing the the using-declaration, "using std::swap;", and adding an extra function, boost_swap_impl::swap<T>? Which would directly call std::swap, as follows: namespace boost_swap_impl { template<class T> void swap(T& left, T& right) { std::swap(left,right); } } After doing so, MSVC 7.1 (2003) will pass both "specialized_in_global" and "specialized_in_other", while it never did before. Borland will pass "specialized_in_other" for the first time, as I tested locally on BCC 5.8.4. Who knows, maybe it will also improve the regression results of GCC 3.3.1 and Intel C++ 8.1... :-) Moreover, I think that such a workaround could also be useful to other Boost libraries, when they would start to use the boost::swap utility. For example, it could solve some swap related regression failures of boost::optional. What do you think? Would it be okay to commit this change to the trunk? Hereby the patch I would like to apply. Kind regards, -- Niels Dekker http://www.xs4all.nl/~nd/dekkerware Scientific programmer at LKEB, Leiden University Medical Center

2 5