February 2010 - Boost-users - lists.preview.boost.org

[variant] Variant call forwarding?
by Rutger ter Borg 26 Feb '10

26 Feb '10

Hello, I'm wondering what's the easiest way to enable call forwarding by a variant to contained function objects accepting the same arguments? I.e., variant< F, G > m_funcs; m_funcs = f; m_funcs( a, b, c ); m_funcs = g; m_funcs( a, b, c ); Thanks, Cheers, Rutger

5 10

boost::asio::read_until w/ boost::function
by marty 26 Feb '10

26 Feb '10

I'm having some trouble resolving the call to read_until (see snippet below) Is there some reason I am not be able to use a boost::function as the MatchCondition object? Thanks, ...m _______________ [MyClass.h] class MyClass { ... typedef boost::asio::buffers_iterator<boost::asio::streambuf::const_buffers_type> t_Iterator; typedef std::pair<t_Iterator, bool> t_ConditionPair; boost::asio::serial_port _port; boost::asio::streambuf _readBuffer; t_ConditionPair myCondition(t_Iterator begin, t_Iterator end); void doRead(); ... }; [MyClass.cpp] MyClass::t_ConditionPair myCondition(t_Iterator begin, t_Iterator end) { t_ConditionPair theCondition; theCondition.first = end; theCondition.second = true; return theCondition; } void MyClass::doRead() { ... boost::asio::read_until( _port, _readBuffer, boost::bind( &MyClass::myCondition, this, _1, _2 ) ); ... }

4 4

Some questions about using BOOST_CLASS_EXPORT_KEY macro of boost.serialization library
by ZouLei 26 Feb '10

26 Feb '10

Dear all , The library version I used was boost_1_42, and the IDE was VS2008 . When I attempt to use the BOOST_CLASS_EXPORT_KEY macro, I met some problems. In my word, I think it doesn't work as expected . My project files are listed following (just five tiny files) : // Base.h #ifndef _BASE_H #define _BASE_H #include <boost/serialization/access.hpp> #include <boost/serialization/export.hpp> #include <boost/serialization/type_info_implementation.hpp> #include <boost/serialization/extended_type_info_no_rtti.hpp> #include <boost/serialization/base_object.hpp> #include <boost/serialization/shared_ptr.hpp> class Base { public: Base() ; Base(int a) ; virtual ~Base(); private: friend class boost::serialization::access ; template<class Archive> void serialize(Archive& ar, const unsigned int version) { ar & a_ ; } private: int a_ ; }; BOOST_CLASS_EXPORT_KEY(Base) BOOST_SERIALIZATION_SHARED_PTR(Base) #endif //_BASE_H // Base.cpp #include "Base.h" Base::Base(): a_(0){ } Base::Base( int a ): a_(a){ } Base::~Base(){ } BOOST_CLASS_EXPORT_IMPLEMENT(Base) //Derived.h #ifndef _DERIVED_H #define _DERIVED_H #include "base.h" class Derived : public Base { public: Derived(); Derived(int a, int b); ~Derived(); private: friend class boost::serialization::access ; template<class Archive> void serialize(Archive& ar, const unsigned int version) { ar & boost::serialization::base_object<Base>(*this) ; ar & b_ ; } private: int b_ ; }; BOOST_CLASS_EXPORT_KEY(Derived) BOOST_SERIALIZATION_SHARED_PTR(Derived) #endif // _DERIVED_H // Drived.cpp #include "StdAfx.h" #include "Derived.h" Derived::Derived(): b_(0){ } Derived::Derived( int a, int b ): Base(a), b_(b){ } Derived::~Derived(){ } BOOST_CLASS_EXPORT_IMPLEMENT(Derived) // main.cpp #include <fstream> #include <iostream> #include <boost/archive/text_oarchive.hpp> #include <boost/serialization/shared_ptr.hpp> #include "Derived.h" int _tmain(int argc, _TCHAR* argv[]) { boost::shared_ptr<Base> base_ptr(new Derived(10,15)) ; std::ofstream ofs("test.txt") ; boost::archive::text_oarchive oa(ofs) ; oa << base_ptr ; return 0; } There are no errors in compile-time. But when I executed the program, a memory error caused ! I don't know what is wrong about my program. Whether my usage of BOOST_CLASS_EXPORT_KEY/BOOST_CLASS_EXPORT_IMPLEMENT was wrong ? And, how can I fix the problems ? Thanks, and with my best wishes. Lei

4 4

[Statechart] Question regarding state_machine event handling
by Arne Babnik 26 Feb '10

26 Feb '10

Hi, I'm currently working with the the statechart library in version 1.42.0 and have some difficulties with the way the simple state_machine processes its events. For my work I need several independent state machines, which communicate with each other using process_event/post_event. For various reasons I do not want to use the asynchroneous_state_machine - mostly because my application is built around a global event/message handler and I do not want to use multiple threads with their necessary synchronization. It basically works because in my hierarchy state_machine<>::process_event() is called only in one direction, while in the "opposite" direction (or if unsure) state_machine<>::post_event() is being used. E.g. A calls B->process_event(), B calls C->process_event(), but C calls B->post_event() and B calls A->post_event(). This works so far, and since the process_event() function also processes events posted from within its execution context I do not see any problems with this. However, what I could really make use of are two functions: a) a query function to check if there are any events in the state machine queue (if additional post_event() calls have been made outside the process_event() context); and b) a process_event() function that does not need an event argument, but only processes the queue. Currently I use a "dummy" event for this, but this is rather ugly. Does anybody know why such functions are not available? For b) there is a function named "process_queued_events()" that does exactly what I need, but unfortunately this function is declared private.For a), a simple "eventQueue_.empty()" wrapper would suffice. An even bigger problem for me is that process_event() executes the event argument _first_. I'm rather used to state machines that process their events in-order regardless of the way they got queued up, so I had expected that process_event() first executes the events already in the queue before processing the given event (in other words, the given event argument is only put to the end of the queue initially, and then the queue is processed). Any ideas why the state machine works this way? What is the rationale for this behaviour? Thanks, Arne

3 4

Re: [Boost-users] 1.39 serialisation: buggy warning message for shared_ptr
by Avi Bahra 26 Feb '10

26 Feb '10

Robert Ramey wrote >> The only reason to export a type is if one needs to >> serialize it through a base class pointer. So, to me >> the best way to suppress the warning would be >> to not export the type. The warning message appears even if you don't export the type: Here is a simple test case //================================== #include <boost/archive/text_iarchive.hpp> #include <boost/archive/text_oarchive.hpp> #include <boost/serialization/base_object.hpp> #include <boost/serialization/string.hpp> #include <boost/serialization/vector.hpp> #include <boost/serialization/shared_ptr.hpp> // no need to include shared_ptr #include <boost/serialization/export.hpp> class Concrete { public: Concrete(const std::string& name ) : name_(name) {} Concrete() {} private: std::string name_; friend class boost::serialization::access; template<class Archive> void serialize(Archive& ar,const unsigned int){ ar & name_; } }; class Base { public: Base(const std::string& name ) : name_(name) {} Base() {} virtual ~Base(){} private: std::string name_; *std::vector<boost::shared_ptr<Concrete> > vec_*; friend class boost::serialization::access; template<class Archive> void serialize(Archive & ar, const unsigned int) { ar & name_; ar & vec_; } }; class Derived : public Base { public: Derived(const std::string& name ) : Base(name) {} Derived() {} private: friend class boost::serialization::access; template<class Archive> void serialize(Archive & ar, const unsigned int) { ar & boost::serialization::base_object<Base>(*this); } }; BOOST_CLASS_EXPORT(Derived); //================================== Notice that I have not exported Concrete, but the serialisation will spit out a warning message, about class Concrete. ... boost_1_39_0/boost/serialization/extended_type_info_typeid.hpp", line 88: warning #2414-D: delete of pointer to incomplete class BOOST_STATIC_WARNING(boost::is_polymorphic<T>::value); ^detected during: instantiation of "const boost::serialization::extended_type_info *boost::serialization::extended_type_info_typeid<T>::get_derived_extended_type_info(const T &) const [with T=Concrete]" at line 92 of "/scratch/ma/emos/ma0/hpia64/boost/boost_1_39_0/boost/archive/shared_ptr_helper.hpp" It looks like if we are serialising via a base ptr, and the base class is serialising concrete data member via a shared ptr, it has assumed that the type must be polymorphic. This does not seem right to me ? Best regards, Ta, Avi

3 2

Multiple key types map
by Michele Caini 26 Feb '10

26 Feb '10

Hi all, I'm looking for a map that has no matter about key types, so I can use such map storing int indexed objects and also, i.e., char indexed objects, as all-in-one container. It can be useful to have such type of key-type unaware containers, as we can find with other languages. What about existing one?

5 5

[program_options] allow_guessing issue
by Filip Konvička 26 Feb '10

26 Feb '10

Hi, I've just upgraded to boost 1.42 from 1.40, and it seems that the new feature 'allow_guessing', a default setting, breaks my existing code. I have two options: "lang" and "lang-dir", the first obviously a prefix of the other, and when my program is run with "--lang=en_US --lang-dir=.", the first argument is interpreted as "lang-dir". Even though the documentation says somewhere that one argument should not be a prefix of another with 'allow_guessing' on, this is a breaking change and should be put in a big red box somewhere on the front page :-) If the change is intended to be kept for the future, it would be wise to detect the problem by examining the options, rather than wait until another problem occurs (in my case, the runtime exception is 'multiple_options' when the user uses both options, and - much worse! - the option gets misinterpreted without a warning if he only uses the shorter option). Cheers, Filip

2 2

Property tree example debug_settings.cpp
by Mauricio Gomes 26 Feb '10

26 Feb '10

Hi, In http://www.boost.org/doc/libs/1_42_0/libs/property_tree/examples/debug_sett… FOREACH lines are commented out. <debug> <filename>debug.log</filename> <modules> <module>Finance</module> <module>Admin</module> <module>HR</module> </modules> <level>2</level> </debug> Then I compiled and tested the program and noticed it wrote only one value for the <modules> tag above. Here it is the output: <?xml version="1.0" encoding="utf-8" ?> - <#> <debug> <filename>debug.log</filename> <level>2</level> - <#> <modules> <module>HR</module> </modules> </debug What is the status of this library ? Is this a known bug or it is just the example that is not uptodate ? If the latter, can anyone provide a functional version of debug_settings.cpp ? Thanks ! -- Mauricio

2 1

[fusion] Introspection of fused objects?
by Rutger ter Borg 26 Feb '10

26 Feb '10

Suppose I have a function object created on the basis of a sequence of fused function objects, where I would like to do shuffle the call order on the basis of some criterion. template< typename SeqOfFused > struct merge_fused { merge_fused( SeqOfFused f ): m_functions( f ) {} typedef void result_type; template< int N, typename Seq > void operator()( Seq& seq ) { // normal dispatch call would be fusion::at_c<N>(m_functions)( seq ); if ( some case ) { store seq for later use } else { call appropriate fused object with parts of stored stuff } } SeqofFused m_functions; // some state / memory specific to this group of fused objects some_state m_state; }; I'm doing a static cast to a superclass to get rid of the int N template parameter, to make the merge_fused look exactly like a fused function object. This works fine. Storing stuff is what my question is about: is there any way to know the type of Seq from its Fused counterpart? Looking at the code, the answer is no, but perhaps there exists introspection code in fusion which I am unaware of? One solution would be to simply use static casting based on Seq in operator(), but then my question would be: is that safe? Thanks, Rutger

2 3

valgrind and boost.datetime
by Matwey V. Kornilov 26 Feb '10

26 Feb '10

Hi, I initialize time input facet in such way: new boost::posix_time::time_input_facet( std::string("%Y-%m-%d %H:%M: %S") ) and valgrind --track-origins=yes tells me: ==30317== Conditional jump or move depends on uninitialised value(s) ... ==30317== Uninitialised value was created by a stack allocation ==30317== at 0x806C486: std::vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > boost::date_time::gather_weekday_strings<char>(std::locale const&, bool) (strings_from_facet.hpp:84) Is there way to fix the problem? The problem is located within boost according to valgrind, but I assume that it can be produced by incorrect usage. Thanks gcc 4.4.1 boost 1.39.0

2 3