- Boost-users - lists.boost.org

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

[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