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

[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

Boost source code ?
by Sajith Kariyawasam 04 Sep '12

04 Sep '12

Hi all, Could any one of you point me to Boost source repository ? Im planning to build from the source. I got nothing in this link http://www.boost.org/users/download/#repository -- Best Regards Sajith

2 2

a client for echo server example
by Goran 04 Sep '12

04 Sep '12

Hi all, I took a look into asio and "boost_asio/example/echo/async_tcp_echo_server.cpp". This example is clear. But I'm looking for something like an "async tcp echo client". The client should send every second one status message. Maybe client is not the correct word. My desired architecture should be "slave server" <--> "master server" where "master server" sends an "ACK" to "slave server" for every "DATA" packet "master server" receives. Something similar to an echo / ping pong server. Can someone provide hints or even an example for a "slave server" similar to "boost_asio/example/echo/async_tcp_echo_server.cpp"? Thanks in advance! Goran

1 0

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

asio::posix::stream_descriptor throws with redirected stdin
by Chris Stankevitz 04 Sep '12

04 Sep '12

Hello, Please consider the program listed below. I compiled with the command "g++ test.cpp -lboost_system-mt" using GCC 4.5 on Gentoo linux with boost 1.48. When I invoke the program like this it works fine: cat test.cpp | ./a.out When I invoke the program like this it throws: ./a.out < test.cpp The exception thrown: terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::system::system_error> >' what(): assign: Operation not permitted Aborted Question: Why does the program throw when I redirect stdin to point to a file? Thank you, Chris //=== begin test.cpp === #include <boost/asio.hpp> int main() { boost::asio::io_service IoService; int Fd = ::dup(STDIN_FILENO); boost::asio::posix::stream_descriptor Stream(IoService, Fd); return 0; }

1 0

Accessing MSM attribute under specific conditions causes non-compile
by Chiem Whua Ma 03 Sep '12

03 Sep '12

This is my first post to the list. I've been working with MSM and have been pulling my hair out over what I now think is a bug, either in the library or the compiler. If you create an action, and inside that action you do a get_attribute on the state machine, and that state machine (MSM) is a sub-statemachine of another (parent) MSM, and that sub-machine state happens to be the initial state of the parent machine (that's a lot of ifs!), the code will not compile. It aborts with the mysterious error: c:\boost_1_51_0\boost\fusion\container\map\detail\deref_data_impl.hpp(28): error C2039: 'second_type' : is not a member of 'boost::mpl::void_' followed by the traditional slew of other stuff. Although this example is easy enough to work around, I've found whether it works or not is erratic. The one thing that seems to work OK is to move the action out of the entry for the sub machine and into the entry of the first state, but I haven't done enough testing to show that this works. I've attached a zip and included the text of a sample. As is it will not compile. You can either uncomment the attribute assignment or change the initial state to make it compile. Any help with this would be appreciated! Thanks! -Chiem Here's sample code. I've also attached a zip: #include <vector> #include <iostream> #include <boost/msm/back/state_machine.hpp> #include <boost/msm/front/euml/euml.hpp> using namespace std; using namespace boost::msm::front::euml; namespace msm = boost::msm; namespace MSM_A // Concrete FSM implementation { BOOST_MSM_EUML_DECLARE_ATTRIBUTE(int, borrowedBuffer_attribute); BOOST_MSM_EUML_ACTION(someAction) { template <class Event,class FSM,class STATE> void operator()(Event const& event,FSM& fsm, STATE&) { fsm.get_attribute(borrowedBuffer_attribute)=1; // <--------------- UNCOMMENTING THIS WILL ALSO ALLOW COMPILATION } }; BOOST_MSM_EUML_EVENT(someevent) BOOST_MSM_EUML_STATE((no_action), someStateA) BOOST_MSM_EUML_STATE((no_action), someStateB) BOOST_MSM_EUML_TRANSITION_TABLE(( someStateA + someevent == someStateB ),transition_table) BOOST_MSM_EUML_DECLARE_STATE_MACHINE(( transition_table, init_ << someStateA, someAction, // <-------------------- ACTION IS AN ENTRY ACTION no_action, attributes_ << borrowedBuffer_attribute, configure_ << no_configure_ ), MSM_A_frontEnd) //fsm name typedef msm::back::state_machine<MSM_A_frontEnd> MSM_A_player; } namespace MSM_B // Concrete FSM implementation { ::MSM_A::MSM_A_player subMachine; BOOST_MSM_EUML_EVENT(someEvent) BOOST_MSM_EUML_STATE((no_action), someState) BOOST_MSM_EUML_TRANSITION_TABLE(( someState + someEvent == subMachine ), transition_table) BOOST_MSM_EUML_DECLARE_STATE_MACHINE(( transition_table, //STT //init_ << someState, // <---------------- WORKS init_ << subMachine, // <---------------- DOES NOT COMPILE no_action, // Entry no_action, // Exit attributes_ << no_attributes_, // Attributes configure_ << no_configure_ ), MSM_B_frontEnd) //fsm name typedef msm::back::state_machine<MSM_B_frontEnd> MSM_B_player; } int main() { MSM_B::MSM_B_player player; player.start(); return 0; }

2 1

{Review] Coroutine reviewstarts today, September 3rd
by Hartmut Kaiser 03 Sep '12

03 Sep '12

Hi all, The review of Oliver Kowalke's Boost.Coroutine library starts today, September 3rd 2012, and will end on September 12th. I really hope to see your vote and your participation in the discussions on the Boost mailing lists! ----------------------------------------------------- About the library: Boost.Coroutine provides templates for generalized subroutines (coroutines) which allow multiple entry points for suspending and resuming execution at certain locations. It preserves local state/data and allows re-entering subroutines more than once (useful if state must be kept across function calls). Coroutines can be viewed as a language-level construct providing a special kind of control flow. You can download the library and the view documentation here: docs: http://ok73.ok.funpic.de/boost/libs/coroutine/doc/html/ src: http://ok73.ok.funpic.de/boost.coroutine.zip --------------------------------------------------- Please always state in your review, whether you think the library should be accepted as a Boost library! Additionally please consider giving feedback on the following general topics: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? Regards Hartmut Review Manager

1 0

compilation problems with thread/chrono & boost 1.51 & HPUX
by Avi Bahra 03 Sep '12

03 Sep '12

I am transitioning from boost 1.47 to boost 1.51. Using compiler : aCC: HP C/aC++ B3910B A.06.20 [May 13 2008] Using: ./bjam --build-dir=./tmpBuildDir toolset=acc stage link=static --layout=tagged --with-thread variant=debug It appears that building thread requires chrono, which now fails to compile. ========================== acc.compile.c++ tmpBuildDir/boost/bin.v2/libs/chrono/build/acc/debug/link-static/threading-multi/chrono.o "./boost/ratio/detail/overflow_helpers.hpp", line 164: error #2063: shift count is too large (BOOST_RATIO_INTMAX_C(1) << (sizeof(boost::intmax_t) * CHAR_BIT - 1)); "./boost/chrono/system_clocks.hpp", line 71: error #2035: #error directive: <time.h> does not supply CLOCK_REALTIME # error <time.h> does not supply CLOCK_REALTIME "./boost/ratio/detail/overflow_helpers.hpp", "./boost/thread/v2/thread.hpp", line 45: error #2135: namespace "boost::chrono" has no member "steady_clock" void sleep_until(const chrono::time_point<chrono::steady_clock, Duration>& t) acc.compile.c++ tmpBuildDir/boost/bin.v2/libs/thread/build/acc/debug/link-static/threading-multi/future.o "./boost/thread/future.hpp", line 608: error #2330-D: "boost::unique_lock<Mutex> &boost::unique_lock<Mutex>::operator=(boost::unique_lock<Mutex> &) [with Mutex=boost::mutex]" (declared at line 287 of "./boost/thread/locks.hpp") is inaccessible locks[i]=boost::unique_lock<boost::mutex>(futures[i].future_->mutex); ============================= 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 ? Best regards, Ta, Avi

2 1

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.Test + Boost.Spirit fails for *many* enable/disable_if calls
by Mario Lang 03 Sep '12

03 Sep '12

Hi. On trunk with gcc 4.7, the following minimalistic test case fails: ---<snip>--- #define BOOST_TEST_MODULE "broken_enable_if" #include <boost/test/included/unit_test.hpp> #include <boost/spirit/include/qi_parse.hpp> ---<snip>--- Compiling this gives me the following error: ./boost/spirit/home/qi/detail/parse.hpp:64:69: error: template argument 2 is invalid This apparently only happens if I include unit_test before spirit. And its not the only error, fixing this one by qualifying enable_if with boost:: reveals a chain of similar errors. Can someone please take a look at this? -- CYa, ⡍⠁⠗⠊⠕ | Debian Developer <URL:http://debian.org/> .''`. | Get my public key via finger mlang/key(a)db.debian.org : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44 `. `' `- <URL:http://delysid.org/> <URL:http://www.staff.tugraz.at/mlang/>

2 1

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

[fusion] push_back documentation issue
by Agustín K-ballo Bergé 03 Sep '12

03 Sep '12

The documentation for push_back specifies a return type of result_of::push_back<Sequence, T>::type where Sequence is not const-qualified: template< typename Sequence, typename T > typename result_of::push_back<Sequence, T>::type push_back( Sequence const& seq, T const& t); yet the implementation is defined to return result_of::push_back<Sequence const, T>::type, note the const-qualified Sequence: template <typename Sequence, typename T> inline typename lazy_enable_if< traits::is_sequence<Sequence> , result_of::push_back<Sequence const, T> >::type push_back(Sequence const& seq, T const& x) Is this a documentation bug? Agustín K-ballo Bergé.- http://fusionfenix.com

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