Hi Rob, --- Rob Stewart <stewart@sig.com> wrote:
From: Christopher Kohlhoff <chris@kohlhoff.com> Don't construct a vector of a given size or use resize(), then. Rely on reserve() instead.
It's my understanding that you cannot access the address &vec[N] (or &vec[0] + N) unless 0 <= N < size(), and reserve() doesn't change the size of the vector.
OTOH, using swap(), *if* a user used a vector<double> instead of the array you mention, then vector won't add overhead.
But Thorsten was proposing only the use of vector<char>, so you would still need to convert from vector<double> to vector<char>.
Instead, how about a std::vector-like class that takes a user-defined, fixed-size block of memory? Then, instead of using an allocator, it uses its own memory management class that doles out elements from the fixed, user-supplied memory. Such a class could even avoid the default construction worry altogether by eliminating resize() and making the constructor that takes a number simply reserve that much space. (Deviating that much from std::vector means you wouldn't want to make it too similar, or at least you'd want the name to be quite dissimilar.) Using a user-supplied block of memory means that the memory can come from a stack allocation, static memory, the free store, a memory mapped file, etc. That class cannot be copyable, but it could be movable and swappable.
I'd be happy to look at a proposed interface for it, if you'd like to sketch it out. However it would have to provide a straightforward way of sending an existing application data structure (and it may be hard to beat void* for that) that doesn't add time or space overhead in an optimised build. Basically I'm still of the opinion that the operations on the socket class should deal in void* to allow for users that need to be close to the metal. But since safe, efficient buffer management seems to be a common need/desire, perhaps there is a place for that in asio with a buffer class (or should it be a Buffer concept?) and non-member send/recv functions. Cheers, Chris