- Boost - lists.preview.boost.org

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

[unnullable_ptr] Proposal for a new library
by Angel Tsankov 02 Aug '08

02 Aug '08

Hello, Is there any interest in a class template which acts like a pointer and guarantees at compile time and at no CPU or memory cost (except when a call to any of its methods is not inlined) that the pointer is not null? One of the applications that I have found for this template is in defensive programming to eliminate the chances that dereferencing a pointer will result in undefined behaviour (when the pointer is null). Using this template is superior to any alternative method (that I know) to achieve the same result, since: (*) it consumes no CPU (in contrast to null checks); (*) the class template instances are copy constructible and copy assignable (in contrast to references which can also be used to guarantee unnullability); (*) it is natively supported by the language and provides a 'real' guarantee (in contrast to 'design by contract'); (*) supports the natural syntax for access to the wrapped resource (in constrast to boost::ref). Regards, Angel Tsankov

13 35

[shifted_ptr] STL support works at 90% (...!)
by Phil Bouchard 02 Aug '08

02 Aug '08

I've finalized the ad extremum idea of STL support of smart pointers such as shifted_ptr which is a good example to use because of the distinct types it is using as pointer types (T *, shifted<T> *, shifted_allocator::pointer, etc.). I have 2 patch files that can be used as an example to add support for real smart pointers using Gcc's STL. These are located in the bits/ folder. These are Gnu related but I wanted to share this here for objectivity. I have added special contructors in shifted_ptr that takes raw pointers (T *) instead of the type safe shifted<T> *. This is temporary until I add the proper casts inside the STL code. What else? I simplified shifted_allocator and fixed abominable bugs in shifted_ptr created by these temporary constructors added. Now I'm pretty dang happy about it... There are still some I need to fix and some more are yet to be found but it should be much easier now. Once again I am using shifted_ptr_test2.cpp as my main test application. Later, -Phil

1 2

Possible library submissions: fuzzy logic library, new container
by Alex Shafir 01 Aug '08

01 Aug '08

I am trying to determine if there might be any interest in a couple of possible library submissions. Both ideas were very useful and instrumental for many C++ development projects that I was doing for the last years. The fuzzy logic library is a simple, pure C++, optimized for speed, practical implementation of the fuzzy logic calculations that DOES NOT attempts to comply with the FCL(Fuzzy Control Language) standard (like IEC 1131). It CANNOT load FCL files. Instead similar to the Boost Spirit framework it provides a syntax that enables fuzzy logic rules to be written exclusively in C++. Compiled fuzzy model specifications are immediately executable. A snippet of what this syntax currently looks like is at the end of this message. The other idea is the “sparse array” container. Working for securities trading industry I used it innumerable number of times. It is useful in situations where there is a set of entities identified by integer(unsigned) numbers. Most often the numbers are identity keys in a database, a protocol field ids, etc. The potential range of the numbers makes it impractical to use a C++ array or the STL <vector>. On the other hand the average percentage of the keys that are really used in an application relative to the potential range is often less then 5% and there are huge holes of unused keys between zero and max(used key). The data elements or pointers to objects are kept in a structure similar to a balanced B-tree. Elements are directly accessed by an index operator. Access involves only a few arithmetic and redirection operations. When storing a new element that is outside of the range provided by exiting data structure the structure bilds itself up extending the indes range enough to accommodate a new index value. Existing data are never physically moved like in the STL vector. So, all references/pointers/iterators referencing existing elements are never invalidated. Feel free to comment. Fuzzy model syntax sample: ======================================== #include "TestModel.h" using namespace Fuzzy; // test model definition TestModel::TestModel(string file): Model(file), angle(-1), velocity(-1), speed(-1) { // fuzzy variables definitions created by the base class (Fuzzy::Model) // Input/Output methods; Input/Output arguments are refs // to double scalar variables Var& Angle = Input(angle); Var& Vlcty = Input(velocity); Var& Speed = Output(speed); // membership functions definitions created by fuzzy variables // Term method; Term method takes curve name as an argument; // cureve names are defined in the Fuzzy::Model curve definition // file MemFun& AngleNegHigh = Angle.Term("AngleNegHigh"); MemFun& AngleNegLow = Angle.Term("AngleNegLow"); MemFun& AngleZero = Angle.Term("AngleZero"); MemFun& AnglePosLow = Angle.Term("AnglePosLow"); MemFun& AnglePosHigh = Angle.Term("AnglePosHigh"); MemFun& VlctyNegHigh = Vlcty.Term("VelocityNegHigh"); MemFun& VlctyNegLow = Vlcty.Term("VelocityNegLow"); MemFun& VlctyZero = Vlcty.Term("VelocityZero"); MemFun& VlctyPosLow = Vlcty.Term("VelocityPosLow"); MemFun& VlctyPosHigh = Vlcty.Term("VelocityPosHigh"); MemFun& SpeedNegHigh = Speed.Term("AngleNegHigh"); MemFun& SpeedNegLow = Speed.Term("AngleNegLow"); MemFun& SpeedZero = Speed.Term("AngleZero"); MemFun& SpeedPosLow = Speed.Term("AnglePosLow"); MemFun& SpeedPosHigh = Speed.Term("AnglePosHigh"); // these are the model rules; syntax is pretty strightforward; // rules look like operator >> where lhs is the condition and // rhs is the conclusion; // lhs and rhs have to be in parens if they contain more then // one term because of the c++ operators precedence rules; // conclusion may be a comma separated list of output terms // in parens ((AngleZero and VlctyZero)or(AnglePosLow and VlctyNegLow)or(AngleNegLow and VlctyPosLow)) >> SpeedZero; ((AngleZero and VlctyNegLow)or(AngleNegLow and VlctyZero)) >> SpeedNegLow; ((AnglePosLow and VlctyZero)or(AngleZero and VlctyPosLow)) >> SpeedPosLow; ((AngleZero and VlctyNegHigh)or(AngleNegHigh and VlctyZero)) >> SpeedNegHigh; ((AnglePosHigh and VlctyZero)or(AngleZero and VlctyPosHigh)) >> SpeedPosHigh; } TestModel::~TestModel() { } void TestModel::run(double a, double v, double &s) { // we assign scalar variables to class members angle = a; velocity = v; speed = s; // then run the model // it should be pretty fast as it all designed to preallocate // all the needed large objects in the model constructor Model::run(); // and assign the values of output variables s = speed; }

3 2

dll-path feature
by brook＠biology.nmsu.edu 01 Aug '08

01 Aug '08

It seems that I need to use the dll-path feature to add an -rpath directive to the linker when my boost libraries are installed. This seems to be described (mostly) fairly clearly at http://www.boost.org/boost-build2/doc/html/bbv2/faq/dll-path.html What is not clear is where the feature should be invoked. My attempt to modify Jamroot to add <dll-path> to the boost-install rule failed in the sense that not rpath information makes it into the installed libraries. (The rest of this snippet is the original.). rule boost-install ( libraries * ) { package.install install : <dependency>/boost//install-headers $(install-requirements) : # No binaries : $(libraries) : # No headers, it's handled by the dependency ; install stage : $(libraries) : <location>$(BOOST_STAGE_LOCATE) <dll-path>/path/to/add/via/rpath ; local c = [ project.current ] ; local project-module = [ $(c).project-module ] ; module $(project-module) { explicit stage ; explicit install ; } } So, how is one supposed to invoke the <dll-path> feature in order to have -rpath added to the linking of libraries during their installation? Thanks for your help. Cheers, Brook

3 4

[1.36.0 beta] Bug fix procedures
by Beman Dawes 01 Aug '08

01 Aug '08

Bug reports from the beta are starting to surface on the user's list. Here is the procedure for dealing with them: * Apply the fix to the trunk. * Wait until enough regression tests have cycled to demonstrate that the fix worked and didn't break anything else. * Apply the fix to branches/release. * Keep an eye on the release test results to be sure there were no unintended consequences. In other words, there is no need to ask the release managers for permission to apply to branches/release as long as tests are clean. The whole point of doing a beta is to shake these user detected bugs out of the woodwork and apply the resulting fixes in time for the release. Thanks, --Beman

3 2

fixed-pt [improved]
by Neal Becker 01 Aug '08

01 Aug '08

Here is an improved version of fixed-pt, incorporating some of the suggestions given here:

5 4

[release] xpressive bug fix
by Eric Niebler 01 Aug '08

01 Aug '08

What are the chances that I'll be able to merge a bug fix to the release branch? This one: http://svn.boost.org/trac/boost/ticket/2157 just came in, and I've already fixed it on trunk. Assuming that the next cycle of the trunk tests don't show anything amiss, would I be permitted to merge the fix? The bug will not cause crashes, but it will lead to incorrect results when matching the end-of-line assertion ($) against internal line breaks, which is fairly common usage scenario. I have high confidence in the fix. These are the relevant changesets: http://svn.boost.org/trac/boost/changeset/47899 http://svn.boost.org/trac/boost/changeset/47901 -- Eric Niebler BoostPro Computing http://www.boostpro.com

2 3

1.36 documentation
by Daniel James 01 Aug '08

01 Aug '08

Hello everyone, Since the generated documentation isn't currently included in the snapshots, I've temporarily made it available here: http://www.calamity.org.uk/1.36/ Hopefully, the documentation should be integrated with the beta site soon after the beta release. Daniel

9 19

[swap] End-user allowed to add overloads to boost namespace?
by Niels Dekker - mail address until 2008-12-31 31 Jul '08

31 Jul '08

Is any end-user allowed to add her own overloads of existing Boost functions to the boost namespace? The boost::swap utility from Joseph Gauterin (recently moved to the trunk) allows the user to customize boost::swap for her class, by providing a swap function for her class within the namespace of the class. Internally boost::swap does the idiomatical "using std::swap; swap(left,right);", to allow finding such a user-provided swap function by argument-dependent lookup (ADL) <svn.boost.org/svn/boost/trunk/boost/utility/swap.hpp> Unfortunately some compilers don't fully supported ADL, as is shown by the mixed test results of swap/test/specialized_in_global.cpp and swap/test/specialized_in_other.cpp, at http://www.boost.org/development/tests/trunk/developer/utility-swap_.html ADL failures appear to occur for GCC 3.3.1 (PathScale), Intel C++ 8.1, MSVC 7.1 (2003), and Borland (up to 5.9.3). Once the boost::swap utility would be used by other Boost libraries, end users might want to add a custom overload of swap for their classes to the boost namespace. Especially when users would have to deal with lacking ADL support of their compiler. Would it be okay for them to do so? Or are there some moral objections, or technical issues, regarding a user-provided overload within the boost namespace? Kind regards, Niels PS Volodya, thanks for fixing swap/Jamfile.v2! -- Niels Dekker http://www.xs4all.nl/~nd/dekkerware Scientific programmer at LKEB, Leiden University Medical Center

6 14

boost versus Apple's gcc 4.2
by Mat Marcus 31 Jul '08

31 Jul '08

On the boost users list, there was a discussion about some issues arising with boost versus gcc-4.2 on Apple systems. One interesting issue arises from the fact that Apple decoupled the gcc compiler version from the lib version. They "own" libstdc++, which they've kept at version 4.0 even when the 4.2 compiler. This breaks some assumptions in boost headers. I am reposting on the main developer list: ### Peter Dimov wrote: > Is the new Apple GCC documented somewhere? I wasn't able to find anything > related to a new assembler syntax or -fasm-blocks. Can you ask Apple to > explain the issue? Stock g++ 4.2.x compiles the code, so the problem must be > Apple-specific. Ok, I've got a little bit more information on the Apple gcc 4.2 situation. Here is a snippet from an email dialog between a user and an apple compiler engineer: user appears below with with prefix ">>" apple compiler engineer appears below with with prefix ">" >> Thank you very much for the detailed reply. >> Based on your information I deduce: >> >> 1) Using gcc 4.2 with 4.0 (c++) libraries is a supported >> configuration by Apple > > Right. > >> I then conclude that the C++ ABI is fully compatible between 4.0 and >> 4.2 > > Right. [snip, then user hypothesizes as to why there are problems with boost under gcc 4.2/libstdc++ 4.0 on current Apple systems] >> This is the case because boost assumes that a 4.2 compiler implies >> 4.2 libraries in flies such as boost/detail/atomic_count_gcc.hpp: >> >> #if (__GNUC__ > 4) || ((__GNUC__ == 4) && (__GNUC_MINOR__ >= 2)) >> # include <ext/atomicity.h> >> #else >> # include <bits/atomicity.h> >> #endif > > Yes, this is a bug or faulty assumption in boost. [snip] > The 4.2 library issue is a bug in Boost, not a problem with > our compiler. I'd suggest raising the issue on one of the boost > mailing lists and see what they say. Comments? Mat

4 4

[1.36 beta] Beta release candidate available
by Beman Dawes 31 Jul '08

31 Jul '08

Release candidate tarballs for the 1.36 beta are available at http://boost.cowic.de/rc/ Special thanks to Daniel James for generating the docs. Hopefully we can get the doc generations problems fixed quickly so that we can get back on a nightly release snapshot generation running again. I'd like to get feedback before uploading these to SourceForge. Please post a reply indicating success or problems encountered, being sure to indicate your platform and which file you downloaded. Thanks, --Beman

5 8

The --toolset option
by Vladimir Prus 31 Jul '08

31 Jul '08

Okay, now it's my turn to propose something to sneak into 1.36.0 at the last minute. Fortunately, it's only documentation change. For quite a while, both getting-started, and bjam --help mentioned --toolset option. This in practice, resulted in folks getting wrong analogy and trying to use --variant=debug --link=shared, etc. We agreed (on Boost.Build list), in principle, that we better remove --toolset from documentation, and use 'toolset=' instead -- which has exactly the same effect. So, I would like to commit the following Jamroot change to HEAD and merge to release branch. Any objections? I also would like to see the issue filed against getting-started: http://svn.boost.org/trac/boost/ticket/2050 fixed, and can provide a patch assuming release manager is fine with having this doc tweak merged into release branch, too. Opinions? Thanks, Volodya

3 2

range_ex: status?
by Mathias Gaunard 30 Jul '08

30 Jul '08

I'm writing some piece of software working that does a lot of data structures traversal and that really needed filtering of traversal etc. I thought I'd get that from Boost.Range, but I was surprised to see Boost.Range provides very little: all the good stuff (the range-based algorithms and adaptors) are in another library, range_ex, which isn't in the main distribution yet. Will this library be included in Boost soon? It's really great. As for the open issues, here are my opinions: - Output ranges: don't adaptors already output ranges? - Two input ranges, or a range and an iterator?: two ranges can do more - For any algorithm foo(container, args...), if foo(args...) is valid then it should be called - Null-termination of C-style strings: Isn't that up to Boost.Range to decide whether it's a range or not?

18 104

add new category in libs/libraries.htm
by Emil Dotchevski 30 Jul '08

30 Jul '08

Any opinions on adding a new category in libs/libraries.htm, Error Reporting, containing static_assert and the exception lib? Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

4 12

[getting started][1.36] Please rebuild and merge.
by Daniel James 30 Jul '08

30 Jul '08

Please can somebody rebuild the getting started guide in trunk? Beman, is it be okay to merge this into the release branch? I've only updated the version numbers: http://svn.boost.org/trac/boost/changeset/47870/ I've also added a note to the release procedure wiki pages so hopefully this won't be missed in the future. thanks, Daniel

3 4

[hash] Broken link in docs
by John Maddock 30 Jul '08

30 Jul '08

While building the docs in /doc/ I see: Writing unordered/buckets.html for section(unordered.buckets) ID recommended on table: Methods for accessing the hash and equal... Writing unordered/hash_equality.html for section(unordered.hash_equality) ID recommended on table: Interface differences. Error: no ID for constraint linkend: unordered.rationale.equality_operator. ID recommended on table: Complexity Guarantees Writing unordered/comparison.html for section(unordered.comparison) Writing unordered/rationale.html for section(unordered.rationale) Looks like a broken link? John.

2 1