Boost logo

Boost :

From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2005-08-18 17:10:30


"Jeremy Maitin-Shepard" <jbms_at_[hidden]> wrote in message
news:87acjedijx.fsf_at_jbms.ath.cx...
> "Thorsten Ottosen" <nesotto_at_[hidden]> writes:
> >> reason to use std::vector. I do not think the additional safety
> >> provided is worth the cost of this overhead.
>
> > doesn't the overhead depend on the amount of data sent?
>
> I suppose that is true. If a vector must be passed to the receive
> function, then programs using this library will either have to use an
> std::vector for any buffers used for receive, which is annoying for
> users that would prefer to use a different data structure for a buffer,
> and has the additional overhead of a dynamically allocated buffer and
> the additional storage std::vecetor requires for the size, capacity, etc.

the space required by vector is 3 words. that is not much for many purposes.

> some additional safety, while introducing a more complex and less
> generic interface.

how is passing 1 agument instead of two going to be more complex?
is it because you can't get the size wrong? :-)

> >> Requiring that the size be known at compile-time, and that an actual
> >> static-sized array be used in order to call the receive function, is
> >> definitely not a good idea.
>
> > Then why do all the examples work on statically sized arrays?
>
> Well, there aren't many examples, and I didn't write them in any case ;)
> I'll admit it is a common network I/O paradigm to read into (large)
> fixed-size buffers, but there are certainly other usage patterns (such
> as reading a fixed-size ``packet'' length specification, and then after
> ensuring that the buffer is large enough, reading the entire ``packet''
> of the specified length with a single read/recv call. Furthermore, even
> a fixed-size buffer that is used might have its size specified at
> runtime.

right. so by passing char (&)[N] you can check that the
size argument is not too big. with void* you're just lost.

-Thorsten


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk