- Boost - lists.boost.org

boost::asio::streambuf problem
by rod haxton 18 Oct '08

18 Oct '08

Hello, "Long time listener, first time caller..." I'm struggling with the "boost::asio::streambuf," and the "boost::asio::async_read_until." I'm trying to wait on the async_read_until, which I can do after the first message is sent, but subsequent messages received cause the streambuf to continuously grow. I am trying to use the streambuf via the .data() member. void TAsioSession::Start() { boost::asio::async_read_until(m_Socket, m_szAsioData, boost::regex("\n"), boost::bind(&TAsioSession::HandleRead, this, boost::asio::placeholders::error, boost::asio::placeholders::bytes_transferred)); } void TAsioSession::HandleRead(const boost::system::error_code& error, size_t bytes_transferred) { if(!error) { boost::asio::streambuf::const_buffers_type bufs = m_szAsioData.data(); std::string szBuffer( boost::asio::buffers_begin(bufs), boost::asio::buffers_begin(bufs) + bytes_transferred); LP_ICPACKET lpICPacket = reinterpret_cast<LP_ICPACKET>(const_cast<char*>(szBuffer.c_str())); // reset streambuf for reading (how?) . . . Start(); } Once I grab the data that is in the buffer, I want to reset the streambuf and go back to "async_read_until," and wait for another message to come in. I try to do the following to reset the streambuf pointers... // set the current put/get ptrs of streambuf to beginning of stream m_szAsioData.commit(-m_szAsioData.size()); m_szAsioData.consume(-m_szAsioData.size()); // clear the streambuff char szClear[512]; ZeroMemory(szClear, 512); m_szAsioData.sputn(szClear, sizeof(szClear)); m_szAsioData.sgetn(szClear, sizeof(szClear)); // set the current ptrs of streambuf back to beginning m_szAsioData.commit(-m_szAsioData.size()); m_szAsioData.consume(-m_szAsioData.size()); but the new message isn't at the head of the buffer, it is coming in at position 512 of the streambuf, and the streambuf grows. Any help would be appreciated. Thanks, Rod

1 1

[serialization] non-windows platform broken
by Juergen Hunold 18 Oct '08

18 Oct '08

Hi ! It seems that http://svn.boost.org/trac/boost/changeset/49349 Log: updated spirit headers to use "classic" broke the serialization build for all non-msvc and non-borland builds (all unices in fact ;-))) See http://www.boost.org/development/tests/trunk/developer/serialization.html for the yellow and red markers. And see http://tinyurl.com/5ltbd6 for details. The reason seem to be workaround macros like // spirit stuff #if (defined __BORLANDC__) && (__BORLANDC__ < 0x593) \ || (defined _MSC_VER) && #if (_MSC_VER <= 1300) #else #include <boost/spirit/home/classic/utility/chset.hpp> #endif found in boost/archive/impl/basic_xml_grammar.hpp where the #else clause contains non-existent headers. I've tried to fix this, but got lost in the vast amount of old, new and phoenix variants of spirit ;-(( 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

[repost] outdated status\expected_results.xml
by JOAQUIN M. LOPEZ MUÑOZ 18 Oct '08

18 Oct '08

Hello, I first posted this some days ago, allow me to repost just in case it went unnoticed: This file has not been updated since 08/12/07: http://svn.boost.org/trac/boost/browser/trunk/status/expected_results.xml which suggests it contains the expected results for Boost 1.34.1. So, Boost 1.36 tests are and 1.37 tests will be comparing against an outdated file (each version should compare against the former). There doesn't seem to be any documentation on Boost about how to do the updating, and the file is not even mentioned at the release manager's checklist at http://svn.boost.org/trac/boost/wiki/ReleasePractices/ManagerCheckList Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

Re: [boost] New library in Vault: Msm (Meta State Machine)
by Christophe Henry 18 Oct '08

18 Oct '08

Hi Andreas, First of all, thank you for taking the time for such a lengthy answer. > So IIUC then you think that transitions crossing state boundaries are bad > practice and should be avoided at all costs? Yes I do (not at any cost of course). Not only because it looks to me like a goto, but also because I feel it is a breach of encapsulation, for example, in the diagram, the "alarm-beeps" state is showing its implementation. It is also unclear to me if the entry method of "alarm-beeps" will be called. > OTOH, the transition triggered by x can only be > made non-state-boundary-crossing by introducing a guard, which is IMO less > concise than allowing for the transition as shown in the chart. This is a matter of taste. I personally prefer this as it reduces the coupling of the system. > As an aside, I don't see much of a connection of state-boundary crossing > transitions with goto. Given your code in the C() function, any transition > could/would be implemented with goto? What I mean is that if you imagined a transition processing as a function call, code using entry pseudo-states would in effect look like the code in the C() function where you could skip the initialization work done in the entry of C and B. It was not meant as real code but as illustration. Sorry if I didn't manage to make my point clear. > Given the examples in the Harel paper and the fact that the UML standard > expressly allows them, I would encourage you to support them. So does C++ support goto and breaching encapsulation, and it still doesn't make them desirable to me. Now, I thankfully take the feedback, and if confirmed, I will add the entry/exit states. > for the same reasons I don't detect value in seeing a composite state as a fully > fledged state machine (as your framework seems to do). I know that the UML > has so-called submachines but they are really just simple composite states > with entry and exit points thrown in. I admit the UML standard is not too clear in its description of submachines but states the goal clearly (UML Superstructure specification v2.1.2 p549), as: "Submachine state is a decomposition mechanism that allows factoring of common behaviors and their reuse". And this is a main design point for Msm. Submachines in Msm intend to be reusable blocks, like classes and functions. They have entry points (entry conditions and initial states), can be defined in different files and reused in different state machines. What defines a FSM with Msm is its transition table, not the inside of submachines. Submachines can be reused in different main state machines and the link between all is the transition table. Now, if the outside world knows the inside of the submachine, which would in turn know about the outside world, I'm afraid it'll be hard for submachines to be reused. However, your example and your point of view are very interesting as they force me to offer a better solution than the one I have (which would be in the init state to forward the events manually). Would the following compromise solution be acceptable to you? Like with deferred events, it would be possible to define automatic forwarding in a state (like the initial one) like this: typedef mpl::vector<T,T1,T2> forward_events; and at the end of the transition, these events would be resent (to the corresponding beep state as defined in the transition table). Like this, it is guaranteed that the entry methods are called, thus ensuring safe initialization and we would come close to an entry pseudostate. To explain better, I uploaded an image into the Vault. Regards and thank you for your time! Christophe

3 2

[1.37] [dynamic_bitset] Permission to port to the release branch
by Gennaro Prota 18 Oct '08

18 Oct '08

The latest changes to dynamic_bitset are either documentation improvements (markup, contents, wording) or removals of workaround code for compilers on which no tests are run anymore. I'll wait for a trunk test cycle anyway, but I thought to ask with some anticipation for permission to port them to the release-ready branch. -- Genny

2 2

Newbie want to get involved in boost projects and prepare for 2009 GSoC
by 徐兴军 18 Oct '08

18 Oct '08

Hi,all: I am a graduate student, and good at algorithm. If I want to get involved in boost projects and prepare for 2009 GSoC, which specific projects are suitable for me ? And how can I get started ? Thank you !

1 0

Re: [boost] [asio] [bind] ambiguous bind templates for asio::write() and asio::read()
by Gregory Dai 18 Oct '08

18 Oct '08

*code:* .... asio::streambuf response; size_t siz = asio::read(sslSock, response); .... *compilation error (g++ 3.4.6 on RHEL4):* asio/1.3.0/asio/impl/read.ipp:107: instantiated from `size_t asio::read(SyncReadStream&, asio::basic_streambuf<Allocator>&) [with SyncReadStream = asio::ssl::stream<asio::basic_stream_socket<asio::ip::tcp, asio::stream_socket_service<asio::ip::tcp> >, asio::ssl::stream_service>, Allocator = std::allocator<char>]' asio/1.3.0/asio/ssl/detail/openssl_stream_service.hpp:415: error: call of overloaded `bind(int (*)(SSL*, void*, int), boost::arg<1>, void*, int)' is ambiguous boost/1.36/boost/bind.hpp:1298: note: candidates are: boost::_bi::bind_t<R, F, typename boost::_bi::list_av_3<A1, A2, A3>::type> boost::bind(F, A1, A2, A3) [with R = int, F = int (*)(SSL*, void*, int), A1 = boost::arg<1>, A2 = void*, A3 = int] boost/1.36/boost/bind/bind_cc.hpp:47: note: boost::_bi::bind_t<R, R (*)(B1, B2, B3), typename boost::_bi::list_av_3<A1, A2, A3>::type> boost::bind(R (*)(B1, B2, B3), A1, A2, A3) [with R = int, B1 = SSL*, B2 = void*, B3 = int, A1 = boost::arg<1>, A2 = void*, A3 = int] Also, asio::write(sslSock, response); resulted in a similar error.

1 0

[proto] reorganized users' guide
by Eric Niebler 18 Oct '08

18 Oct '08

I've just completed a major reorg of Proto's docs, with significant portions clarified or completely rewritten. I intend to merge these changes to the release branch soon. I encourage any and all interested parties to click around and offer feedback. The purpose of the reorg was to make the users' guide more approachable and less reference-y. It takes the view that a library built with Proto is a compiler for a DSEL, and as such it has 3 parts: front-end, intermediate form, and back-end. The guide is organized accordingly. You can find the new guide here: http://boost-sandbox.sourceforge.net/libs/proto/doc/html/index.html TIA, -- Eric Niebler BoostPro Computing http://www.boostpro.com

5 7

thread build on solaris
by Edward Peschko 18 Oct '08

18 Oct '08

All, I'm trying to compile a thread with the boost, threading libraries, and am getting errors like these. gcc -o conftest -g -O2 -I/GAAL/pesced_release/install/fuego/include/boost-1_36 -L/GAAL/pesced_release/install/fuego/lib /tmp/aa.c -lboost_thread-gcc43-mt /GAAL/pesced_release/install/fuego/lib/libboost_thread-gcc43-mt.so: undefined reference to `__cxa_allocate_exception(a)CXXABI_1.3' /GAAL/pesced_release/install/fuego/lib/libboost_thread-gcc43-mt.so: undefined reference to `std::basic_string<char, std::char_traits<char>, std::allocator<char> >::_Rep::_M_destroy(std::allocator<char> const&)(a)GLIBCXX_3.4' /GAAL/pesced_release/install/fuego/lib/libboost_thread-gcc43-mt.so: undefined reference to `std::bad_alloc::~bad_alloc()@GLIBCXX_3.4' /GAAL/pesced_release/install/fuego/lib/libboost_thread-gcc43-mt.so: undefined reference to `__cxa_throw(a)CXXABI_1.3' This is on solaris 2.10, using gnu ld (version 2.18..) Any ideas on how to get around this? Ed

1 0

Re: [boost] Measuring compile time performance
by dan marsden 17 Oct '08

17 Oct '08

Steven Watanabe wrote: >Joel de Guzman wrote: >> time is good enough for benchmarking. OTOH, Steven's perl sript >> is nice because it can (as he says) actually gather info when >> templates are being instantiated. I haven't used it yet, but it >> seems to be just the tool we need for profiling templates. >> Steven, please tell us more about your script. > >The scripts are actually a combination of bjam + perl + C++. > >At the moment, the only thing that it does reliably is to >count the number of times each template is instantiated. > >A month or two ago, I tried to make it produce a gprof-like >call graph by parsing the instantiation backtraces, but it >doesn't really work, and I broke gcc support in the process. >Hmmm, I'll try to fix this over fall break. Thanks Steven, that would be great. We'd certainly be interested in trying what you've got on Fusions compile time performance tests. Thanks to everyone else that provided ideas on this. Dan Send instant messages to your online friends http://uk.messenger.yahoo.com

3 2