August 2010 - Boost - lists.boost.org

Re: [boost] [msm] Async transition
by Christophe Henry 27 Aug '10

27 Aug '10

> Thanks for your answer. > > It was in fact a question from my employer that asked if msm allows to > do the same as the last example of the statechart doc : > http://www.boost.org/doc/libs/1_44_0/libs/statechart/doc/tutorial.html > (at the end of the page). It depends. As the event processing function of msm is reentrant thanks to the message queue, you have no risk in single threaded programs. In multithreaded programs, you will need to protect the access to process_event. > It's not a requirement, just a technical question because from my > understanding of UML, state regions should be managed separately and I > thought maybe they were threaded in some way. We wanted to be sure of > the whole behaviour before starting testing it. What UML writes about regions is that they are "logically" concurrent, meaning (IIUC) that they each get a chance to handle an event. MSM is implemented this way, each region being called in turn (in the order of the initial_state typedef). Of course, doing this concurrently would speed up event processing at the cost of predictability (if regions sent events to each other, you could not know which is processed first). > Anyway I see that I should treat the state machine like a STL > component in regards to thread-safety and asynchronous event > management. Yes, I also tend to see it that way. >As it's not a requirement, it's not a problem for me but I > was asking myself if there would be an interest in having the event > processing being thread-safe, allowing multiple threads to send > events? Maybe like haveing a msm2 like signals2? > I'm not experienced enough to see if it would be a good idea and I > don't need it so it's just a theorical question. As I don't see msm as a library closed for changes, there is no need for a msm2 yet ;-) I'm working on the next version so if there is a need, I will happily implement it. I've been thinking about thread safety for a while but failed to see a huge gain. I could replace: lock() // whatever you need for locking fsm.process_event(event()); unlock(); by: fsm.process_event(); where process_event would lock at the beginning and unlock at the end, but it seems pretty limited. This leaves us with the valid use case of concurrent region processing. I don't see any other yet, but I'd be interested if someone does as it's a subject I'll want to handle of at some point. Regards, Christophe

2 1

[serialization] register_type order dependent?
by Jeff Flinn 27 Aug '10

27 Aug '10

Is it expected that the calls to register_type need to be identical on both the save and load side of a serialization exchange? I thought I read that the registration facility sets up a map. But the following caused a archive_exception. struct C {}; struct B : C {}; struct A : B {}; --- save boost::archive::text_oarchive oa(some_ostream); oa.register_type(static_cast<A*>(0)); oa.register_type(static_cast<B*>(0)); oa.register_type(static_cast<C*>(0)); oa & aC_ptr; --- load boost::archive::text_iarchive ia(some_istream); ia.register_type(static_cast<B*>(0)); ia.register_type(static_cast<A*>(0)); ia.register_type(static_cast<C*>(0)); oa & aC_ptr; Thanks, Jeff

3 3

glog - google logging library
by Neal Becker 27 Aug '10

27 Aug '10

Just noticed this. Interesting design. http://google-glog.googlecode.com/svn/trunk/doc/glog.html

1 0

[python] boost 1.44 using python 3.1.2 build problem
by Christopher Lux 27 Aug '10

27 Aug '10

Hi, i am under the impression boost.python supported python 3 for a while now. But trying to compile it using python 3.1.2 gives me the old errors: .\boost/python/converter/builtin_converters.hpp(138) : error C2039: 'PyInt_FromLong' : is not a member of '`global namespace'' .\boost/python/converter/builtin_converters.hpp(138) : error C3861: 'PyInt_FromLong': identifier not found .\boost/python/converter/builtin_converters.hpp(138) : error C2065: 'PyInt_Type' : undeclared identifier .\boost/python/converter/builtin_converters.hpp(138) : error C2039: 'PyInt_FromLong' : is not a member of '`global namespace'' .\boost/python/converter/builtin_converters.hpp(138) : error C3861: 'PyInt_FromLong': identifier not found .\boost/python/converter/builtin_converters.hpp(138) : error C2065: 'PyInt_Type' : undeclared identifier .\boost/python/converter/builtin_converters.hpp(138) : error C2039: 'PyInt_FromLong' : is not a member of '`global namespace'' .\boost/python/converter/builtin_converters.hpp(138) : error C3861: 'PyInt_FromLong': identifier not found .\boost/python/converter/builtin_converters.hpp(144) : error C2039: 'PyInt_FromLong' : is not a member of '`global namespace'' .\boost/python/converter/builtin_converters.hpp(144) : error C3861: 'PyInt_FromLong': identifier not found .\boost/python/converter/builtin_converters.hpp(144) : error C2065: 'PyInt_Type' : undeclared identifier .\boost/python/converter/builtin_converters.hpp(144) : error C2039: 'PyInt_FromLong' : is not a member of '`global namespace'' .\boost/python/converter/builtin_converters.hpp(144) : error C3861: 'PyInt_FromLong': identifier not found .\boost/python/converter/builtin_converters.hpp(144) : error C2065: 'PyInt_Type' : undeclared identifier .\boost/python/converter/builtin_converters.hpp(144) : error C2039: 'PyInt_FromLong' : is not a member of '`global namespace'' .\boost/python/converter/builtin_converters.hpp(144) : error C3861: 'PyInt_FromLong': identifier not found my user-config.jam: using python : 3.1 : "C:\\Program Files\\python31\\python" : "C:\\Program Files\\python31\\include" : "C:\\Program Files\\python31\\libs" : #condition : #ext suffix ; Regards -chris

5 5

Re: [boost] Generic lazy loader library interest
by John Bellone 27 Aug '10

27 Aug '10

Hey Dave, It is not a code loader (or class loader) in the sense of Java. This is a design pattern which delays execution (allocation) until the object is first needed. Wikipedia would have a much better explanation than I could ( http://en.wikipedia.org/wiki/Lazy_loading) I currently have a example up on my Github repository, but there is still work to be done to make it better so I figured I'd put the feelers out to see if there is interest. I have a post regarding it on my blog (http://thoughtlessbanter.com/) and I'll include a snippet from the example. class Unique{public: Unique() : m_uuid(boost::uuids::random_generator()()) { } Unique(const boost::uuids::uuid& u) : m_uuid(u) { } const boost::uuids::uuid& uuid() { return m_uuid; }private: boost::uuids::uuid m_uuid;}; static void factory(boost::shared_ptr<Unique>& impl){ impl = boost::shared_ptr<Unique>( new Unique(boost::uuids::nil_uuid()) );} int main(int argc, char* argv[]){ thunk::lazy_loader<Unique> loader(&factory); const boost::uuids::uuid& u = loader->uuid(); std::cout<<"uuid: "<<boost::lexical_cast<std::string>(u)<<std::endl; return 0;} Thanks, jb

1 0

[Filesystem] problems with g++ -std=c++0x
by Roland Bock 26 Aug '10

26 Aug '10

Hi, getting my feet wet with variadic templates, I switched on c++0x support in gcc. Unfortunately, I am experiencing a linker error for the following minimal program: ------------------ #define BOOST_FILESYSTEM_VERSION 3 #define BOOST_FILESYSTEM_NO_DEPRECATED #include <boost/filesystem.hpp> int main() { boost::filesystem::copy_file("a", "b"); } ------------------ rbock@rbock:~/temp/test$ g++ File.cpp -std=c++0x -I boost/1.44/include -L boost/1.44/lib -l boost_filesystem -l boost_system /tmp/ccwkcQpq.o: In function `boost::filesystem3::copy_file(boost::filesystem3::path const&, boost::filesystem3::path const&)': File.cpp:(.text._ZN5boost11filesystem39copy_fileERKNS0_4pathES3_[boost::filesystem3::copy_file(boost::filesystem3::path const&, boost::filesystem3::path const&)]+0x2a): undefined reference to `boost::filesystem3::detail::copy_file(boost::filesystem3::path const&, boost::filesystem3::path const&, boost::filesystem3::copy_option, boost::system::error_code*)' collect2: ld returned 1 exit status Experienced on Ubuntu-10.4, 64bit, gcc (Ubuntu 4.4.3-4ubuntu5) 4.4.3 Other boost libraries seem to work fine, other functions within Boost.Filesystem work fine, too. When I rebuild boost with -std=c++0x, then the linking problem is gone, but I experience crashes in the boost::thread constructor :-( Any ideas? Thanks and regards, Roland

4 8

Re: [boost] [msm] Async transition
by Christophe Henry 26 Aug '10

26 Aug '10

Hi, > from what I understand of Meta-State-Machine library documentation, > the state transitions are performed immediately when events are > processed. - right? Right. > So my (maybe very dumb) question is : is there cases where the > state-machine will perform state transitions in an asynchronous way? No, transitions are performed when an event is fired. What are you trying to achieve? Regards, Christophe

2 1

ptr_container] 1.44 compile error in serialization
by Jan Boehme 26 Aug '10

26 Aug '10

Hi, a compile error (gcc used) occurs if a ptr_container should be serialized: boost/ptr_container/detail/serialize_reversible_cont.hpp:28: error: ‘make_nvp’ is not a member of ‘boost::serialization’ A patch to fix this is attached. Bye, Jan.

2 2

[msm] Async transition
by Klaim 26 Aug '10

26 Aug '10

Hi, from what I understand of Meta-State-Machine library documentation, the state transitions are performed immediately when events are processed. - right? So my (maybe very dumb) question is : is there cases where the state-machine will perform state transitions in an asynchronous way? Thanks, Joël Lamotte

1 0

[algorithm][string] gcc unused parameter warning
by Jürgen Hunold 25 Aug '10

25 Aug '10

Hi, compiling code using Boost.Unit results in an unused parameter in algorithm/string/detail/find_format_store.hp with gcc and -Wall -Wextra enabled. Okay to commit the attached patch ? Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold(a)ivembh.de ! www.ivembh.de * * Geschäftsführer: ! Sitz des Unternehmens: Hannover * Prof. Dr.-Ing. Thomas Siefer ! Amtsgericht Hannover, HRB 56965 * PD Dr.-Ing. Alfons Radtke !

2 2