Boost logo

Boost :

From: scleary_at_[hidden]
Date: 1999-08-20 07:39:17

Reid Sweatman wrote:
> That would be good. Wouldn't it be easier, though, for a
> special case like
> an array container (as opposed to a vector container) to just
> add a member
> function to the iterator that would return a raw pointer to
> the internal
> representation? For usage in C++ algorithms, you could
> certainly define
> interators to do random access as though the array were
> multidimensional,
> but you couldn't hand them over to an assembler routine.

Note that, according to some semantics rules in ANSI/ISO C++, you can do the
following on any forward iterator:
which will result in a pointer to the underlying object. However (and this
is where the tricky part comes in), you _cannot_ use that pointer _as_ an
iterator to the container, _unless_ the container holds its values in a
sequential, contiguous format (which there is no guarantee of in the
Standard, but every vector implementation I know of does).

Note: not all implementations of vector<T>::iterator are T*, even if the
allocator is the std-supplied allocator; code that depends on this property
is not conforming.

If you are just wanting to use vectors as arrays, I would assume that
vectors are contiguous and pass &(front()) to a function accepting a

If you are talking about serious calculations on multidimensional arrays, I
would highly recommend "valarray" instead of vector. "valarray" is a
little-known but very powerful part of the STL designed explicitly to handle
n-D numeric calculations.


P.S. I use an "iter_to_ptr" template which translates forward iterators to
pointers when necessary - mainly for code clarification ("&(*i)" is rather

template <typename ForwardIterator>
typename iterator_traits<ForwardIterator>::value_type
iter_to_ptr(ForwardIterator i)
{ return &(*i); }
template <>
T * iter_to_ptr(T * i)
{ return i; }

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