Re: [boost] Any Interest In a Raw Memory Buffer

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 
algorithms.

  -- Brian