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

From: Kevin Atkinson (kevin_at_[hidden])
Date: 2003-03-04 14:13:34

Attached is my implementation.  It is not very well tested yet so be 
careful.

On Tue, 4 Mar 2003, Brian Gray wrote:

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

Well I have a special method which allows reinterpreting the memory into an 
arbitrary pointer.  Which provided some of what you are looking for.  
Suggestions for how to do better welcome.

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

That is true.  However if a user passes in a memory buffer it is expected 
that there is enough room to hold the data.  If an arbitrary amount of space 
is needed than the memory should not be user defined.  Currently my Buffer
aborts if an operations exceeds the available memory.  Maybe an exception 
is better but I prefer aborts when a precondition or the like is violated.

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

That may work if it can be determined at compile time when a fixed amount 
of memory is acceptable.  Sometimes this can not be determined at compile 
time however.

Generic algorithms will work just fine as look as the available memory
isn't being exceeded.  When it doesn't, my Buffer as is, will abort.

--- 
http://kevin.atkinson.dhs.org