- Boost - lists.boost.org

[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 04 Aug '08

04 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

Problems with building docs on trunk
by Andrey Semashev 03 Aug '08

03 Aug '08

Hi, I recently updated to Boost trunk and now I cannot build any QuickBook documentation. I get the following error: /home/lastique/src/boost/trunk/tools/build/v2/build/virtual-target.jam:1032: in virtual-target.register-actual-name from module virtual-target error: Duplicate name of actual target: <phtml>standalone_HTML.manifest error: previous virtual target { boostbook%boostbook.docbook-to-htmldir-standalone_HTML.manifest.HTMLDIR { boostbook%boostbook.boostbook-to-docbook-bimap.docbook.DOCBOOK { quickbook%quickbook.quickbook-to-boostbook-bimap.xml.XML { bimap.qbk.QUICKBOOK } } } } error: created from libs/bimap/doc/standalone error: another virtual target { boostbook%boostbook.docbook-to-htmldir-standalone_HTML.manifest.HTMLDIR { boostbook%boostbook.boostbook-to-docbook-bimap.docbook.DOCBOOK { quickbook%quickbook.quickbook-to-boostbook-bimap.xml.XML { bimap.qbk.QUICKBOOK } } } } error: created from libs/bimap/doc/standalone error: added properties: <link>static error: removed properties: <link>shared /home/lastique/src/boost/trunk/tools/build/v2/build/virtual-target.jam:468: in actualize-no-scanner from module object(file-target)@505 /home/lastique/src/boost/trunk/tools/build/v2/build/virtual-target.jam:123: in object(file-target)(a)505.actualize from module object(file-target)@505 /home/lastique/src/boost/trunk/tools/build/v2/build-system.jam:681: in load from module build-system /home/lastique/src/boost/trunk/tools/build/v2/kernel/modules.jam:281: in import from module modules /home/lastique/src/boost/trunk/tools/build/v2/kernel/bootstrap.jam:128: in boost-build from module /home/lastique/src/boost/trunk/boost-build.jam:17: in module scope from module I tried the branches/release version of Boost, but the error persists. I had QuickBook working just fine before I updated (sorry, I don't remember the previous revision number). Could someone point me to the problem source, please?

2 3

A library for checking overflow in the built-in int types?
by Isaac Dupree 02 Aug '08

02 Aug '08

Is there interested in a library to check for overflow in (primarily) the built-in integers? (and some other things related to int-wrapping: see below). It implements a different thing than constrained_value, though I suppose they might have some code in common. I need/want it in my own project, so I've been working on such a thing: Use case: I'm trying to write some performance-critical code that might buggily rely on larger ints than are provided, and it's not obvious whether there are actually any integer overflows happening (I hope not, but I need to test -- there are some bugs that might be overflow-related). Additionally, it has to behave exactly the same on the network across different computers it's compiled on (so I've been using all specific int-sizes, such as int32_t). (okay, it's a multiplayer game where all players simulate on their own computers to keep in sync, and most of the time only transfer their very simple commands over the network.) For example, a bug I'd had that took me a while to squash involved not realizing that right/left-shifting by an unsigned integer's bit-size is undefined behavior, (the bug manifested on x86-linux-gcc but not powerpc-linux-gcc). Also, the platforms manifested different behaviors for dividing by zero (crash with SIGFPE(!) versus continue with some value). Most of the time I want overflows to be treated as errors, (although sometimes I actually want the unsigned modulo-behavior, and a plausible error behavior would be to clamp the value to within the range and log to stderr). I looked at a (proposed for boost?) constrained-value library http://student.agh.edu.pl/~kawulak/constrained_value/index.html . Since I want the full range of the builtin types, and constrained_value deliberately doesn't check for overflow in the underlying representation, I need something different (or additional). Ideally it could be a drop-in replacement for the builtin types I've been using. Like constrained_value, I decided it was too unsafe to have implicit casting back to the representation-type. The integral-promotion effects inherited from C would surely end up being changed by such a wrapper. So I also want a wrapper that just "sanitizes" those promotions: I think e.g. adding ints of the same signedness should produce a value with the max. of their two bit-sizes, and anything else (including mixed-signedness) require explicit casting. Then I can wrap that type with my overflow-checking template (which has performance overhead) for testing, while having exactly the same behavior as without the overflow-checking when there are in fact no overflows. There's also the issue of determinism in relation to implementation- defined behavior -- e.g. dividing with or right-shifting negative numbers. In one wrapper I probably want to (optionally, depending on policy template arguments perhaps) prevent doing those operations on the underlying types, and perhaps have another wrapper that detects those cases and replaces them with builtin operations that work. (e.g. (sint >> shift) becomes (sint >= 0 ? (sint >> shift) : ~(~sint >> shift)) (I started out not being so wrapper-happy, but then I thought it was probably cleaner to have a library that makes it generally easy to wrap int-like things.) Hopefully a compiler that doesn't need them, can just optimize out the pessimizations. Other notes about implementation "decisions" I've thought about: It's very convenient to assuming that the underlying values are two's complement bitwise (signed or unsigned) integer types that have some number of bits, for writing algorithms to efficiently check for overflow, so I do that in the part of the library that has range-checking algorithms for ints. However, I allow underlying types to be larger than strictly needed (and in some cases the underlying type being larger, allows the overflow-checking code to be faster as well). Currently I have the overflow-checking algorithms in macros, which I don't like much. But it has some advantages: - library can even be used in preprocessor constant expressions, e.g. in an #if. (not worth as much as it could be because it can't interact with Boost.Preprocessor constants usefully.) - Until we have C++0x "constexpr" functions, the only way to share int-based algorithms between runtime code and compile-time template code is macros. - The maximum bit-sizes of the values could be allowed to vary at runtime. But then we lose a lot of static optimizations. Putting the bit-sizes as dynamic arguments even to an "inline" function template seems risky, but making them static is forever. In light of constrained_value's mutable ranges, I don't think there's actually a need for that. Bit-shift amounts are often but not always known at compile-time... but let's let the compiler worry about that? But there's a disadvantage: - No explicit sharing; the compiler will have to figure out that two expressions are identical. However, explicit sharing kills 'constexpr' functions too... but at least then the shared expression can be put into another named function so that it might be less work for the compiler to notice that they're the same. Overflow checking for signed numbers is annoying/inefficient, because e.g. negating the minimum value is overflow. Perhaps there should be two signed compile-time modes, one in which those can overflow but not the bitwise operators ~ | ^ &, and another mode without that minimum value, in which normal arithmetic would be "safer" but bit-operations a bit less so (but you should know what you're doing if you're using them on signed values anyway). Conceivably a wrapper something like this could be used to wrap "integer-valued doubles that are small enough to represent each consecutive integer" as odd-sized integer values computed by FPU. But (x < 1) where x is a double may not even give the same answer each time, apparently! So I don't have the skills to do anything like that. ideas of what people might want for overflow behavior: - boost::optional<int> to have non-throwing failure, similar to floating-point NaN. - clamping to the endpoints (overflow becomes the max value defined by the bit-size, underflow the min value, and if division by zero is one of the things detected... well that's something a policy will have to say). - modulo-arithmetic for any number of bits you want, even if it's not a multiple of CHAR_BIT. - obviously, exception throwing or assert failure In the process I found/invented an int-log-base-two implementation that seems it should be decently fast at runtime and also works as an integer constant expression. (although with GCC it can detect with __builtin_constant_p and bitsizes, whether it can change that to __builtin_clz[l[l]], so it can be often be turned into a special processor instruction at runtime for many architectures including x86 and powerpc; do other compilers have facilities like that?). Unfortunately I've been struggling a little with the int-wrapping template classes, but I thought I'd ask if there was interest before struggling to make sure my code approached Boost-quality rather than just "good enough for me" quality :-) cheers, -Isaac

6 5

Why I hate subversion
by Eric Niebler 02 Aug '08

02 Aug '08

U boost/indirect_reference.hpp U boost/parameter.hpp svn: In directory 'boost' svn: Can't move 'boost/.svn/tmp/foreach.hpp.2.tmp' to 'boost/foreach.hpp': Permission denied ericne@ericne-xps ~/boost/org/trunk $ svn up svn: Checksum mismatch for 'boost/.svn/text-base/enable_shared_from_this.hpp.svn-base'; recorded: '12d8c5183a709a7699c13b312073c36c', actual: 'c89a6b23045ff8c89d2de74213d1649a' Does this ever happen to anybody else? I get this random corruption of my local subversion repository about once a month. -- Eric Niebler Boost Consulting www.boost-consulting.com

11 15