- Boost - lists.boost.org

State of giallo, (sockets and demultiplexing)
by Hugo Duncan 16 Sep '04

16 Sep '04

Spend a few days off line and you suddenly miss a whole conversation :-( It's going to take a while to catch up... Recent IOstreams discussion has indeed been very interesting, espescially as I am finally getting round to implementing buffers and filters for giallo (boost.sockets). At the moment I am leaning towards ACE style message buffer, using the apache filter idea of flush/eos/eoc control (but trying to avoid any knowledge of the underlying resource). So where is giallo today (apart from being temporarily broken on gcc due to mpl changes)? i) Low level, platform header hiding, object based wrappers of sockets, named pipes, select, and completion ports (and a POSIX aio wrapper on linux that I have tried to get to work in many different ways and failed so far). ii) proactor and reactor interfaces, with policy based implementation, provided by bridge classes to the low level completion port and select wrappers above. iii) 'event completion notification' style connector, acceptor and connection classes for sockets and named pipes. These classes combine a demultiplexer with a resource (socket, pipe, etc), and can use a proactor or reactor demultiplexer interchangeably (via template parameter). The connection selects the synchronisation mode (block, non-blocking, asynchronous) of the socket based the demultiplexer. The library is thread aware (can run multithreaded, will create threads if asked to, uses threads to do asynchronous connect if not natively supported, etc) There is a streambuf implementation, but I have not found a way to implement this without it degenerating to a thread per connection model. I feel quite strongly that the decision to implement connection, connector and acceptor concepts with a single (in this case 'event completion' style) notification interface, regardless of the demultiplexer mechanism used, is very important, and can lead to a stream/filter concept that is independent of demultiplexer, of blocking/non-blocking/asynch mode and thus independent of the resource used.

5 12

RE: [boost] State of giallo, (sockets and demultiplexing)
by Hurd, Matthew 16 Sep '04

16 Sep '04

> The only exception I can think of is if the data is to be 'multicast' down 2 > TCP connections... Another exception for you: In place messaging with a "fast message" format would be nice for support. Some network hardware, including TCP via TOE cards and infiniband and the like, support very low latency messaging, e.g. < 10 microseconds. You don't want to copy, but also you don't want to serialize. In fact, for many applications you are prepared to sacrifice architecture portability on the altar of speed and you might send a contiguous c++ object, padding from alignment and all, directly as a message block. The CPU never has to see the whole object. A diminutive $0.02, Matt Hurd. IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

2 1

[mpl] gcc problem with include order dependency
by Hugo Duncan 16 Sep '04

16 Sep '04

Aleksey, With gcc (GCC) 3.3.3 (cygwin special) there is a include order dependency. Including boost/bind.hpp before boost/mpl/transform.hpp causes a compile error type named `type' in `struct boost::mpl::apply_wrap2<boost::mpl::push_front<mpl_::na, mpl_::na>, mpl_::arg<1>, wrapper<mpl_::arg<2> > >' I have not been able to test with other gcc versions. Regards, Hugo #include "boost/bind.hpp" #include "boost/mpl/transform.hpp" #include <boost/mpl/apply.hpp> #include <boost/mpl/list.hpp> #include <boost/mpl/equal.hpp> #include <boost/mpl/assert.hpp> // computed type template <typename T> struct wrapper{}; // metafunction class to compute type struct wrapped_type { template <typename T> struct apply { typedef wrapper<T> type; }; }; void test_transform() { typedef boost::mpl::list<int, char> typelist; typedef boost::mpl::list< wrapper<int>, wrapper<char> > wrapped_typelist; typedef boost::mpl::transform< typelist, wrapped_type >::type result; BOOST_MPL_ASSERT(( boost::mpl::equal<wrapped_typelist, result> )); }

3 3

RE: [boost] spirit 1.8 / vc 8.0 test results
by Reece Dunn 16 Sep '04

16 Sep '04

Paul A Bristow wrote: >I was under this impression from the MS docs, but a recent reply to my >query >by Brandon Bray at MS cites a 40901 release (perhaps an internal beta 2?), >whereas I have says 8.0.40607.16 but I am not sure if the compiler release >has changed. >(cl.exe file is 8.00.40607.16 too) I have beta 1 installed with the first tool refresh and have: Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.40809 for 80x86 Copyright (C) Microsoft Corporation. All rights reserved. I think 40607.16 refers to the initial beta1 release, 40809 refers to the first tool refresh and I assume that 40901 would be the second (upcoming) tool refresh. Regards, Reece _________________________________________________________________ Express yourself with cool new emoticons http://www.msn.co.uk/specials/myemo

3 2

RE: [boost] Where are they now? (needed license permissions)
by Ben Hutchings 16 Sep '04

16 Sep '04

John Maddock wrote: > Here are the people we still need to contact, in order to move the > rest of Boost over to the BSL, if anyone has a more up to date email > address for these folks than the ones shown here, please let me > know, as at present they're not responding :-( Where you've written "??" does that mean that you have no email address or that mail to it is bouncing? <snip> > Gennadiy Rozental ?? Subscribed as <gennadiy.rozental(a)thomson.com>. <snip> > Mathias Koch ?? Subscribed as <mail(a)mathias-koch.de>. <snip> > Stephen Silver ?? Possibly subscribed as <silver(a)gsc-game.kiev.ua>? > Terje Slettebø tslettebo(a)chello.no <snip> Subscribed and posted on Tuesday as <tslettebo(a)broadpark.no>. Ben.

1 0

[test] problems with new intel-win32-8.1 toolset
by Joaquín Mª López Muñoz 16 Sep '04

16 Sep '04

Just in case nobody noticed, seems like Boost.Test is failing with Intel 8.1. This error appears at run-time in plenty of tests: Exception in "call_test_main": memory access violation C:/boost_regression/boost/libs/test/src/unit_test_suite.cpp(127): fatal error in "call_test_main": Test case initialization has failed *** errors detected in test case "call_test_main"; see standard output for details Test case "call_test_main" was aborted due to uncaught exception, user assert or system error EXIT STATUS: 200 I'm quite sure the problem is in Boost.Test, since the crash happens at several different libraries, all of which use this Boost.Test. Maybe someone with local access to this compiler can debug some of the failing tests and narrow down the locus of the problem. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

4 3

Serializing bitsets and tuples
by Brian Riis 16 Sep '04

16 Sep '04

Again, Robert, I have to thank you immensely for the Serialization library. It has made my life much easier. Anyway, I was wondering, since you state in the manual that all STL containers are supported, why I can't seem to find std::bitset in that. I realize that it is probably not the most common container to serialize, but still. Also, considering the is Boost library now, I'm wondering about the apparent absence of serialization for boost::tuple. It's not the end of the world (I can write them myself rather easily, I suppose), but for completeness I'd think at least Boost.Tuple should be supported. -- /Brian Riis

2 2

Boost Software License: Summary
by John Maddock 16 Sep '04

16 Sep '04

I've made a set of summaries for BSL conformance available at http://freespace.virgin.net/boost.regex/index.html There's one summary per library + one for all of Boost, I'd encourage everyone to take a look to see whether their work can be used under the BSL alone, or if there are non-BSL dependencies that they rely upon. Note that there are one or two cases where dependencies are found that are not real: filesystem for example ends up being shown as dependent upon the Graph lib (not under the BSL), but this is an illusion, based on iterator_adapters pulling in some python headers, which leads to a presumed dependence upon the python source. In most cases though the information shown should be accurate. Regards, John.

4 6

Howto track changes?
by Neal D. Becker 16 Sep '04

16 Sep '04

I did cvs update recently on boost-cvs, and found lots of changes - probably anticipation 1.32. I don't see a way to get a summary of changes. Does boost have such a mechanism? At mimimum, a ChangeLog for each lib. As an example of best-of-class, http://cvs-digest.org/?issue=aug202004

1 0

It seems that boost.random doesn't work under vc6.0?
by huangliang 16 Sep '04

16 Sep '04

When I tried to compile the random_demo.cpp using vc6.0 and stlport5.0, there were many errors and warnings. Does boost.random correctly work under vc6.0? I use boost1.31.0.

1 0