"Thorsten Ottosen" <nesotto@cs.aau.dk> writes:
"Jeremy Maitin-Shepard" <jbms@cmu.edu> wrote in message news:87iry3c9cn.fsf@jbms.ath.cx... [snip]
std::vector<char> (even with additional offset and length parameters) introduces significant overhead for users that do not otherwise have any 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::vector requires for the size, capacity, etc. Alternatively, the user could create an std::vector just for each receive call, then copy the data out after it completes. In either case, though, although the additional cost may be rather small compared to the cost of network I/O, it is an additional cost which provides only some additional safety, while introducing a more complex and less generic interface. The ideal interface would be an output iterator and a size, but this cannot be used efficiently; an arbitrary memory range seems like the next most generic interface, and this is also precisely the interface supported by operating systems. [snip]
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.
If we're not working on statically sized arrays, then why not use vector?
There are many possible reasons, but the point is, there is no reason to force the user to use vector, when doing so provides no real benefit.
I'm not convinced about any overhead noticable associated wirh vector.
Besides, both versions could be provided.
Well, I think the critical version to provide would be the memory range version (which already exists). The other two versions could be provided, but the std::vector version, which would be implemented as a very simple wrapper around the memory range version, would only be slightly more convenient than using the memory range version directly, and the static array version would probably not be used much at all, because it is often useful to read into only a portion of an array, rather than always reading into the entire array. As a side note, perhaps the names read and write should be used rather than send and receive/recv if the library will at some point support I/O on non-sockets, such as pipes and fifos. -- Jeremy Maitin-Shepard