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

Problems with boost build setup
by Michael Buksas 31 Jan '04

31 Jan '04

Hi all, I'm having newbie problems with linking against Boost libraries. Here's the situation: I can build the boost libraries without problem, and I'm using the default toolkit for my system, (Fedora Core 1) which is g++. Compiling is no problem, just linking. I can link the object files by hand, but not as part of using Boost.build. As a test, I grabbed an example program from the date_time library and it's corresponding build rule. This code compiles fine as part of Boost, but if I move it to my project space, I get linking errors. Here's my Jamfile: exe time_math : <lib>$(BOOST_ROOT)/build/boost_date_time time_math.cpp : <include>$(BOOST_ROOT) <define>BOOST_DATE_TIME_POSIX_TIME_STD_CONFIG ; and here's my Jamrules in the same directory: project-root ; path-global BOOST_ROOT : "/opt/boost-1.30.2" ; Here's the Jamfile from /opt/boost-1.30.2/libs/date_time/example/ exe time_math : <lib>../build/boost_date_time posix_time/time_math.cpp : <include>$(BOOST_ROOT) <define>BOOST_DATE_TIME_POSIX_TIME_STD_CONFIG ; And the environment variable is set: BOOST_BUILD_PATH=/opt/boost-1.30.2/tools/build When I run bjam from a clean build, here's what I get: gcc-C++-action bin/time_math/gcc/debug/runtime-link-dynamic/time_math.o gcc-Link-action bin/time_math/gcc/debug/runtime-link-dynamic/time_math bin/time_math/gcc/debug/runtime-link-dynamic/time_math.o(.gnu.linkonce.t._ZN5boost9date_time15month_formatterINS_9gregorian10greg_monthENS0_13simple_formatEE12format_monthERKS3_RSo+0x3a): In function `boost::date_time::month_formatter<boost::gregorian::greg_month, << edited for brevity >> In function `boost::date_time::month_formatter<boost::gregorian::greg_month, << edited for brevity >> collect2: ld returned 1 exit status export LD_LIBRARY_PATH g++ -g -o "bin/time_math/gcc/debug/runtime-link-dynamic/time_math" "bin/time_math/gcc/debug/runtime-link-dynamic/time_math.o" -Wl,-rpath-link,. ...failed gcc-Link-action bin/time_math/gcc/debug/runtime-link-dynamic/time_math... ...failed updating 1 target... So things are compiling, but not linking. I must not have the configuration for Boost.build correct, but I've tried everything I can think of. Any help would be appreciated. Thanks, Mike Buksas -- Michael Buksas -- michael(a)buksas.net -- www.buksas.net

2 1

Properties in a subgraph
by Hugues Joly 30 Jan '04

30 Jan '04

Hi, I'd like to clarify a point about the graph properties accessed through a subgraph. According to the documentation of get(PropertyTag, subgraph& g): vertex and edge properties are shared by all subgraphs, so changes to a property through a local vertex descriptor for one subgraph will change the property for the global vertex descriptor, and therefore for all other subgraphs (c.f. boost-1.30.2/libs/graph/doc/subgraph.html). Here, I'm sending you a small program inspired by the boost-1.30.2/libs/graph/example/subgraph.cpp example. >From its behavior, it seems that: 1) A property value is not shared between the global descriptor and its corresponding local descriptors. 2) we need to initialize property values for each of the subgraphs. For example, if I set a name "A" for the global vertex descriptor A, that property is not seen through the corresponding local vertex descriptors. Is this a case of misuse or is it a bug? __________________________________________________________ Lèche-vitrine ou lèche-écran ? magasinage.yahoo.ca

2 2

Re: [Boost-users] Using boost::format with Lambda expressions
by Shawn Church 29 Jan '04

29 Jan '04

Jaakko Jarvi (jajarvi(a)cs.indiana.edu) wrote: > Lambda and format don't play well together, I noticed :( > Here's a code that works however, with some explanation. > Not pretty. > > Best, Jaakko > ... > format f("%-10s|") ; > for_each(Foos.begin(), Foos.end(), > cout << ret<format&>(var(f) % bind(&foo::name, _1))); > > } > > // format defines operator% as a member, which takes precedence over > // % defined by lambda. Therefore one must make the format object to > // be a lambda functor. var does that. > // Var, however, cannot take a temporary object (it holds a reference to > // the wrapped object). That's why the variable f. > // ret<format&> informs lambda about the return type of formats % operator. OK, that is just what I was looking for, thanks!!! I tried all of those things but not in the right combination. Is there any resources (i.e. example programs or additional documentation) available for the lambda library. I have read through the test code already. Thanks,

2 1

Using boost::format with Lambda expressions
by Shawn Church 29 Jan '04

29 Jan '04

I may be missing something simple here but I have tried everything I can think of and cannot get the following to work (simplified from a project I am working on): Given a class such as: class foo{ public: foo(const char* name): _name(name) {} const char* name() const {return _name.c_str();} private: std::string _name;}; I can do the following without any problems: std::vector<foo> Foos; ... for_each(Foos.begin(), Foos.end(),cout << bind(&foo::name, _1) << "|"); This prints a list of all the names in the vector of Foo objects by calling the Foo::name() method. It would be nice to be able to do something like the following: for_each(Foos.begin(), Foos.end(), cout << format("%-10s|") % bind(&foo::name, _1); I have tried everything I can think of including extending the return type deduction of the lambda library to include the "%" operator as used by format and binding directly to the basic_format::operator% method. In every case I get 40 or so compile errors explaining why my 30 character statement is wrong :-) Does anyone have an example of this usage that works? This is not a high priority as I can obviously just format the value returned by the Foo::name() method but it would be nice to have this technique available when the need arises. I adapated the code above from a test program that demonstrates the problem in detail. I can provide the test program if anyone is interested (just tell me what to do with it). Thankyou for any help you can provide, Shawn Church sl_church(a)sbc_global.net

4 3

Storing vertex objects and edge objects in a BGL graph?
by Hugues Joly 29 Jan '04

29 Jan '04

Hi, I'd like to know if it's possible to create a BGL graph that uses custom-made classes for the nodes and the edges. While looking to your documentation, I came across the following: "Many graph representations (such as adjacency lists) do not store actual vertex objects, while others do (e.g., pointer-linked graphs)." (c.f. boost-1.30.2/libs/graph/doc/quick_tour.html) Is the pointer-linked graph implementation supplied from boost or do I have to create one and use external adaptation for using it with your library? Thanks in advance. __________________________________________________________ Lèche-vitrine ou lèche-écran ? magasinage.yahoo.ca

2 3

1.31.0??
by Phil Hornby 29 Jan '04

29 Jan '04

Hi all, Just wondering when a release of 1.31.0 is planned for? Thanks... -- Phil "Requirements - what are they I just hack something together that does what I think they want" ;)

2 3

RE: [Boost-users] Re: MultiArray questions
by Ben Hutchings 28 Jan '04

28 Jan '04

Dr Mark H Phillips <mark(a)austrics.com.au> wrote: > On Sun, 2004-01-25 at 04:47, garcia wrote: <snip> > > >Why can't you change the != into <? Ie, do: > > > > > > for(index i = 0; i < 3; ++i) > > > for(index j = 0; j < 4; ++j) > > > for(index k = 0; k < 2; ++k) > > > A[i][j][k] = values++; > > > > > >or can you? This would be more efficient I should think, and > > >requiring that index types be ordered shouldn't be too onerous > > >should it? > > > > > You can change the != into a < if you like. I don't see any > > good reason why one should be more efficient than the other. I > > personally use != because it more closely matches how I write > > for loops using iterators. > > So in short, that's a matter of personal preference. > > I would have thought < was more efficient. Isn't "i != j" > implemented, at machine level, more or less by "i > j || i < j". > So one compare would be cheaper than two. Or have I got this > wrong? <snip> A test for i != j typically compiles to an instruction sequence like: CISC: RISC: CMP j,i LD r1,i BEQ test_failed LD r2,j SUB. r0,r1,r2 BEQ test_failed (CMP is a subtraction which doesn't store its result but sets condition flags. BEQ is branch-if-equal. RISC processors need to have all arithmetic operands in registers, but generally they have a lot of registers so the variables may well be in registers already, making the LDs unnecessary.) A test for i < j (assuming i and j are unsigned) would be like: CISC: RISC: CMP i,j LD r1,i BCC test_failed LD r2,j SUB. r0,r2,r1 BCC test_failed (BCC is branch-if-carry-flag-clear. Order of arguments varies between assembly languages, so don't worry too much about that.) These instruction sequences usually have identical timing properties (the exact time taken depends on caching and branch prediction). Theoretically, an architecture which had a combined comparison and conditional branch could make != a little faster since it requires only bitwise comparison whereas < requires carrying between bits (longer signal propagation time). However, the world is moving away from such architectures - even x86 processors are designed to make the simple instructions run fast, not the complex ones. For a generic algorithm that uses iterators, comparing with < requires that the iterators be random-access. If this isn't essential to the algorithm, it would be better to use !=. So it's a good habit to use i != j as the loop condition if i can definitely never be greater than j.

2 1

Using boost::shared_ptr<> with G++'s -fno-rtti
by Jonathan Lennox 28 Jan '04

28 Jan '04

Is it possible to use boost::shared_ptr<> without RTTI being enabled? I'm trying to port some code to the Sharp Zaurus, and its GUI libraries are all compiled with the G++ flags -fno-exceptions -fno-rtti. Boost seems to support the former flag just fine, but has problems with the latter: g++ -g -O2 -Wall -fno-rtti -fno-exceptions -o sipua/main.o -c ../sipua/main.cpp In file included from ../libcine/boost/shared_ptr.hpp:27, from ../rtplib++/rtptypes.h:8, from ../rtplib++/rtpsession.h:14, from ../sipua/radio.h:11, from ../sipua/main.cpp:18: ../libcine/boost/detail/shared_count.hpp: In member function `virtual void* boost::detail::sp_counted_base_impl<P, D>::get_deleter(const std::type_info&)': ../libcine/boost/detail/shared_count.hpp:267: error: cannot use typeid with -fno-rtti In file included from ../rtplib++/rtptypes.h:8, from ../rtplib++/rtpsession.h:14, from ../sipua/radio.h:11, from ../sipua/main.cpp:18: ../libcine/boost/shared_ptr.hpp: In function `D* boost::get_deleter(const boost::shared_ptr<U>&)': ../libcine/boost/shared_ptr.hpp:431: error: cannot use typeid with -fno-rtti What is the typeid call in the get_deleter functions doing? Is there any way to work around or disable this? Thanks. -- Jonathan Lennox lennox at cs dot columbia.edu

2 2

Disabling synchronization in Boost.Thread
by Aaron W. LaFramboise 28 Jan '04

28 Jan '04

Hi, Is there some easy way to disable all of the synchronization primatives in Boost.Thread, or in other words, make them all no-ops? I have written some generic code to be used in both singlethreaded and multithreaded environments, and it would be convenient for me to simply be able to 'switch off' synchronization when I know that I am in a singlethreaded environment, without having to uglify my code with ifdef's or similar. Simply disabling threads in Boost seems to cause synchronization primatives to fail to compile at all. Aaron

3 2

Re: MultiArray questions
by garcia 28 Jan '04

28 Jan '04

Dr Mark H Phillips <mark(a)austrics.com.au> wrote: >Hi, > >I've recently found out about the existence of MultiArray and I >am quite impressed! I was thinking of implementing something >similar myself but now hopefully I don't have to! However I have >a few questions that I'm hoping someone can answer. > > > Hi Mark. Thank you for the compliments on MultiArray. I hope that it meets your needs, and if not, I hope I can be of some service. >Question 1 >---------- > >In the user documentation there is an example which has >some example code: > > for(index i = 0; i != 3; ++i) > for(index j = 0; j != 4; ++j) > for(index k = 0; k != 2; ++k) > A[i][j][k] = values++; > >Why can't you change the != into <? Ie, do: > > for(index i = 0; i < 3; ++i) > for(index j = 0; j < 4; ++j) > for(index k = 0; k < 2; ++k) > A[i][j][k] = values++; > >or can you? This would be more efficient I should think, and >requiring that index types be ordered shouldn't be too onerous >should it? > > > You can change the != into a < if you like. I don't see any good reason why one should be more efficient than the other. I personally use != because it more closely matches how I write for loops using iterators. So in short, that's a matter of personal preference. >Question 2 >---------- > >If I use the built-in "no-frills" C array type to represent a >2-dimensional array in row-major order, then I would access >an element (i, j) by doing: > > a[ &a[0] + i*n + j ] > >where a is my m by n array. And if I wish to traverse a, in >row-major order, I can do: > > for (int* ip=&(a[0]); ip<&(a[n*m]); ip+=n) { > for (int* ijp=&(ip[0]); ijp<&(ip[n]); ++ijp) { > visit(ijp); > } > } > >These are a very efficient ways of doing things, but it lacks >somewhat in ease-of-generalization and in readbility. This is where >the MultiArray library is useful. But do I lose in efficiency by >going to MultiArray? Ie, in the simple case where base is 0, stride >is 1, and when we traverse in row-major order, is the MultiArray >library smart enough to do compile-time optimizations to generate >code which is as efficient as the above? > > > The MultiArray implementation doesn't currently do anything special for the case that the base is 0. I'm in the midst of doing some performance analysis on the library, and so far, to be honest, it looks like there is a performance hit. I'm investigating what is happening, and I hope to translate my findings into performance improvements. I would liket hose to be available by May of this year. >Is it possible to construct a new >multi_array/multi_array_ref/const_multi_array_ref from an array_view >by doing a deep copy of the view? > >A view is a nice way of looking at different parts of a MultiArray >object in a readable way, but sometimes you might wish to turn this >view into a more-efficiently represented object. Is this easy to do >in the MultiArray library? > > It is my intention that a new multi_array be constructible from an existing view, but on looking back through my code and test cases, the library does not currently support it. This is an oversight on my part. I hope to have this functionality available in CVS by the end of this coming week (which coincides with the end of the month). I'm afraid that the functionality won't make the upcoming Boost release however. >Question 4 >---------- > >Sometimes you might have an object starts off being mostly >accessed in row-major order, so you want a representation which works >efficiently for this use. But down the track you might wish to change >to mostly column-major access. Does MultiArray provide easy ways to >transform from one underlying representation to another? > > > There is no direct means to change the underlying representation of an existing array. The layout of an array is determined at construction. You can however assign a row-major multi_array to a column-major multi_array. >Thanks, > > > My pleasure. Thank you for your questions and comments. Incidentally, I am now subscribed to Boost-Users. I apologize for any discussion I have missed or inaccessibility resulting from my absence. Cheers, ron

2 1