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

From: Brian Gray (briangray_at_[hidden])
Date: 2003-03-04 16:12:58

On Tuesday, March 4, 2003, at 12:24 PM, Larry Evans wrote:
> Brian Gray wrote:
>> 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.
> Could this also be used to make vector<Derived> implicitly convertible 
> to
> vector<Base>?  It seems so if everything is implemented in terms of 
> char* and
> the only difference is the increment (of char) to move from one 
> element to the
> next.  Of course I guess this would mean the increment op would have 
> to be virtual,
> but maybe not.  If the iterator, as suggested above, the increment 
> size was parameterized,
> this would eliminate the need for virtual increment.

I can see how vector<Derived*> might benefit from conversion to 
vector<Base*>, but we're talking about contiguous memory here.  Very 
subject to raw object size, so there's no way to cast between the two 
and preserve object hierarchies if they're not pointers.

Yes, I was suggesting parameterized iterators, but that would be 
useful, for example, to have a single contiguous memory section that 
contains varied data types -- like a network header.  So iterator<obj1> 
being copyable to an iterator<obj2> should be legal, to switch types on 
the fly, preserving the data offset.  But phrasing it as 
iterator<Derived> and iterator<Base> implies something that isn't 
happening.  It would be for a section that had some instances of 
Derived followed by some instances of Base.  And so the conversion 
would just be because they are different, without respect to their 
lineage.

  -- Brian