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

[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

[traits, fusion, mpl] Basic question about is_base_of and template ancestors
by Rindeberg Magnus 04 Sep '12

04 Sep '12

Hello List! I have an issue understanding how to combine CRTP with the "is_base_of" trait when iterating over a fusion vector. I have tried to illustrate my problem in the test program below. The idea is to first "do stuff" to all instances of types derived from A and then "do stuff" to the ones derived from B. I just don't know what to write instead of "WHAT_GOES_HERE?" below. I have tried to use "::boost::mpl::_" in different ways to get the "type" type of B but failed miserably every time. I'm also curious about how to negate the "is_base_of" predicate. I tried using "not_<>" but that didn't work at all... Very thankful for any and all help! // Magnus P.S. Sorry if this question has been answered already! I have looked at the documentation, searched archives and the web but couldn't find the solution. Maybe I searched using the wrong keywords... #include <boost/type_traits.hpp> #include <boost/mpl/vector.hpp> #include <boost/fusion/include/mpl.hpp> #include <boost/fusion/container.hpp> #include <boost/fusion/include/at_key.hpp> #include <boost/fusion/include/for_each.hpp> #include <boost/fusion/include/filter_if.hpp> struct dostuff { template<typename T> void operator()(T const & x) const { // Do stuff here! } }; template<class D> struct A { }; template<class D, typename T> struct B { typedef T type; }; struct derived_from_A : public A<derived_from_A> { }; struct derived_from_B : public B<derived_from_B, int> { }; typedef ::boost::mpl::vector<derived_from_A, derived_from_B>::type typelist_type; ::boost::fusion::result_of::as_set<typelist_type>::type typeset_; int main(int argc, char ** argv) { dostuff ds; // This seems to be working! ::boost::fusion::for_each( ::boost::fusion::filter_if < ::boost::is_base_of<A< ::boost::mpl::_>, ::boost::mpl::_> > (typeset_), ds); #if(0) // Don't know how to do this! Preferably I'd like to check for inheritance from B. // If that isn't possible I'll settle for "not inheriting from A". ::boost::fusion::for_each( ::boost::fusion::filter_if < ::boost::is_base_of<B< ::boost::mpl::_, WHAT_GOES_HERE? >, ::boost::mpl::_> > (typeset_), ds); #endif }

3 3

problems in compiling application using IBM XL C/C++ V12.1 and boost1.50.0
by Pravar 04 Sep '12

04 Sep '12

Hi All, I am getting compilation errors when I try to build my application code which includes some boost headers using IBM XL C/C++ compiler V12.1. ------------------------------------------------------------------------------------------------ "/opt/boost/include/boost/date_time/time_resolution_traits.hpp", line 71.21: 1540-0063 (S) The text "->" is unexpected. "/opt/boost/include/boost/date_time/time_resolution_traits.hpp", line 135.33: 1540-0040 (S) The text "<" is unexpected. "time_resolution_traits" may be undeclared or ambiguous. "/opt/boost/include/boost/date_time/time_resolution_traits.hpp", line 136.33: 1540-0040 (S) The text "<" is unexpected. "time_resolution_traits" may be undeclared or ambiguous. "/opt/boost/include/boost/date_time/time_resolution_traits.hpp", line 137.33: 1540-0040 (S) The text "<" is unexpected. "time_resolution_traits" may be undeclared or ambiguous. "/opt/boost/include/boost/date_time/posix_time/posix_time_config.hpp", line 40.44: 1540-0040 (S) The text "<" is unexpected. "date_time::time_resolution_traits" may be undeclared or ambiguous. ------------------------------------------------------------------------------------------------- These errors seems come due to the fact that this version of compiler is claimed to have more standard conformance than its predecessors. I confirmed from boost release notes of boost 1.50.0 that V12. of XL C/C++ supports this boost version. But still I encountered above errors. Should I use an older version of XL C/C++ compiler so that such errors can be avoided ? Does anybody encountered similar issues ? I am completely stuck at this point and would greatly appreciate any ideas to understand and resolve this. Thanks, Pravar DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or NECHCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of NECHCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. . -----------------------------------------------------------------------------------------------------------------------

2 4

boost UTF suite namespace collision with user class names
by Aras Vaichas 03 Sep '12

03 Sep '12

Hello, I've just started using the Boost Unit Test Framework so my problem may be a bit naive. I would like to name each test suite after each of my classes. e.g. class foo { } BOOST_AUTO_TEST_SUITE(foo) { foo bar; BOOST_REQUIRE_SOMETHING(bar ... etc ...); } This is a problem because the BOOST_AUTO_TEST_SUITE macro expands to: namespace foo { ... etc ... } and the compiler gives an error: 'namespace foo{}' redeclared as a different symbol. I solved the problem by changing the namespace name to something less likely to collide. e.g. #define BOOST_AUTO_TEST_SUITE( suite_name ) \ namespace suite_name ## _boost { \ BOOST_AUTO_TU_REGISTRAR( suite_name ## _boost )( BOOST_STRINGIZE( suite_name ) ); \ /**/ Tested and it works. Comments? regards, Aras Vaichas

2 2

boost 1.51.0 bz2 archive observations
by Aras Vaichas 03 Sep '12

03 Sep '12

Sorry for the cross-posting, but I'm not sure where to put this. There is a slight difference between the 1.51.0 and 1.50.0 boost bz2 files. e.g. \boost_1_50_0.tar.bz2\boost_1_50_0.tar\boost_1_50_0\ \boost_1_51_0.tar.bz2\boost_1_51_0.tar\.\boost_1_51_0\ I went looking for this because I updated the Boost version to 1.51.0 in Buildroot and it failed to find the bootstrap.sh file because it wasn't in the expected directory. e.g. /opt/br/output/build$ find -name "bootstrap.sh" ./boost-1.51.0/boost_1_51_0/tools/build/v2/bootstrap.sh ./boost-1.51.0/boost_1_51_0/bootstrap.sh ./boost-1.50.0/tools/build/v2/bootstrap.sh ./boost-1.50.0/bootstrap.sh Buildroot fails to find the boostrap.sh file and the build fails. When I tried to untar it manually I got an error. $ tar xjf boost_1_51_0.tar.bz2 tar: .: Cannot utime: Operation not permitted tar: .: Cannot change mode to rwxr-xr-t: Operation not permitted tar: Exiting with failure status due to previous errors 1.50.0 does not have this problem. regards, Aras Vaichas

2 1

[Range] Proposal to add a new range adaptor (first_nd), or modify sliced
by Gábor Márton 01 Sep '12

01 Sep '12

Hi, Problem: Get the first N element of a SinglePassRange. It is not possible with sliced, because it requires RandamAccessRange. (Similar discussion was on the list about this in 2011 January: http://lists.boost.org/boost-users/2011/01/65757.php) Possible solutions: A) Modify sliced implementation to use std::advance instead of boost::size. (Boost::size calls operator+ on the end iterator of the adapted range, that is why it requires the random access.) However using std::advance is not efficient in case of iterators which are not random access ones. I think this efficiency problem is the reason why the author(s) decided to not use std::advance, but rather boost::size. So this is not a real solution. B) Introduce a new range adaptor, which has an underlying adapted iterator with a "count" member: template <class Iterator> class first_n_iterator : public boost::iterator_adaptor<first_n_iterator<Iterator>, Iterator> { ... first_n_iterator(const Iterator& it, std::size_t n) : first_n_iterator::iterator_adaptor_(it), initial(it), count(n) {} ... void increment() { ++(this->base_reference()); ++count; } bool equal(first_n_iterator const& other) const { return this->initial == other.initial && this->count == other.count; } Iterator initial; // used to be able to differentiate ranges std::size_t count; }; One can find the whole solution and the test for it attached (first_nd.hpp, first_nd_test.cpp). I think this is more effective than a sliced implementation with std::advance would be. The structure first_nd could be changed to support two parameters, so one could provide the start position too (so it wouldn't be fixed to zero). In the implementation (first_nd_range) std::advance could be used to point the starting iterator to the start position. However in this case we would get the same functionality as slice now has ... I am asking the boost community, 1) Would it be useful, to have such a new range adaptor? If yes, -- what would be the best name for it (first_nd is not the best, I know) ? -- I would be pretty enthusiastic to contribute it to boost. 2) Are the upper arguments valid against the current implementation of sliced? If yes, would it worth to change it to a similar to first_nd one? Or maybe, it would even be better to specialize sliced_range based on the iterator_tag of the range, what do you think? Best Regards, Gabor

7 7

[Function] Move semantics
by Szymon Gatner 31 Aug '12

31 Aug '12

Is there a plan to add move semantics to the Function library via Boost.Move? Many of us will be stuck in 03 compilers for a while and that would be a very nice update. -- Szymon Gatner The Lordz Games Studio www.thelordzgamesstudio.com

1 0

How to get the name of a boost::interprocess::managed_shared_memory::segment_manager
by Markus Bader 31 Aug '12

31 Aug '12

Hi I created a boost::interprocess::managed_shared_memory::segment_manager with an name an size. Afterwords I like to get the name again, but how? managed_shared_memory shm(create_only, "myShm", 65536) std::string name = shm.get_name()? // does not exist std::string name = shm.get_device().get_name();? // is not accessable Any ideas Greetings Markus

1 0