Boost logo

Boost :

From: Brian Gray (briangray_at_[hidden])
Date: 2003-03-04 13:11:54

A raw memory buffer is a good idea. I've rolled my own on a couple of
occasions, but never tried to mimic the style of the STL. That
approach opens up a couple issues:

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

  -- Brian

Boost list run by bdawes at, gregod at, cpdaniel at, john at