[boost] Re: Raw Array Classes

From: Greg Colvin (gcolvin_at_[hidden])
Date: 1999-08-19 17:15:31

From: Reid Sweatman <reids_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Thursday, August 19, 1999 12:46 PM
Subject: [boost] Re: Raw Array Classes

> > For every vector implemetation I have seen vector<T>::iterator is the
> > moral equivalent of T*.  Or is that not what you meant?
> 
> Well, "moral equivalent" and the same thing aren't the same thing, so it's
> not what I meant <g>.  What I want is a second access method that is
> *exactly* like good old C pointers, and that I can do the standard array
> indexing tricks on to treat the data as multidimensional if I want, or hand
> the pointer off to an assembler routine and have no problems.
> 
> Frankly, I've never been totally clear on whether or not STL vectors are
> even required to maintain contiguous memory locations, let alone ones that
> have specified address alignments, which can be critical in CPU cache
> management.  Maybe I'm wrong, and there *is* a contiguity requirement, and
> maybe it would be enough to set the data packing *before* creating the
> vector.  But as for being able to pass an iterator off to an assembler
> routine as a pointer, I'm not so sure, especially if a resize occurs.  Most
> of my applications for such a thing would use pre-specified array sizes, but
> not always.
> 
> Comments?

My "moral equivalent" I meant that given a standard allocator if you follow
out through all the typedefs you will hit a T*, on which all the indexing
tricks will work.  The standard does not yet require that, but I believe we
are going to fix that.