Question

I’m wrapping up user space linux socket functionality in some C++ for an embedded system (yes, this is probably reinventing the wheel again).

I want to offer a read and write implementation using a vector.

Doing the write is pretty easy, I can just pass &myvec[0] and avoid unnecessary copying. I’d like to do the same and read directly into a vector, rather than reading into a char buffer then copying all that into a newly created vector.

Now, I know how much data I want to read, and I can allocate appropriately (vec.reserve()). I can also read into &myvec[0], though this is probably a VERY BAD IDEA. Obviously doing this doesn’t allow myvec.size to return anything sensible. Is there any way of doing this that:

1. Doesn’t completely feel yucky from a safety/C++ perspective
2. Doesn’t involve two copies of the data block – once from kernel to user space and once from a C char * style buffer into a C++ vector.

Answer 1

Use resize() instead of reserve(). This will set the vector’s size correctly — and after that, &myvec[0] is, as usual, guaranteed to point to a continguous block of memory.

Edit: Using &myvec[0] as a pointer to the underlying array for both reading and writing is safe and guaranteed to work by the C++ standard. Here’s what Herb Sutter has to say:

So why do people continually ask whether the elements of a std::vector (or std::array) are stored contiguously? The most likely reason is that they want to know if they can cough up pointers to the internals to share the data, either to read or to write, with other code that deals in C arrays. That’s a valid use, and one important enough to guarantee in the standard.