August 2006 - Boost-users - lists.preview.boost.org

bjam issues
by Daniel Krügler 01 Aug '06

01 Aug '06

Hello! Regrettably my posting "Labeling patched Boost versions" from 2006-07-21 got no response :-(( - so I would like to manipulate the boost bjam on my own to reach the effect that the build libraries will have a fixed character sequence suffix (aka "build id") but I got lost, when I tried this. My assumption was that I only need to modify Jamfile.v2 in the root directory where I found the promising rules beginning with line 92: # This rule is called by Boost.Build to determine the name of # target. We use it to encode build variant, compiler name and # boost version in the target name rule tag ( name : type ? : property-set ) { if $(type) in STATIC_LIB SHARED_LIB IMPORT_LIB { if $(layout) = versioned { name = [ stage.add-variant-and-compiler $(name) : $(type) : $(property-set) ] ; local version-tag = [ MATCH "^([^.]+)[.]([^.]+)" : $(BOOST_VERSION[1]) ] ; version-tag = $(version-tag:J="_") ; # On NT, library with version suffix won't be recognized # by linkers. On CYGWIN, we get strage duplicate symbol # errors when library is generated with version suffix. # On OSX, version suffix is not needed -- the linker expets # libFoo.1.2.3.dylib format. # AIX linkers don't accept version suffixes either. if [ $(property-set).get <os> ] in NT CYGWIN MACOSX AIX { return $(name:B)-$(version-tag)$(name:S) ; } else { return $(name:B)-$(version-tag)$(name:S).$(BOOST_VERSION) ; } } else { return [ stage.add-variant-and-compiler $(name) : $(type) : $(property-set) ] ; } } } Naively I just tried to add a fixed string to the returned name, e.g. # This rule is called by Boost.Build to determine the name of # target. We use it to encode build variant, compiler name and # boost version in the target name rule tag ( name : type ? : property-set ) { if $(type) in STATIC_LIB SHARED_LIB IMPORT_LIB { if $(layout) = versioned { name = [ stage.add-variant-and-compiler $(name) : $(type) : $(property-set) ] ; local version-tag = [ MATCH "^([^.]+)[.]([^.]+)" : $(BOOST_VERSION[1]) ] ; version-tag = $(version-tag:J="_") ; # On NT, library with version suffix won't be recognized # by linkers. On CYGWIN, we get strage duplicate symbol # errors when library is generated with version suffix. # On OSX, version suffix is not needed -- the linker expets # libFoo.1.2.3.dylib format. # AIX linkers don't accept version suffixes either. if [ $(property-set).get <os> ] in NT CYGWIN MACOSX AIX { return $(name:B)-$(version-tag)$(name:S)."A" ; } else { return $(name:B)-$(version-tag)$(name:S).$(BOOST_VERSION)."B" ; } } else { return [ stage.add-variant-and-compiler $(name) : $(type) : $(property-set)."C" ] ; } } } but that did not influence the resulting names of a new bjam build at all. Could someone please help a dump bjam beginner to reach the wanted effect, e.g. to attach a given fixed string constant like "M20060801" to all created libraries?? Thank you very much for your patience, Daniel Krügler

2 1

Re: [Boost-users] [multi_index] illegal indirection compile error
by JOAQUIN LOPEZ MU?Z 01 Aug '06

01 Aug '06

----- Mensaje original ----- De: Themistoklis Bourdenas <themis(a)ics.forth.gr> Fecha: Lunes, Julio 31, 2006 4:47 pm Asunto: [Boost-users] [multi_index] illegal indirection compile error > Could you help me understand what I'm doing wrong in the code > below? I'm > trying to setup a multi_index structure of class B. > > class A > { > const std::string& ID(void) const; > ... > }; > > class B : public A > { > ... > }; > > typedef boost::multi_index::multi_index_container< > B*, > boost::multi_index::indexed_by< > boost::multi_index::ordered_unique< > boost::multi_index::const_mem_fun<A, const > std::string&, &A::ID> > > > > > > BSet; > > However when I compile VS2005 returns me an "illegal indirection" > compile error. Any thoughts? Hello Themistoklis, You've found a limitation in Boost.MultiIndex (as of Boost 1.33.1) by which one cannot specifiy a key in a given base class and pass derived classes as elements. This is solved in what will become Boost 1.34, please read bullet 3 of Boost.MultiIndex release notes at: http://boost- consulting.com/boost/libs/multi_index/doc/release_notes.html#boost_1_34 Until this release is out, you can use the following workarond: simply define a custom key extractor like this (warning, I haven't compiled it, beware typos): struct pB_ID_extractor { typedef std::string result_type; const std::string& operator()(const B* pb)const { return pb->ID(); } }; typedef boost::multi_index::multi_index_container< B*, boost::multi_index::indexed_by< boost::multi_index::ordered_unique< pB_ID_extractor > > > BSet; Does this help? Thank you for using Boost.MultiIndex, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

[boost ::threads] Different behaviour between packaged and compiled version.
by Thierry Dumont 01 Aug '06

01 Aug '06

My code (a very small piece of code) uses boost:threads; It performs perfectly with the Debian Sarge version of boost,but segfaults with the version I installed myself (using bjam "-sTOOLS=gcc"). The Boost version I installed is: 1_33_1; Debian Sarge version is 1_32_06. I tried to runs the tests from inside the compiled 1_33_1 version: it works perfectly; but when I copy, say tennis.cpp, in an other directory, and compile and link it with version 1_33_1 (the one I compiled), it segfaults. I think it's only a question of compiler options. ->My options (which makes the program crash): -DBOOST_HAS_THREADS -DBOOST_HAS_PTHREADS -D_REENTRANT What is false? This works with Debian installed version. ->what are the options used by bjam when compiling the tests? I need a personnal version of boost (not the debian one) because I want to use the property tree library... yours t.d. -- Thierry Dumont. Institut Camille Jordan -- Mathematiques-- Univ. Lyon I,43 Bd du 11 Novembre 1918, 69622 - Villeurbanne Cedex - France. Thierry.Dumont(a)maply.univ-lyon1.fr web: http://maply.univ-lyon1.fr/~tdumont

3 3

in_edges inconsitency
by Louis Lavery 01 Aug '06

01 Aug '06

p219 of the BGL book says that in_edges(...) is available for bidirectional graphs but that in_degree(...) is not. Shouldn't both or neither be available? Louis.

2 1

boost.program_options gives ./first: free(): invalid pointer with g++ 4.0.3 and 4.1.0
by William Lederer 01 Aug '06

01 Aug '06

In compiling and testing the 'first.cpp' program from the example directory of the program_options directory, the program fails with the message: *** glibc detected *** ./first: free(): invalid pointer: 0x00000000005104e8 *** I built g++ version 4.1.0 and received the same result. The hardware is AMD opteron 64 bit, the OS is Linux fedora core 4. I had upgraded the compiler earlier to 4.0.3, and all other compiles/execution work fine and also tried 4.1.0 gcc. Nonetheless, I cannot shake the notion that this might be related to the compiler. Are there any ideas regarding what I might try next? Thanks -- William Lederer <wgl(a)ciexinc.com> CIEX, Incorporated

2 1

Re: [Boost-users] performance of template expression
by Sohail Somani 01 Aug '06

01 Aug '06

> -----Original Message----- > From: boost-users-bounces(a)lists.boost.org > [mailto:boost-users-bounces@lists.boost.org] On Behalf Of > divyank shukla > Sent: Monday, July 31, 2006 8:06 AM > To: boost-users(a)lists.boost.org > Subject: [Boost-users] performance of template expression > > snip.... > > My question is does the performance penalty still > exist with g++(4.1) compilers as against boost::lambda > functions. Where are your performance results (hard numbers)? Have you measured them as compared to the rest of your algorithm? For example, if you do the general QR decomposition, chances are that's going to be the slow part. One should usually profile after coding, rather than optimizing prematurely. Generally it's the algorithm that is slow.

2 1