- Boost - lists.boost.org

Serialization: docs addition
by Darren Cook 23 Apr '05

23 Apr '05

Hi, Can I suggest adding another example to: http://www.boost.org/libs/serialization/doc/special.html#objecttracking I had this code: void mycallback(const BigClass &BC){ const SomeData *d=BC.get_data(); ... archive & BOOST_SERIALIZATION_NVP(d); } My archive was smaller than intended and I discovered that the data only got saved the first time. XML version showed me it was using: object_id_reference. It turns out the fix was to dereference the pointer: archive & BOOST_SERIALIZATION_NVP(*d); That is an easy to write bug; I cannot see how the serialization library can catch it, so all I can think of is to make people aware of it in the docs. Also please mention "object_id_reference" in the objecttracking section of the docs, as that was the first thing I googled on and it got no useful hits. Darren

2 2

[website] Fluid layout.
by Rene Rivera 23 Apr '05

23 Apr '05

OK I've done more changes/improvements. It's now a fluid layout. Since no one except Dave had suggestions on what to I went with his idea of two (mostly equal) columns. In this case the left is fluid the right is fixed. I also removed everything except the latest release information. For the simple reason that more than that make the page unnecessarily long. After all anything older than the latest version isn't "Latest News". http://redshift-software.com/~grafik/boost/index.htm -- -- 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

11 26

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

23 Apr '05

Hi guys, > Peter Dimov wrote: >>Michel Andr� wrote: >> Should several pending reads be allowed? I have >> leaned back and forth on this issue in a previous >> platform specific async com library I wrote. > > Definitely; a server that has N active connections > might have up to N reads active at any time. Not > on the same socket, of course. :-) If I understood Michel's question correctly, then your answer would be "no". As would mine. There's the question of need (which, IMO is close to 0) plus the added complexity of explaining/managing FIFO read order; and don't forget multiple threads making simultaneous reads - just say NO. :) Best, Don __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

New Singleton Release!
by Jason Hise 23 Apr '05

23 Apr '05

I'm pretty confident that this is the last major update before the review starts. All new library features and changes are explained in the documentation. The new library is available here: http://tinyurl.com/6qvrd -Jason

1 2

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