April 2005 - Boost - lists.boost.org

Re: [boost] Re: (Another) socket streams library
by Iain Hanson 22 Apr '05

22 Apr '05

On Thu, 2005-04-21 at 19:30 -0700, Jeff Garland wrote: > I notice we don't have a buffer concept in any of our net/socket writeups on > the wiki. I think that's a big omission. I also wonder if the abstraction > doesn't already exist --> std::basic_streambuf. Let the socket class write > into the streambuf and then you can trivially wrap a stream around it to do > sophisticated i/o if you wish -- or simply pull out the raw chars.... > A buffer concept is absolutely essential for TCP. Without it you will run into delays with Nagle, delayed ack and slow start all combine-ing. Yuk! Streambuf makes sense for the iostream concept. For lower layers the buffer concept needs to be a model of contiguous container. Iterator type can only be guessed at because I don't know what goes on inside the 'C' socket lib or the kernel but first guess would be forward iterator. /ikh

4 4

VC 7.0 template specialization problems
by Jason Hise 22 Apr '05

22 Apr '05

The following specialization fails to compile on .NET 2002. Is there a good reason as to why, and if not, is there a suggested work around? template < typename T > class A { }; template < typename T > class B { }; template < typename T > class A < B < T > > // this is the specialization { }; -Jason Hise

3 4

Re: [boost] Re: (Another) socket streams library
by Iain Hanson 22 Apr '05

22 Apr '05

On Fri, 2005-04-22 at 12:06 -0300, pedro.lamarao(a)mndfck.org wrote: > Iain Hanson wrote: > > [SNIP] > > > A buffer concept is absolutely essential for TCP. Without it you will > > run into delays with Nagle, delayed ack and slow start all combine-ing. > > Yuk! > > > > Streambuf makes sense for the iostream concept. For lower layers the > > buffer concept needs to be a model of contiguous container. Iterator > > type can only be guessed at because I don't know what goes on inside the > > 'C' socket lib or the kernel but first guess would be forward iterator. > > Well, if you think about it, the streambuf *is* the lower layer buffer > concept (unless you consider ir a buffer over the "kernel buffer"). The > methods it offers are simple: get char, put char, and the like. > > Exposing a "socket" class is a requirement only if the proposed library > wants to try to interface with old, "hybrid" code, provide the > possibility for some kind of "extension" I really can't think of. A > C++-only library could just not have a "socket" class, or consider it > "private", and expose as the most basic thing the stream buffer. If you > don't need the buffering itself, call pubsetbuf(0, 0). I agree that the socket class may be private detail for an iostreams implementation but I do not agree that all network i/o should be done this way. I don't think that iostreams as a model works well for packet protocols. BTW do you use path MTU or MSS to set your streambuf size? /ikh

2 1

Re: [boost] Re: [network] An RFC - updated
by Iain Hanson 22 Apr '05

22 Apr '05

On Fri, 2005-04-22 at 20:03 +0300, Peter Dimov wrote: > Iain Hanson wrote: > > I really don't see this as workable in the general case. The library has > > to guess the size of the read buffer. It would also prevent reading a > > complete record on a stream by reading a header up to the length field > > and then making a 2nd read call for that length with the correct size > > buffer. > > This is a good point, but async_read can take a size parameter, even when > the client does not supply a buffer. True. > > > It would also add dynamic memory allocation to the library > > I'm not sure that you can beat the library from the client side with respect > to the number of memory allocations. With N asynchronous reads active you > need to keep N buffers alive. The library can manage with just one in the > select case. > pre-allocate a set of buffers and hold them in condition variable protected queue. > > and be a source of runtime errors as a result a user not copying the > > buffer > > and trying to use it after its lifetime expired. > > I'm fairly confident that manual buffer management will introduce even more > runtime errors. ;-) (That's been my experience with async reads/writes, at > least.) And use the active object pattern instead of callbacks ( producer/consumer ) :-). /ikh

1 0

About refactoring C++ program
by zlf 22 Apr '05

22 Apr '05

Hi, Manually refactor C++ program is anonying and inefficient. Who can tell me some refactoring tool working on C++ code. I have searched google, but nothing valuable found:( Thx zlf

5 5

[ptr_container] comparison operators
by Fredrik Blomqvist 22 Apr '05

22 Apr '05

I can't find any code or docs dealing with comparison in the current CVS. Weren't ptr_container supposed to have deep comparison semantics? Regards // Fredrik Blomqvist

4 10

Re: [boost] Re: (Another) socket streams library
by Iain Hanson 22 Apr '05

22 Apr '05

On Fri, 2005-04-22 at 12:17 -0300, pedro.lamarao(a)mndfck.org wrote: [snip] > I don't think it is necessary to throw an exception from the stream to > signal it, for the same reason the stream can signal other kinds of > errors without throwing exceptions. The standard basic_ios base class is > even nice enough to offer the exceptions(iostate) "property" for you to > choose if you want or don't want exceptions to be thrown. Nothing new here. > > I believe a non-blocking mode is possible for std::iostream, but I'm > unsure of how... elegant would it be to use it. > > But should we offer the possibility for the user to set socket options, Yes. > or merely offer a blocking(bool) method? > > Also, how should the stream object behave in case of EWOULDBLOCK? Set > failbit? Even if we use a wouldblockbit, we still need to set failbit, > as the only thing clear is that the operation was *not* successful. > I don't think you want to set failbit as it is sticky and must be manually reset and EWOULDBLOCK is not an error. /ikh

1 0

Visual Studio 2005 Beta 2 + Multi Index
by Gordon Smith 22 Apr '05

22 Apr '05

The following stdafx.h for a vanilla console app kills the beta 2 compiler (I think it creates a corrupt PCH file): #pragma once #define WIN32_LEAN_AND_MEAN // Exclude rarely-used stuff from Windows headers #include <windows.h> #include <tchar.h> // BOOST --- #include <boost/multi_index/sequenced_index.hpp> #include <boost/multi_index/ordered_index.hpp>

1 0

Re: [boost] Re: [network] An RFC - updated
by Iain Hanson 22 Apr '05

22 Apr '05

On Fri, 2005-04-22 at 16:24 +0200, Peter Simons wrote: > Iain Hanson writes: > > >>> This would give a significant performance hit as there > >>> will now be two copies of the data. > > >> Not if the callback doesn't make any copies. > > > That is a long way from being the common case. > > Maybe, maybe not. My point is that whether or not data has > to be copied depends on the _callback_, not on the I/O > driver. Your original statement made it appear as if copying > of data would be inevitable in a callback-driven design -- > and it is not. > No. Copying the data becomes probable when the lib provides the buffer. Nothing to do with callbacks. > > > I really don't see this as workable in the general case. > > The library has to guess the size of the read buffer. > > No, the caller can provide the capacity (or the buffer). > > > > It would also prevent reading a complete record on a > > stream by reading a header up to the length field and > > then making a 2nd read call for that length with the > > correct size buffer. > > Why exactly would that be impossible in a callback-driven > design? > > > > It would also add dynamic memory allocation to the > > library [...]. > > Let the user pass the buffer when calling the driver, and > then there's no memory management at all. This is what I was arguing for. /ikh

1 0

Re: [boost] Re: Re: (Another) socket streams library
by Iain Hanson 22 Apr '05

22 Apr '05

On Fri, 2005-04-22 at 13:26 +0300, Boris wrote: > Caleb Epstein wrote: > > [...] > > concise, which is a tribute to the your implementation. At the same > > time, it is missing asynchronous and/or non-blocking operations and > > any means for doing single-threaded I/O multiplexing (e.g. > > select/poll/etc). > > But these don't belong to a streams library anway - at least I wouldn't know > how to support these I/O models without changing the stream interface. > Sorry, but I think that they do. At least both non-blocking and a reactor. I don't see why just because you are using iostreams that these become excluded. /ikh

1 0