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

[mpi] linking MPI with MPICH2 under Cygwin
by Murphy, John T. 05 Sep '12

05 Sep '12

Hello, I'm getting a very consistent problem trying to link with the Boost.MPI library and MPICH2 under Cygwin. What seems to be happening is that the libboost_mpi library that is created contains redundant copies of elements from the MPI libraries. For example: It is possible to add debugging code to MPICH2 source code, build MPICH2, build Boost's mpi library against this, then compile, link, and run an executable, with the result that the debugging code is output from the MPICH functions. Then it is possible to modify the MPICH debugging code and rebuild MPICH2, but leave Boost's mpi library so that it is _not_ rebuilt. When the executable is rebuilt and linked to the boost and MPICH libraries, the output indicates that some of the old versions of the debugging code are still being used while other functions have the new code. The error I am getting is 'Attempting to use an MPI routine before initializing MPICH'. My debugging suggests that during execution there are two distinct copies of the MPICH flag that indicates that MPICH has been initialized; one of these shows that the MPI_Init initialization has been run but the other does not. Additionally, an MPI program that contains no reference to boost and that compiles and runs cleanly when linked only with the MPICH libraries will crash with the same error if the linker is instructed to link against the boost mpi library, even though nothing in the boost namespace appears in the code. Has anyone seen this, or have a solution? The issue seems to be something that is happening with linking while the Boost.mpi library is being built, part of which is being done by bjam (aka b2). Is it possible to specify how boost's mpi library will be built and linked against the MPICH libraries, and if so is there a strategy I can use to avoid the problems I am having? I'm using Boost 1.48 for compatibility with other code we're using. I have the same code built and running on other systems; the error seems to be specific to the Cygwin environment. Thanks, John -- John T. Murphy Computational Postdoctoral Fellow Decision and Information Sciences and Argonne Leadership Computing Facility Argonne National Laboratory jtmurphy(a)anl.gov

1 0

BGL: d_ary_heap_indirect duplicated values
by David Doria 05 Sep '12

05 Sep '12

I am using a d_ary_heap_indirect as a priority queue using a property map to store the priorities. However, I when I change the values in the priority property map and push vertices that are already in the queue into the queue again, it results in kind of an invalid state where the vertex appears in the queue twice at different positions. Here is a demo: http://programmingexamples.net/wiki/CPP/Boost/BGL/IndirectPriorityQueue It simply sets random priority values for every vertex, and pushes them all into the queue. It then does exactly the same thing again. You can see that some vertices appear twice in the queue at different positions. For example, vertex (3,0) occurs at position 0 in the queue, and again at position 6. Of course the priority values that are output are the same because the demo simply outputs the values that are currently in the priority property map, but I guess I would expect the two instances of a vertex to appear at back-to-back positions in the queue (as it should have used their current value to sort the queue)? Is there a way to replace a vertex in the queue when it is pushed instead of adding a second one? (like an std::set instead of the current behavior which is like std::multiset)? Thanks, David

3 17

asio: question regarding design
by Goran 05 Sep '12

05 Sep '12

Hi all, I wanna change the design of some async client (code at end of this message) towards something like "run as a server and pull a message from another server". The so called "another server" will be my master server in future. At the moment I'm taking some example from asio's documentation: http://www.boost.org/doc/libs/1_46_1/doc/html/boost_asio/tutorial/tutdaytim… The async client is derived from another example of asio's documentation: http://www.boost.org/doc/libs/1_46_1/doc/html/boost_asio/example/http/clien… My simple question is: How would you change the code below to run in a loop and pulls 'let's say' every second a message from master server? Thanks a lot! #include <iostream> #include <istream> #include <ostream> #include <string> #include <boost/asio.hpp> #include <boost/bind.hpp> using boost::asio::ip::tcp; class client { public: client(boost::asio::io_service& io_service, const std::string& server, const std::string& port) : resolver_(io_service), socket_(io_service) { // Start an asynchronous resolve to translate the server and service names // into a list of endpoints. tcp::resolver::query query(server, port); resolver_.async_resolve(query, boost::bind(&client::handle_resolve, this, boost::asio::placeholders::error, boost::asio::placeholders::iterator)); } private: void handle_resolve(const boost::system::error_code& err, tcp::resolver::iterator endpoint_iterator) { if (!err) { // Attempt a connection to each endpoint in the list until we // successfully establish a connection. tcp::endpoint endpoint = *endpoint_iterator; socket_.async_connect(endpoint, boost::bind(&client::handle_connect, this, boost::asio::placeholders::error)); } else { std::cout << "Error: " << err.message() << "\n"; } } void handle_connect(const boost::system::error_code& err) { if (!err) { // The connection was successful. Read the response. boost::asio::async_read(socket_, response_, boost::bind(&client::handle_response, this)); } else if (err != boost::asio::error::eof) { std::cout << "Error: " << err.message() << "\n"; } } void handle_response() { if (response_.size() > 0) std::cout << "Response: " << &response_; else std::cout << "Response is empty." << std::endl; } tcp::resolver resolver_; tcp::socket socket_; boost::asio::streambuf request_; boost::asio::streambuf response_; }; int main(int argc, char* argv[]) { try { if (argc != 3) { std::cout << "Usage: async_client <server> <port>\n"; std::cout << "Example:\n"; std::cout << " async_client localhost 2020\n"; return 1; } boost::asio::io_service io_service; client c(io_service, argv[1], argv[2]); io_service.run(); } catch (std::exception& e) { std::cout << "Exception: " << e.what() << "\n"; } return 0; }

1 0

Re: [Boost-users] compilation problems with thread/chrono & boost 1.51 & HPUX
by Avi Bahra 05 Sep '12

05 Sep '12

>Le 04/09/12 11:44, Avi Bahra a ?crit : >>>> On 3.9.2012. 10:26, Avi Bahra wrote: >>>>> Can any one suggest *any* hacks/workarounds that gets me pass these errors. >>>>> Is it possible to use gcc on HPUX with boost 1.51 ? >>>> The docs for boost thread 1.51 say this: >>>> >>>> Boost.Thread uses by default Boost.Chrono for the time related >>>> functions. For backward compatibility and also for compilers that don't >>>> work well with Boost.Chrono the user can define >>>> BOOST_THREAD_DONT_USE_CHRONO. If BOOST_THREAD_DONT_USE_SYSTEM is defined >>>> then BOOST_THREAD_DONT_USE_CHRONO is defined implicitly. >>>> >>>> BOOST_THREAD_USES_CHRONO is defined when Boost.Thread uses Boost.Chrono. >> I have already tried BOOST_THREAD_DONT_USE_CHRONO and it has no effect. >> It appears that some of headers files are not guarded with this. >> >> In my case >> $BOOST_ROOT/boost/chrono/system_clocks.hpp >This evidently should not be included. Could you point from where it is >included? libs/chrono/src/chrono.cpp fails to compile with errors in system_clocks.hpp and overflow_helpers.hpp >> $BOOST_ROOT/boost/ratio/detail/overflow_helpers.hpp >This evidently should not be included. Could you point from where it is >included? libs/chrono/src/chrono.cpp fails to compile with errors in system_clocks.hpp and overflow_helpers.hpp libs/chrono/src/process_cpu_clocks.cpp fails to compile with error in overflow_helpers.hpp >> $BOOST_ROOT/boost/thread/future.hpp >Could you point where in this file the compiler fails? >> do not compile, >> "libs/thread/src/future.cpp" >> >> Also Is it possible to make a request to change: >> >> $BOOST_ROOT/boost/thread/future.hpp >> >> line:603 >> for(count_type i=0;i<count;++i) >> { >> #if defined __DECCXX || defined __SUNPRO_CC >> locks[i]=boost::unique_lock<boost::mutex>(futures[i].future_->mutex).move(); >> #else >> locks[i]=boost::unique_lock<boost::mutex>(futures[i].future_->mutex); >> #endif >> } >> >> T0: >> >> for(count_type i=0;i<count;++i) >> { >> #if defined __DECCXX || defined __SUNPRO_CC || defined __hpux >> locks[i]=boost::unique_lock<boost::mutex>(futures[i].future_->mutex).move(); >> #else >> locks[i]=boost::unique_lock<boost::mutex>(futures[i].future_->mutex); >> #endif >> } >> >Please could you create a ticket for that? created ticket 7329. It should be noted that there also numerous warnings in compiling file libs/chrono/src/process_cpu_clocks.cpp i.e "./boost/chrono/detail/inlined/posix/process_cpu_clocks.hpp", line 118: warning #2940-D: missing return statement at end of non-void function "boost::chrono::process_real_cpu_clock::now(boost::system::error_code &)" } "./boost/chrono/detail/inlined/posix/process_cpu_clocks.hpp", line 194: warning #2940-D: missing return statement at end of non-void function "boost::chrono::process_user_cpu_clock::now(boost::system::error_code &)" } "./boost/chrono/detail/inlined/posix/process_cpu_clocks.hpp", line 271: warning #2940-D: missing return statement at end of non-void function "boost::chrono::process_system_cpu_clock::now(boost::system::error_code &)" } "./boost/chrono/detail/inlined/posix/process_cpu_clocks.hpp", line 350: warning #2940-D: missing return statement at end of non-void function "boost::chrono::process_cpu_clock::now(boost::system::error_code &)" } These could easily be removed by simple restructure of the code. Best regards, Ta, Avi

2 1

Re: [Boost-users] [boost] [Review.Coroutine] Some comments
by Oliver Kowalke 05 Sep '12

05 Sep '12

> * I don't know if showing the signature in the documentation will be > more informative. OK > * Could you add the following noexcept specifier? OK > * As the template class Allocator is not used to allocate internal > memory of the coroutine class. Could the Allocator parameter be renamed > StackAllocator? OK > * Could you add an standard Allocator parameter as e.g. the one of > packaged_task? > > C++ International Standard > > * I understand that the Boost.Context Allocator parameter is part od the > class, as context is a low-level class, but coroutine is more high > level. Is there a possibility to type erase the StackAllocator (and > preceding Allocator) template parameter, as packaged_task do? This will > allow to store coroutines (and generators) with the same signature in a > container even if they don't share the Allocator. You mean coroutine would have two allocators - one for allocating internal memory and one for allocating the stack? Removing the StackAllocator from the template arguments of coroutine should not that problem (would require an internal pointer to an internal interface - maybe detail::context_exec is a candidate). I've some concerns about having two allocator objects in coroutine's ctor . > * Parameters and move semantics. Could the signature parameters be > rvalue references? > > R operator()(A0 a0, ..., A9 a9); Hmmm - this would require a second version of opertor() and all arguments are moveable?! R operator()(BOOST_RV_REF( A0) a0, ..., BOOST_RV_REF( A)) a9); > I'm asking this because I think that Boost.Tuple has not implemented yet > move semantics. don't know - would that be an issue > * What about moving some of the coroutine/generator optional parameters > to a coro::attributes class > > std::size_t size = ctx::default_stacksize(), > flag_unwind_t do_unwind = stack_unwind, > bool preserve_fpu = true, instead of passing those threee params as args to coroutine ctor? good point > * Usually (at least in the C++ standard) a function doesn't throws > because of its preconditions are not satisfied. then assert? pre-conditions should be checked but how should I react if I get garbage from the user? > This should be coherent with > > > |Result operator()()| > > Preconditions: > > |*this| is not a /not-a-generator/, |! is_complete()|. > > which doesn't throws any specific exception if the preconditions are not > satisfied. does an assert - OK the I'll replace throwing excpetions be assertions > Documentation > ========= > > coroutine.html > > s/it can migrated between threads/it can migrate between threads/ OK > s/yield_return/yield_break/ > > * documentation for the following constructor is missing in the reference > > template< typename Fn > > coroutine( Fn && fn, > std::size_t size = ctx::default_stacksize(), > flag_unwind_t do_unwind = stack_unwind, > bool preserve_fpu = true, > Allocator alloc = Allocator() ); OK I think it will be easy to incorporate your suggestions - but during the boost.context review I was told not to modify the reviewd library (if the review is still on-going). regards, Oliver

1 0

can different versions of boost coexist in an executable?
by Nathan Ridge 05 Sep '12

05 Sep '12

Hello, I am developing a C++ library, which I distribute in binary form as a static library. The implementation of my library uses Boost, but the interface does not, so I completely shield my users from the Boost dependency by linking the Boost object files that my implementation requires into the static library. Suppose a client of my library uses Boost in their own code. When they link their executable, the linker now sees two copies of some Boost libraries: the copy in my static library, and their own copy that they are linking. It seems that the linker only keeps one of the two and discards the other. If the Boost version that I linked into my static library is different from the Boost version my client uses, then one of my code and their code will be linked to a different version of Boost that the one it was compiled against, leading to a crash. I suppose one way to rectify this problem would be for me to document what version of Boost libraries I compiled and linked against, and require that if my clients use Boost themselves, they use the same version. However, I dislike this solution for two reasons: 1) It exposes my library's dependence on Boost, which was meant to be an implementation detail. 2) It limits my clients to using a particular version of Boost. They may have good reasons for using an older (or newer!) version instead. I would much prefer if the linker kept both copies of the Boost libraries in the executable, and each piece of code (mine and my client's) used whichever version of the libraries it was compiled against. Can this be accomplished? Thanks, Nate

2 1

[fusion] Wrapping a Fusion sequence
by Agustín K-ballo Bergé 04 Sep '12

04 Sep '12

I'm looking for a way to create a Fusion sequence wrapper that is itself a Fusion sequence and forwards all 'calls' to its wrapped sequence. Something in the lines of template< typename Sequence > struct sequence_wrapper { explicit sequence_wrapper( Sequence const& s ) : seq( s ){} Sequence seq; }; where sequence_wrapper< Sequence > is a Fusion sequence as well, and works just as Sequence would. The reason I need this is that I have several functions that operate on Fusion sequences (where all elements satisfy some special requirements), and I would like to add some syntax sugar for which I need a custom type to add overloaded operators to. I do not need the result of operations on a sequence_wrapper to return a sequence_wrapper as well, only the syntax sugar related calls would return a (manually) wrapped sequence. For instance, appending elements to a sequence using the comma operator (somewhat of a Boost.Assign for Fusion sequences): template< typename Sequence, typename T > sequence_wrapper< typename boost::fusion::result_of::push_back< Sequence const& , T >::type > operator,( Sequence const& seq, T const& v ) { return sequence_wrapper< typename boost::fusion::result_of::push_back< Sequence const& , T >::type >( boost::fusion::push_back( seq, v ) ) ; } What would be the best way to achieve this (if it is indeed supported by the library)? I'm particularly trying to avoid creating a Fusion sequence from scratch, as I would like to use whatever sequence is returned by Fusion operations. Would inheritance + specialization of `tag_of` to return the tag of the wrapped sequence just work? Or will I need to define a tag of my own and implement all required functions to just forward the call? Thank you in advance. Agustín K-ballo Bergé.- http://fusionfenix.com

2 4

Trying to compile and use boost on proprietary complier similar to MPICH2 CXX
by Chris 04 Sep '12

04 Sep '12

Hi all, hope this is the right list for my question. So here it goes: When it try to use boost using a proprietary MPIC++ compiler I have no control over, I get the following errors: In file included from ../boost_1_43_0/boost/thread/detail/platform.hpp:17, from ../boost_1_43_0/boost/thread/thread.hpp:12, from ../boost_1_43_0/boost/thread.hpp:13, from test.cpp:37: ../boost_1_43_0/boost/config/requires_threads.hpp:47:5: error: #error "Compiler threading support is not turned on. Please set the correct command line options for threading: -pthread (Linux), -pthreads (Solaris) or -mthreads (Mingw32)" In file included from ../boost_1_43_0/boost/thread/thread.hpp:12, from ../boost_1_43_0/boost/thread.hpp:13, from test.cpp:37: ../boost_1_43_0/boost/thread/detail/platform.hpp:67:9: error: #error "Sorry, no boost threads are available for this platform." In file included from ../boost_1_43_0/boost/thread.hpp:13, from test.cpp:37: ../boost_1_43_0/boost/thread/thread.hpp:19:2: error: #error "Boost threads unavailable on this platform" The thing is, when I use the standard mpicxx from MPICH2, things work out fine. I'm now trying to find out if the problem lies in the complier, or if I simply did not compile and bootstrap boost properly. What I did when building boost is the following: ./bootstrap.sh --with-libraries=date_time,filesystem,serialization,iostreams,system,thread,mpi ./bjam cxxflags="-O2" release threading=multi link=static After bootstrap, I tried to manually edit the user-config.jam to add "using mpi ;" and explicitly added the path to the compiler, but this all did not change the above mentioned error when I try to compile my code that uses boost. Is this enough information for you to judge if I might have overlooked something when building boost? Many thanks, Chris

3 3

filesystem directory_iterator run-time error during construction after upgrading to OSX Lion
by Martin Searancke 04 Sep '12

04 Sep '12

I have just upgraded my Mac to Lion and code that worked fine under snow leopard is giving me a run-time exception when constructing a directory_iterator. The error I am getting is "malloc: pointer being freed was not allocated" The line in question that raises this error is: for ( directory_iterator itr( my_path ); itr != end_itr; ++itr ) taken directly from the example and working fine under windows. This is version 1.49 installed with MacPorts. Is this a known problem? I found some vague references to a similar problem in an earlier version of boost but no solution. I have confirmed that I only have 1 copy of the headers and libs on the system and in the correct path. The date stamp on the files matches the last time I did a macports update so this should be the matching library for the header. Please note that I am a real novice to Mac development and have only just started porting code from windows for less than a month. Thanks in advance, Martin

3 2

Re: [Boost-users] compilation problems with thread/chrono & boost 1.51 & HPUX
by Avi Bahra 04 Sep '12

04 Sep '12

>>On 3.9.2012. 10:26, Avi Bahra wrote: >>> Can any one suggest *any* hacks/workarounds that gets me pass these errors. >>> Is it possible to use gcc on HPUX with boost 1.51 ? >> >>The docs for boost thread 1.51 say this: >> >>Boost.Thread uses by default Boost.Chrono for the time related >>functions. For backward compatibility and also for compilers that don't >>work well with Boost.Chrono the user can define >>BOOST_THREAD_DONT_USE_CHRONO. If BOOST_THREAD_DONT_USE_SYSTEM is defined >>then BOOST_THREAD_DONT_USE_CHRONO is defined implicitly. >> >>BOOST_THREAD_USES_CHRONO is defined when Boost.Thread uses Boost.Chrono. I have already tried BOOST_THREAD_DONT_USE_CHRONO and it has no effect. It appears that some of headers files are not guarded with this. In my case $BOOST_ROOT/boost/chrono/system_clocks.hpp $BOOST_ROOT/boost/ratio/detail/overflow_helpers.hpp $BOOST_ROOT/boost/thread/future.hpp do not compile, Also Is it possible to make a request to change: $BOOST_ROOT/boost/thread/future.hpp line:603 for(count_type i=0;i<count;++i) { #if defined __DECCXX || defined __SUNPRO_CC locks[i]=boost::unique_lock<boost::mutex>(futures[i].future_->mutex).move(); #else locks[i]=boost::unique_lock<boost::mutex>(futures[i].future_->mutex); #endif } T0: for(count_type i=0;i<count;++i) { #if defined __DECCXX || defined __SUNPRO_CC || defined __hpux locks[i]=boost::unique_lock<boost::mutex>(futures[i].future_->mutex).move(); #else locks[i]=boost::unique_lock<boost::mutex>(futures[i].future_->mutex); #endif } Best regards, Ta, Avi

2 1