Boost logo

Boost :

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

  -- Brian

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