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

Re: [Boost-users] [Pool] Problems using Boost.Pool with the Eigen matrix library
by lfrfly＠icqmail.com 22 Oct '10

22 Oct '10

>2010/10/14 <lfrfly(a)icqmail.com>: >> Since Eigen matrices and vectors use SSE and therefore require a particular >> alignment, Eigen requires that when these types (specifically, the >> compile-time sized versions) are within a struct or class, that struct be >> given the EIGEN_MAKE_ALIGNED_OPERATOR_NEW macro. > >What we do require is that e.g. Vector4f's be created at 16 byte >aligned locations. EIGEN_MAKE_ALIGNED_OPERATOR_NEW is just one way of >doing that. > >> >> But here's the problem. What if that struct is allocated by a >> boost::pool_allocator<T>? Is there any way to enforce alignment then? > >That's a question for boost::pool_allocator, not for us; if this >allocator doesn't give you 16 byte alignment, then you need a >different allocator (or just modify this allocator to meet this >criterion). > >The allocator is what gives you an address. If it's giving >non-16-byte-aligned addresses, then it can't be used. > >Benoit It's now clear that this question belongs firmly on the Boost.Pool side of the fence, so here it is---I'm wondering why boost::pool_allocator isn't designed to work with a standard-compliant allocator as its second template parameter? I tried creating a boost::fast_pool_allocator<T, Eigen::aligned_allocator<T>>, but this failed with a compile error----apparently fast_pool_allocator has an unusual notion of what concept a UserAllocator should satisfy, requiring the methods malloc() and free(). Why does it not accept any standard allocator, which will instead provide allocate() and deallocate()? This seems like a serious shortcoming.

1 0

building boost with the windows sdk 7.1
by Sean Farrow 22 Oct '10

22 Oct '10

Hi: I need to build boost with the windows sdk v7.`1. I've got vs2010 (10.0) instaloled and the sdk. If there anything specific I need to do to build with 7.1 as aposed to 7.0? Cheers Sean.

4 3

Re: [Boost-users] [boost] What's so cool about Boost.MPI?
by Brian Wood 22 Oct '10

22 Oct '10

>At Thu, 21 Oct 2010 14:25:38 -0500, >Brian Wood wrote: >> >> David Abrahams: >> > Which yields huge performance benefits and makes practical some >> > computations that might otherwise not be, due to resource constraints >> >> I've been exploring this further here - >> http://www.gamedev.net/community/forums/topic.asp?topic_id=585405 >> >> Also, from what I can tell, MPI messages are composed of one >> data type or an array of one type. > > Maybe, but the library lets you easily make arbitrarily complex data > types (described to MPI as MPI type maps). Right, I don't deny that. > >> If that's the case, I'd argue there's room for more coolness. > >What more do you want? Here's an example from my work. I have a three-tier architecture: C++ Middleware Writer (server) | C++ Middleware Writer Ambassador (server) | command line program that exits I'll introduce a struct that I don't currently use, but that might make this easier to follow. struct RequestData { uint32_t accountNumber; uint32_t transactionNumber; std::vector<File> includeFiles; std::auto_ptr<File> middleFile; uint32_t userOptions; }; I could use that to send a message, but being forced to receive those fields as a unit would be detrimental to the implementation of the C++ Middelware Writer. The account number is used to determine how the files are received. A directory is associated with each account. If I couldn't break the account number out of there, I'd have to receive the files into a temporary directory and then move them into the right directory later and get rid of the temporary directory. So I do it something like this: struct TransactionData { uint32_t transactionNumber; std::vector<File> includeFiles; std::auto_ptr<File> middleFile; uint32_t userOptions; }; That's the same as RequestData, but the account number field has been removed. This middle code describes how the message is sent (@out) and received (@in): (uint32_t, TransactionData) @out @msg_id_direct (uint32_t) @in (TransactionData) @in The sending process sends 2 items as one message. The receiving process receives the message in two steps. First it gets the account number as a uint32_t which it uses to receive the balance of the message. I believe accomplishing the same thing with MPI would involve two message ids (tags) and would require more work to be certain that the messages are sent and received in the correct order. There's needless overhead associated with the additional message id and the programming is more involved to make sure everything is kosher. -- Brian Wood Ebenezer Enterprises http://webEbenezer.net (651) 251-9384

2 1

Printer Friendly Proto
by Hossein Haeri 22 Oct '10

22 Oct '10

Dear all, How can I get a printer friendly version of the complete Proto documentation? http://boost.org/doc/libs/1_44_0/doc/html/proto.html A PDF version say? (I'm going to read it in bus, bus-stop, etc etc. So, the webpage is not very useful without internet connection. Furthermore, I take it that Chapter 15 of the Boost book is now completely outdated...) TIA, --Hossein

2 1

asio UDP message packet loss even on localhost?
by Ákos Maróy 22 Oct '10

22 Oct '10

Hi, I'm having a very basic issue: when sending a large number of UDP messages in short succession via boost::asio, even to localhost, after a few hundred messages, there seems to be a serious loss. please see a sample code here: http://pastebin.com/Bq0DnkeG the output I get is the following: $ ./async_asio 0 1 2 3 ... 939 940 941 942 943 944 958 983 1013 1049 1093 1151 1234 1363 1576 1943 b sent 2000 messages a received 955 messages so, basically while 2000 messages were sent over, only up to 944 were received so that all of them are, an then there are only sporadic messages received afterwards - a total of 955. while I understand UDP is not guaranteed to be sent over, such a level of unreliability to the localhost interface seems to be quite troublesome.. what am I doing wrong? Akos

7 14

Boost.MPI build problem: auto-configuration fails
by Kondov, Ivan 22 Oct '10

22 Oct '10

Hi, I would like to build boost.mpi from boost/1.43.0 with gcc/4.4.4, openmpi/1.4.2 on GNU/Linux 2.6.18-128.1.14.el5.8hp.2sp SMP x86_64 bjam always skips the MPI section (see below). Adding a line in user-config.jam "using mpi : /software/all/openmpi/1.4.2/bin/mpiCC ;" or "using mpi : /software/all/openmpi/1.4.2/bin/mpic++ ;" does not change the result: username@host:~/boost/boost_1_43_0$ bjam -v Boost.Jam Version 3.1.18. OS=LINUX. username@host:~/boost/boost_1_43_0$ bjam --with-mpi warning: No toolsets are configured. warning: Configuring default toolset "gcc". warning: If the default is wrong, your build may not work correctly. warning: Use the "toolset=xxxxx" option to override our guess. warning: For more configuration options, please consult warning: http://boost.org/boost-build2/doc/html/bbv2/advanced/configuration.html Building the Boost C++ Libraries. warning: skipping optional Message Passing Interface (MPI) library. note: to enable MPI support, add "using mpi ;" to user-config.jam. note: to suppress this message, pass "--without-mpi" to bjam. note: otherwise, you can safely ignore this message. Component configuration: - date_time : not building - filesystem : not building - graph : not building - graph_parallel : not building - iostreams : not building - math : not building - mpi : building - program_options : not building - python : not building - random : not building - regex : not building - serialization : not building - signals : not building - system : not building - test : not building - thread : not building - wave : not building ...found 1 target... The Boost C++ Libraries were successfully built! The following directory should be added to compiler include paths: ......................../username/boost/boost_1_43_0 The following directory should be added to linker library paths: ......................../username/boost/boost_1_43_0/stage/lib username@host:~/boost/boost_1_43_0$ which mpic++ /software/all/openmpi/1.4.2/bin/mpic++ username@host:~/boost/boost_1_43_0$ mpic++ -v Using built-in specs. Target: x86_64-linux-gnu Configured with: ../gcc-4.4.4/configure --enable-threads=posix --enable-shared --prefix=/software/all/gcc/4.4.4 --enable-languages=c,c++,fortran,java --enable-checking=release --with-tune=generic --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu --with-gmp=/software/all/gcc_infrastructure/gmp/4.3.2 -with-mpfr=/software/all/gcc_infrastructure/mpfr/2.4.2 --with-ppl=/software/all/gcc_infrastructure/ppl/0.10.2 --with-cloog=/software/all/gcc_infrastructure/cloog-ppl/0.15.9 Thread model: posix gcc version 4.4.4 (GCC) Many thanks in advance for any help! Best regards, Ivan

2 4

[boost] What's so cool about Boost.MPI?
by Brian Wood 22 Oct '10

22 Oct '10

David Abrahams: >At Tue, 19 Oct 2010 16:26:04 +0200, >Thorsten Ottosen wrote: >> >> The semi-automatic, but very easy to maintain, way of >> creating/maintaining the MPI type maps (via Boost.Serialization), >> IIUC. > Which yields huge performance benefits and makes practical some > computations that might otherwise not be, due to resource constraints I've been exploring this further here - http://www.gamedev.net/community/forums/topic.asp?topic_id=585405 Also, from what I can tell, MPI messages are composed of one data type or an array of one type. If that's the case, I'd argue there's room for more coolness. Brian Wood Ebenezer Enterprises http://webEbenezer.net

3 2

Re: [Boost-users] foreach question
by Pete Bartlett 21 Oct '10

21 Oct '10

Rob Riggs wrote: > On 10/15/2010 12:27 PM, Neal Becker wrote: >> The following loop iterates over strings in result (which >> comes from boost::split). Is there a way to include the integer >> enumerator 'col' into the FOREACH loop? >> >> In python that would be spelled >> for col,s in enumerate (result): >> ... >> >> int col = 0; >> BOOST_FOREACH (std::string s, result) { >> H(row, col) = boost::lexical_cast<int> (s); >> ++col; >> } >> > > >Something like: > >template <typename Range> >auto make_counting_range(Range& range, size_t start = 0 >[..] > >would then give you: > > BOOST_FOREACH(auto t, make_counting_range(result)) > { > using boost::tuples::get; > H(row, get<0>(t)) = boost::lexical_cast<int>(get<1>(t)); > } > >(Compiled with GCC 4.4.) Even without C++0x, you can wrap this up into a reasonable interface to get e.g. std::vector<std::string> data = boost::assign::list_of("foo")("bar")("baz"); BOOST_INDEXED_EACH( std::size_t i , std::string const& s , data ) std::cout << "\n" << i << " " << s; if you tinker a little bit with BOOST_FOREACH internals - see code below, compiled on vc10 with Boost.ForEach code as in 1.43. However for the same reasons that BOOST_REVERSE_FOREACH exists (rather than just using BOOST_FOREACH( ... , make_reverse_range(r) ) - see http://lists.boost.org/boost-users/2007/07/29101.php ) this approach doesn't play well with rvalue ranges. Instead you'd have to duplicate the guts of FOREACH, as Eric did for REVERSE_FOREACH, to get a library-quality version. Pete #include <boost/range/begin.hpp> #include <boost/range/end.hpp> #include <boost/range/distance.hpp> #include <boost/range/iterator_range.hpp> #include <boost/iterator/zip_iterator.hpp> #include <boost/iterator/counting_iterator.hpp> template< typename Range > struct indexed_range { typedef boost::counting_iterator<std::size_t> it0_type; typedef typename boost::range_iterator< Range >::type it1_type; typedef boost::tuple< it0_type , it1_type > tuple_type; typedef boost::zip_iterator< tuple_type > zip_type; typedef boost::iterator_range< zip_type > type; }; template< typename Range > typename indexed_range<Range>::type make_indexed_range(Range& range , std::size_t start = 0) { return make_iterator_range( boost::make_zip_iterator( boost::make_tuple( boost::counting_iterator<size_t>(start), boost::begin(range))), boost::make_zip_iterator( boost::make_tuple( boost::counting_iterator<size_t>( boost::distance(range) + start), boost::end(range)))); } #include <boost/foreach.hpp> #define BOOST_INDEXED_EACH_IMPL(VAR1, VAR2 , COL) \ BOOST_FOREACH_PREAMBLE() \ if (boost::foreach_detail_::auto_any_t BOOST_FOREACH_ID(_foreach_col) = BOOST_FOREACH_CONTAIN(COL)) {} else \ if (boost::foreach_detail_::auto_any_t BOOST_FOREACH_ID(_foreach_cur) = BOOST_FOREACH_BEGIN(COL)) {} else \ if (boost::foreach_detail_::auto_any_t BOOST_FOREACH_ID(_foreach_end) = BOOST_FOREACH_END(COL)) {} else \ for (bool BOOST_FOREACH_ID(_foreach_continue) = true; \ BOOST_FOREACH_ID(_foreach_continue) && !BOOST_FOREACH_DONE(COL); \ BOOST_FOREACH_ID(_foreach_continue) ? BOOST_FOREACH_NEXT(COL) : (void)0) \ if (boost::foreach_detail_::set_false(BOOST_FOREACH_ID(_foreach_continue))) {} else \ for (VAR1 = boost::tuples::get<0>( BOOST_FOREACH_DEREF(COL) ); !BOOST_FOREACH_ID(_foreach_continue);)\ for(VAR2 = boost::tuples::get<1>( BOOST_FOREACH_DEREF(COL) ); !BOOST_FOREACH_ID(_foreach_continue); BOOST_FOREACH_ID(_foreach_continue) = true) #define BOOST_INDEXED_EACH(VAR1,VAR2,COL) BOOST_INDEXED_EACH_IMPL(VAR1,VAR2,make_indexed_range(COL)) //test scaffolding #include <vector> #include <iostream> #include <boost/assign/list_of.hpp> int main() { std::vector<std::string> data = boost::assign::list_of("foo")("bar")("baz"); BOOST_INDEXED_EACH( std::size_t i , std::string s , data ) std::cout << "\n" << i << " " << s; std::cout << "\n\n"; return 0; }

1 0

exception type thrown by ip::address::from_string()
by Alan Vella 21 Oct '10

21 Oct '10

Hi all, I've started working with the Boost ASIO library and came across a problem. I'm trying to catch exceptions thrown by boost::asio::ip::address::from_string(const std::string & str) but I don't know what the type of the exception that I should catch is. I can find no mention of this in the boost reference. Any help would be appreciated. Many thanks, Alan _______________________________________________________ Unlimited Disk, Data Transfer, PHP/MySQL Domain Hosting http://www.doteasy.com

2 1

Can't link subgraphs because remove_vertex is a TODO
by Trevor Harmon 21 Oct '10

21 Oct '10

Hi, I have two directed subgraphs that I want to link together in a particular way. To illustrate: BEFORE 1 ---> 2 ---> 3 4 ---> 5 ---> 6 AFTER 1 ---> 2 ---> 3 \---> 5 ---> 6 Note that vertex 4 is removed, and the edge that was linking 4 to 5 now links 1 to 5. Seems simple enough, but there are two problems, one minor and one major: 1) To rewire the edge's source from 4 to 1, I'd like to simply change the edge's source. But that doesn't seem possible in Boost. It appears I must remove the edge and add a new one with the desired source. This can get complicated when it comes to preserving the edge's properties, index maps, and such, but hey, at least it's doable. 2) This one I can't work around. Calling remove_vertex on a subgraph gives an assertion failure: Assertion failed: (false), function remove_vertex, file /usr/local/ boost_1_43_0/boost/graph/subgraph.hpp, line 733. It turns out that subgraph's remove_vertex method is not implemented at all, which is quite the showstopper for my project. I don't know enough about Boost to implement it myself. Any suggestions? Thanks, Trevor

2 6