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:Could this also be used to make vector<Derived> implicitly convertible to
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.
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
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
