"Jeremy Maitin-Shepard" <jbms@cmu.edu> wrote in message news:87acjedijx.fsf@jbms.ath.cx...
"Thorsten Ottosen" <nesotto@cs.aau.dk> 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