- Boost-users - lists.boost.org

synchronous vs asynchronous...
by Ozgur Ozturk 23 Jul '09

23 Jul '09

Hi, I am kind of new to multithreaded programming and network programming, so I had some difficulty with the examples. Can you confirm an epiphany I had? - I was thinking I had to use the asynchronous functions to handle multiple clients, now I understand that you can achieve same things with synchoronous ones w/ threads and you can write equally efficient code?. (It is only a different pattern; some people find the code more manageable the async way, since they don't need to handle threads themselves.) Is this new understanding true? - If no (if there is some efficiency difference), is it significant? (Otherwise, for the initial prototype of our software, I may use still use synchronous sockets w/ threads, since I am still not very comfortable with async.) Best regards, Ozgur (Oscar) Ozturk www.DrOzturk.com Phone: +1 (908) DROZGUR i.e, +1 (908) 376-9487

3 2

ASIO async_read_until...
by Etienne Philip Pretorius 23 Jul '09

23 Jul '09

Hello list, I have a set of inherited classes as follows: client [parent of] stream [parent of] parser [parent of] grammar When I perform the following call: boost::asio::async_read_until( socket_, streambuf_, stream::parse(), boost::bind( &client::handle_read, this, boost::asio::placeholders::error, boost::asio::placeholders::bytes_transferred ) ); The xml::parser::operator() call for the match condition is a copy of the classes: parser [parent of] grammar I need to know if someone could suggest a client way for me to use (shared) pointers to the classes so that the xml::parser::operator() can keep its state changes over successive calls for async_read_until. Currently I have this (hack) for the issue, but hope there is a cleaner approach: class parser : public grammar { public: parser( ) : parser_(//stupid hack... this ) { }; virtual ~parser( ) { }; parser& parse( ) { return *this; }; template <typename T> std::pair<T, bool> operator()( T begin, T end ) { ...[state changes based on content matches]... }; private: parser* parser_;//needed for stupid hack... protected: }; When I call stream::parse() it returns the parser object, at which async_read_until makes a copy of the parser object and its base classes. When parser::operator() is called by async_read_until, I then apply all state changes via parser* parser_ to the original class. Any suggestions are welcome. Etienne.

2 2

Statechart compile error on OS X
by Daniel Dilts 23 Jul '09

23 Jul '09

I'm trying to use Boost.Statechart in an iPhone development project. When I build the Hello World example in a .mm file (Objective C++) I get an error "error: no class template named 'rebind' in 'struct Machine'". If, in the same project, I build the statemachine in a .cpp file (C++) and call a C function from a .mm file it works perfectly. Is there a compiler flag or project setting that I need to change to get the state machine to work from a .mm file? I would really like the state machine to be a member of an Objective C class.

2 3

Important: Subversion upgrade on Saturday, July 25
by Doug Gregor 23 Jul '09

23 Jul '09

We will be upgrading Boost's Subversion server and the Boost Subversion repository to Subversion 1.6.3. This upgrade will bring the new features provided by the Subversion 1.5.x and 1.6.x released to Boost, including merge tracking: http://subversion.tigris.org/svn_1.5_releasenotes.html http://subversion.tigris.org/svn_1.6_releasenotes.html The upgrade will begin on Saturday, July 25 at 8:00AM EST, and is likely to take all day. During this upgrade, the Boost Subversion repository, Trac, and mailing list archives will be inaccessible. However, the Boost mailing lists should still function normally. I will send a note to the Boost list when the upgrade is complete. Thank you for your patience. - Doug

1 0

boost 1.39 serialization via base pointer ok on gcc, but crashes on AIX V10.1
by Avi Bahra 23 Jul '09

23 Jul '09

Take the following small self contained example. This compiles and runs without any problems on gcc 4.2.1 on SUSE Linux. However on AIX v10.1 compiler, you see the following on compile: "/s1a/emos_esuite/emos_data/sms/boost_1_39_0/boost/archive/detail/oserializer.hpp", line 538.5: 1540-2400 (W) "boost::serialization::STATIC_WARNING" is undefined. The delete operator will not call a destructor. "/s1a/emos_esuite/emos_data/sms/boost_1_39_0/boost/archive/detail/oserializer.hpp", line 530.13: 1540-0700 (I) The previous message was produced while processing "boost::archive::save<boost::archive::text_oarchive,Defs>(text_oarchive "/s1a/emos_esuite/emos_data/sms/boost_1_39_0/boost/archive/detail/common_oarchive.hpp", line 64.9: 1540-0700 (I) The previous message was produced while processing "boost::archive::detail::common_oarchive<boost::archive::text_oarchiv. "/s1a/emos_esuite/emos_data/sms/boost_1_39_0/boost/archive/basic_text_oarchive.hpp", line 75.13: 1540-0700 (I) The previous message was produced while processing "boost::archive::basic_text_oarchive<boost::archive::text_oarchive>::sa "/s1a/emos_esuite/emos_data/sms/boost_1_39_0/boost/archive/detail/interface_oarchive.hpp", line 64.21: 1540-0700 (I) The previous message was produced while processing "boost::archive::detail::interface_oarchive<boost::archive::text_. "src/TestSerialisation2.cpp", line 86.20: 1540-0700 (I) The previous message was produced while processing "main()". vacpp.compile.c++ bin/vacpp/debug/src/TestSerialisation.o When the program is run, the following is produced by the debugger: Can't read type info for "basic_pointer_oserializer": Expecting mangled name, and didn't find one. Can't read type info for "basic_pointer_iserializer": Expecting mangled name, and didn't find one. Can't read type info for "singleton<boost__archive__detail__<unnamed>__guid_initializer<RepeatDate> >": Expecting ":", and didn't find one. Can't read type info for "singleton_wrapper<boost__archive__detail__<unnamed>__guid_initializer<RepeatDate> >": Expecting ":", and didn't find one. Can't read type info for "error_info_container": Expecting mangled name, and didn't find one. Can't read type info for "init_guid<RepeatDate>": Expecting ":", and didn't find one. it then throw an exception: archive_exception::unregistered_cast This is because the it thinks that Base/Derived class relationship has not been registered. (i.e RepeatBase/RepeatDerived in the enclosed example). It appears that: ar & boost::serialization::base_object<RepeatBase>(*this); is not registering the base/derived relationship on AIX. The actual point in the code where is throws an exception is >>>>>>>>>: // convert pointer to more derived type. if this is thrown // it means that the base/derived relationship hasn't be registered vp = serialization::void_downcast( *true_type, *this_type, static_cast<const void *>(&t) ); if(NULL == vp){ boost::serialization::throw_exception( >>>>>> archive_exception(archive_exception::unregistered_cast) ); } In the debugger variables true_type and this_type are of type boost::serialization::extended_type_info true_type: m_type_info_key unsigned int const 0x1100121b8 0x00000001 (1) m_key $string const * 0x1100121c0 0x1000b9748 -> "RepeatDerived" this_type: m_type_info_key unsigned int const 0x110012a40 0x00000001 (1) m_key $string const * 0x110012a48 0x00000000 It looks like the m_key data member of this_type is empty, I expected "RepeatBase" Has any one else hit a similar problem, where on one platform its ok and another it crashes ? Are there any workarounds I could try ? -- Best regards, Ta, Avi

2 1

AIX Boost 1.39 serialization warning message:
by Avi Bahra 23 Jul '09

23 Jul '09

Take the following simple use of serialization: //=============================================== #include <boost/archive/text_iarchive.hpp> #include <boost/archive/text_oarchive.hpp> #include <boost/serialization/base_object.hpp> #include <boost/serialization/utility.hpp> #include <boost/serialization/vector.hpp> #include <boost/serialization/string.hpp> #include <fstream> #include <assert.h> class Defs { public: Defs(const std::string& f) : fileName_(f) {} Defs() {} bool operator==(const Defs& rhs) const { return fileName_ == rhs.fileName_;} const std::string& fileName() { return fileName_;} private: std::string fileName_; friend class boost::serialization::access; template<class Archive> void serialize(Archive & ar, const unsigned int /*version*/) { ar & fileName_; } }; int main() { Defs saveDefs("saveFile.txt"); { // Save the defs file std::ofstream ofs( saveDefs.fileName().c_str() ); boost::archive::text_oarchive oa( ofs ); oa << saveDefs; } { // Restore the defs file Defs loadDefs; std::ifstream ifs(saveDefs.fileName().c_str()); boost::archive::text_iarchive ia(ifs); ia >> loadDefs; assert( saveDefs == loadDefs ); } return 0; } //=============================================== This produces the following messages from the AIX v10.1 compiler. vacpp.compile.c++ bin/vacpp/debug/src/TestSerialisation.o "/s1a/emos_esuite/emos_data/sms/boost_1_39_0/boost/archive/detail/oserializer.hpp", line 538.5: 1540-2400 (W) "boost::serialization::STATIC_WARNING" is undefined. The delete operator will not call a destructor. "/s1a/emos_esuite/emos_data/sms/boost_1_39_0/boost/archive/detail/oserializer.hpp", line 530.13: 1540-0700 (I) The previous message was produced while processing "boost::archive::save<boost::archive::text_oarchive,Defs>(text_oarchive &, Defs &)". "/s1a/emos_esuite/emos_data/sms/boost_1_39_0/boost/archive/detail/common_oarchive.hpp", line 64.9: 1540-0700 (I) The previous message was produced while processing "boost::archive::detail::common_oarchive<boost::archive::text_oarchive>::save_override<Defs>(Defs &, int)". "/s1a/emos_esuite/emos_data/sms/boost_1_39_0/boost/archive/basic_text_oarchive.hpp", line 75.13: 1540-0700 (I) The previous message was produced while processing "boost::archive::basic_text_oarchive<boost::archive::text_oarchive>::save_override<Defs>(Defs &, int)". "/s1a/emos_esuite/emos_data/sms/boost_1_39_0/boost/archive/detail/interface_oarchive.hpp", line 64.21: 1540-0700 (I) The previous message was produced while processing "boost::archive::detail::interface_oarchive<boost::archive::text_oarchive>::operator<< <Defs>(Defs &)" Does anyone know if the boost serialisation library is still actively maintained on this compiler ? Best regards, Ta, Avi

2 1

strange serialization compilation issue - serialize function not being compiled
by G, Benjamin (NSN - IN/Bangalore) 23 Jul '09

23 Jul '09

Hi, I have a class which has got the serialize function implemented. template<class Archive>void myClassB::serialize( Archive& ar, const unsigned int) Somehow, this function is skipped and doesn't appear even in the object file created for this file which gives me undefined reference errors later when linking. I have included : #include <boost/archive/text_iarchive.hpp> #include <boost/archive/text_oarchive.hpp> #include <boost/archive/binary_oarchive.hpp> #include <boost/archive/binary_iarchive.hpp> In my cpp file. Does this sound faimiliar to anyone? Or am I going wrong somewhere? Thanks in advance - Benjamin Jacob.

3 2

Spirit qi recommendations ? (avi)
by Avi Bahra 23 Jul '09

23 Jul '09

Hartmut Kaiser wrote: >> In order to reduce compile times I have decided to rewrite the >> parser/grammar >> from classic to spirit qi (spirit 2.1). My understanding is that >> faster >> compiles come from easier modularisation available under spirit qi. >> (As shown in mini_c example, in the boost tree) >> >> However I need this to be portable to as many platforms as >> possible. >> In my case minimum set is Linux,HP-UX, AIX. >> > > We never tried to compile Spirit on AIX/xlc. So any feedback is welcome. > Using gcc should be fine. > Steven Watanabe wrote: >>The trunk regression tests for spirit with xlc mostly fail >>with an internal compiler error. On AIX v10.1 boost 1.39, spirit classic gets stuck in an infinite loop, and spirit qi produces the following even on the simplest of grammars. My plans to migrate to AIX are equally stuck. "/s1a/emos_esuite/emos_data/sms/boost_1_39_0/boost/spirit/home/support/component.hpp", line 219.37: 1540-0711 (S) Too few template arguments have been specified. "/s1a/emos_esuite/emos_data/sms/boost_1_39_0/boost/spirit/home/support/modifier.hpp", line 83.59: 1540-0711 (S) Too few template arguments have been specified. "/s1a/emos_esuite/emos_data/sms/boost_1_39_0/boost/spirit/home/support/attribute_transform.hpp", line 71.17: 1540-0711 (S) Too few template arguments have been specified. >From googling around a similar error was found with boost tuple, (but must have been with a different compiler version) see: http://lists.boost.org/Archives/boost/2004/06/66550.php I have seen that a new patch for the v10.1 compiler was released in May 2009. I am not sure yet if I can access this patched compiler, If I can will let you know. Best regards, Ta, Avi

2 1

Using boost::asio::async_write to stream out data
by Alex Black 23 Jul '09

23 Jul '09

My app writes out a large amount of data to a socket, in a loop, in pieces, say 8kb at a time. I'd like to switch from using Socket::send to use asio::async_write. At a high level, what do I need to do? From my reading, I think I need to: 1. Call async_write instead of send 2. Ensure that my buffers have the correct lifetime - today since my writes are synchronous I re-use the same buffer over and over again - so instead, should I make a new buffer for each write? Whats a good way to ensure the buffer has the correct lifetime, e.g. how do I delete it once its been written out? 3. I understand I can't call async_write again before the first one has been completed (since I don't want my 8kb chunks interleaved), so should I maintain a queue of buffers waiting to go out? Then in my handle_write method should I check the queue, if at least one buffer is in the queue then I should start a new async_write? Thanks! - Alex

4 20

[coroutine] Assembler snippet for linux x86_64
by Pavel Shevaev 23 Jul '09

23 Jul '09

Hi folks, First of all I'd like to thank Giovanni P. Deretta for the brilliant idea and implementation of courotines [1]. Unfortunately, coroutines haven't been reviewed and included into the official boost repository yet but I believe it's just a matter of time. I downloaded the latest version "boost-coroutine-2009-04-30.tar.gz" from the boost vault[2] and it seems to build/run just fine on linux x86. However trying to build it on x86_64 gave me a compile time error - "This file is for x86 CPUs only" in swapcontext.cpp, since there is a #if !defined(i386) guard which produces this error. I was naive and tried to change "#if !defined(i386)" to "if !defined(i386) && !defined(__x86_64__)" in hope it would "just work" for x86_64...well, it didn't ;) I'm not that good in assembler(I have only basic knowledge), maybe someone stumbled upon the same problem and has a working patch for x86_64? Or maybe someone can give some pointers on how to make couroutines x86_64 compatible? IMHO, it shouldn't be very hard and I can try to do it myself, I just don't know where to start :) Thanks a lot in advance. [1] http://www.crystalclearsoftware.com/soc/coroutine/index.html [2] http://www.boostpro.com/vault/index.php?direction=0&order=&directory=Concur… -- Best regards, Pavel

3 7