- Boost - lists.boost.org

Re: [network] An RFC - updated
by Don G 23 Apr '05

23 Apr '05

Hi Michel & Peter, --- Peter Dimov wrote: > Michel Andr� wrote: >> This means we have one global dispatcher for the library >> (completion queue in asynch case). Isn't there a need to >> have several dispatchersto be able to group connections >> to several dispatchers/pollers. > > You can probably guess that I think that the answer is no. ;-) And I would agree. :) I can see no particular reason to expose the arbitrary grouping of network objects to the user. I can see the need for multiple dispatchers, but at most one per thread. Best, Don __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

Re: [network] An RFC - updated
by Don G 23 Apr '05

23 Apr '05

Hi Iain, > A connector sets socket options that can not be set after a call to > connect on a TCP connection! In the proposal I am making, the stream is created without being connected. So, it could offer pre-connection configuration. Of course, those methods would just be sitting there (temptingly<g>) after connect was performed. But, so I suppose would the connector if it were an object. If there are some significant options to be set, I could see them effectively becoming ctor arguments. Perhaps packaged in a stream_options bundle. Just some ideas. 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: (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