- Boost - lists.boost.org

Re: Network library: What we have until now
by Don G 13 Apr '05

13 Apr '05

Hi Doug, > Here's more motivation: the C++ committee is planning > to finish the next revision of the C++ standard in the > next few years, and I stress *few*. Boost has been a > wonderful source of libraries for the C++ committee, > and C++ would be greatly improved if the next version > of the standard library contained a sockets library... > this library could be that library, but we have to > finish it, review it, and be sure it's right. We can't > review what doesn't come up for review. "Finished" is > more important than "complete". That possibility was actually my motivation for getting involved with Boost. :) I believe that the proposal I posted fits with this goal, while a "socket library" does not. It was only recently posted here, but it has been under development at my work (where I recently got permission to get involved with Boost) for many years. In the process of posting to Boost, I have reworked it a bit to make it more "boost-like". There are only a few concepts in general use that are not covered in my proposal, but those can always be added. The abstractions I proposed can be implemented on virtually any modern OS and, because it makes minimal assumptions about stream and address semantics, can describe a non-TCP/IP network (within limits, of course<g>). I have done so using HTTP tunnels and reflecting servers (as I mentioned elsewhere). Sockets are an API to a network. A concept, and not a universal one as far as I know. What is needed, IMHO, is a C++ description of those concepts, not a "wrapper over sockets" (though that would come at a lower level since sockets are just about everywhere we want to be<g>). It would be like having iostreams be a "wrapper over Windows Kernel Objects" ;). Clearly, it uses such things on Windows, but that API has no impact on the C++ interface, nor should it. Best regards, Don __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

Re: Network library: What we have until now
by Don G 13 Apr '05

13 Apr '05

Hi Boris, Boris wrote: > The multiplexing interface can be used in a > single-threaded application while the async stuff > will be multi-threaded. There might be network > developers (like me for example :-) who don't want > to synchronize callbacks but just want to build > the whole application around a blocking call to > select (or any other multiplexing operation). What I was trying to get at is that this can be provided by the boost::function<> queue apporach. Possibility #1: Using the general async library (like the one I proposed<g>), pass callbacks that have built-in enqueue behavior. Possibility #2: A simple/single call to the network object could tell it to queue calls to completion handlers instead of make them immediately. I prefer #1, but #2 would be simpler to use. The idea is that one does not abstract an fd_set, rather one describes the target of notification callbacks. > Basically I like the idea to have an async I/O > library just like std::iostreams which supports > synchronous I/O. However I don't know how difficult > it is to implement such a library but isn't POSIX > aio exactly about this? I like the idea of async I/O facilities, I just don't believe that there can be much of an async I/O library that lies _beneath_ files, networks, etc.. >>> * On a low level the network library should be close to >>> what is known as Berkeley sockets to many programmers. >> >> I think sockets should be hidden. > > Opinions seem to vary on this. When I once proposed to > build a C++ network abstraction with I/O streams I got > complaints that it should be possible to use sockets > directly in a lower level. Whatever you write the other > group will join the thread and complain. :) Agreed ;). What I have proposed does not entail iostreams, rather it is an abstraction of primitives. > Yes, that's why I am trying to find a design the > majority agrees with. If we end up with several network > libraries implemented by different people noone will do > the effort to understand and compare design decisions. An effort that is worth doing :) Best, Don __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

Re: [boost] Re: Re: Network library: What we have until now
by Iain Hanson 13 Apr '05

13 Apr '05

On Wed, 2005-04-13 at 12:54 +0300, Boris wrote: > Douglas Gregor wrote: [snip] > That's why I started this thread yesterday to > ask if we have now a few things everyone agrees with and we can move on. Boris, there are lots of things in this thread that I disagree with. However, I don't have either the time or the energy to explain them all and work on my own Library in which I have already invested 3 years work. [snip] I > I wish there was a network library already. But > the reason why people started with a socket library and then left again > unfinished is that there are lots of different opinions about what this > library should do and look like. Some of us have not left but are working quietly in the background. predominately because we have seen the same kinds of discussions happen over and over. The main reason we do not have a socket lib is that even to produce a basic lib supporting blocking, non-blocking and signal driven is that it is a very big undertaking to produce good type safety, and be able to cope with the richness of the BSD socket API functionality. /ikh

2 1

Re: [boost] Re: Network library: What we have until now
by Iain Hanson 13 Apr '05

13 Apr '05

Hi, On Wed, 2005-04-13 at 11:24 +0200, Douglas Gregor wrote: > On Apr 13, 2005, at 10:49 AM, Boris wrote: > > Here's the problem: we've been discussing and working on a sockets > library for *years*. People have come, started working on it, and left > before anything ever came up for review. It's getting to the point > where it's become embarrassing to Boost that we *don't* have a sockets > library yet. > > Here's more motivation: the C++ committee is planning to finish the > next revision of the C++ standard in the next few years, and I stress > *few*. Boost has been a wonderful source of libraries for the C++ > committee, and C++ would be greatly improved if the next version of the > standard library contained a sockets library... this library could be > that library, but we have to finish it, review it, and be sure it's > right. We can't review what doesn't come up for review. "Finished" is > more important than "complete". > I won't make any promises ( i did that before and was not able to keep them ) but I'm hoping to publish my socket lib ( layer 1) in the next few weeks. The design is complete ( I hope ) after many revisions and I am currently implementing it again. Basic concepts supported are: address socket select fd_set socket_options Protocol support is for IPv4 and IPv6 with unicast, broadcast, and multicast. additionally, I have support for routing, raw, and data link layer sockets. Initial implementation will be for gcc and Linux only and once I have had a preliminary review I'll add Intel on Linux , and GCC on Windows Impl. /ikh

1 0

[mpl] BOOST_MPL_AUX_ASSERT_NOT_NA problem
by Daniel Wallin 13 Apr '05

13 Apr '05

This problem is showing up in the Parameter library: http://tinyurl.com/4tmy7 I think this is a problem with the assert mechanism in MPL, because if you change boost/mpl/aux_/na_assert.hpp so that it always uses BOOST_STATIC_ASSERT instead of BOOST_MPL_ASSERT_NOT the Parameter tests compile. -- Daniel Wallin

1 0

[regression testing] Is likely broken right now...
by Rene Rivera 13 Apr '05

13 Apr '05

This change by Danile Wallin: http://build.redshift-software.com:9990/changes/156 Change #156 Is causing errors in the build about missing test targets: http://build.redshift-software.com:9990/RSI-SoL-OnDemand/builds/13/boost.ja… (ignore the timeout error, that's my problem) -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org

5 9

examples in regression testing
by Gennadiy Rozental 13 Apr '05

13 Apr '05

Hi, As you've noticed I added Boost.Test examples into status/Jamfile (as it was recommended to me).Unfortunately I do not see any results on status pages. Any help? Gennadiy

1 0

[vc 8.0] toolset
by Gennadiy Rozental 13 Apr '05

13 Apr '05

Here is an error I am getting when trying to use vc-8_0 toolset: ....\boost\test\impl\execution_monitor.ipp(66) : fatal error C1083: Cannot open include file: 'wtypes.h': No such file or directory But I see it working during regression testers runs. What do I need? Gennadiy

1 0

Re: Network library: What we have until now
by Don G 13 Apr '05

13 Apr '05

Hi Doug, I would be curious to hear your thoughts on the proposal I posted to the sandbox (network.zip). The complete implementation (including URL class, thread pooling, load balancing, etc.) was < 9000 lines and that includes tons of comments (see network.hpp for a frame of reference). I wrote it from scratch in 3 weeks (once the design was finalized). Or rephrased from a previous message: it's not the technical challenges that take all the time; it's the design process ;) Best, Don --- Douglas Gregor <doug.gregor(a)gmail.com> wrote: > I think the scope of this library is insane. We don't need > to solve every single network I/O problem with one huge > networking library. > > Having a solid socket library that handles only blocking > with be a _huge_ improvement . Start small and don't be > afraid to say "No! That's for the next version." > > Doug __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/

1 0

Regex-User: ISBN validation
by Detlef 12 Apr '05

12 Apr '05

Hi, we need to validate ISBN. With another REGEX-implementation we uses (?=.{13})\d{1,5}( |\-)\d{1,7}\1\d{1,6}\1(\d|X). But this seem not to work. Only the shorter version "\d{1,5}( |\\-)?\\d{1,7}\\1\\d{1,6}\\1(\d|X)" works, but how to check the 13 digits? Thanx in advanced Detlef

7 8