|
Boost : |
From: Nick Ambrose (nicka_at_[hidden])
Date: 1999-08-31 19:09:59
Reid Sweatman wrote:
> > 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>.
Have you looked at blitz++ library ? It uses no assembler, just templates etc. I'd be interested to see how it compared to raw assembler,
especially with a decent compiler.
Nick
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk