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

From: Phil Nash (phil.nash.lists_at_[hidden])
Date: 2003-03-05 09:43:07

[Brian Gray]
> 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.

The concept of parameterised iterators interests me. I am working on a
problem that seems to only be neatly solved with such a concept. However I
have not been able to find any other mention of such things so it makes me
doubt wether they are such a good idea (obvious problems would be when used
with algorithms, but then parameterised iterators may open up some iterable
entities to the iterator concept that wouldn't have been otherwise).
Is there an established concept or an established reason why they are not
recommended, etc?
I can design around my particular problem by using a non iterator approach
but, like Brian's example, I would seem to be losing out on some extra
structure and elegance to the design.

Regards,

[)o
IhIL..