Since we don't know what's stored in the memory buffer (image/audio data, chars from an input stream, serialized structs, etc.), it would be useful to be able to parameterize the iterators to the increment size. And to be able to get multiple input iterators of different size on the same buffer. For example, I might want to read in a couple structures describing the audio format of a WAV file, then use that data to determine the number of bytes in each sample, get that size iterator from the end of the header data, and read in the samples. This could be enormously helpful, as right now I'm using a union hack that allows me to access various pointer sizes on the same data. This would be cleaner.
We'd have to work out failure methods for lack of space if the user supplies memory, as we can't grow it. Users are not necessarily prepared for push_back to fail with an out_of_memory exception that's not a bad_alloc. It's just documentation, but it breaks the transparency of the interface and substitutability of the container. I'm almost ready to say that it shouldn't use user memory and insist on holding its own, but I'd have to think about it more. For example, the interface is fundamentally different if reserve() performs a nop or an actual reserve depending on which constructor was called. On the other hand, with sockets and other input methods reading into a char*, an extra data copy is often unacceptable in performance-critical applications such as network servers.
Perhaps use of a publicly-inherited policy could accommodate the discrepancy by providing reserve() and other methods where they make sense and withholding them when they don't. We'll have to look into what limits these changes could impose when using the buffer in generic algorithms.
-- Brian
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
