[boost] Re: Raw Array Classes

From: Reid Sweatman (reids_at_[hidden])
Date: 1999-08-20 16:47:44

> Note that, according to some semantics rules in ANSI/ISO C++, 
> you can do the
> following on any forward iterator:
> &(*i)
> which will result in a pointer to the underlying object.  

True, but the uses I put such a structure to require random access, so that
technique wouldn't be worth much.

> 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).

I didn't really think so, and that was one of the concerns that prompted me
to ask about array templates to begin with.

> 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
> pointer.

Except that I can't rely on being able to pass that interator to an
assembler routine, as you indicated in your previous paragraph.

> 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.

I'm aware of the class, not too familiar with it, but I think it would
suffer from the same problem with assemblers.  I know talking assembly here
is probably akin to mouthing the Algebenesian Heresy outside the Vatican,
but I'm one of those people who still believes that assembler has its place,
without being an assembler bigot.  It's the interface between the two
languages that's problematic when you're using templates.  For small stuff,
I use inline assembler, and for larger things, assembler functions with C
linkage.  But there are certainly times when you're in a tight, highly
repetitive loop where speed is critical, and you can't even afford the
overhead of a function call, let alone a stack frame.  In my code (bi- and
tri-cubic splines, Delaunay Triangulations, rasterizing, texture mapping,
neural networks, real-time procedural textures, and so on) this nearly
always involves large arrays of data that can be arranged for the fastest
possible access with minimal L1 cache thrashing, but only if the low-level
routines are in assembler.

For that kind of stuff, I'm not sure, but I think valarray still has the
same problem, but I'm certainly willing to be proven wrong on this one <g>.

> P.S. I use an "iter_to_ptr" template which translates forward 
> iterators to
> pointers when necessary - mainly for code clarification 
> ("&(*i)" is rather
> obscure):
> 
> 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; }

Nice little bit of code.  Don't mind if I do <g>.