> Todd> The restrict keyword has apparently been adopted into the C9x
> Todd> standard, so hopefully it will become part of C++ in the future.
>
> AFAIK it was first proposed in the C++ committee who rejected it.
Yes, this was a shame. Nathan Myers suggested it will "almost
certainly" be adopted into C++ now that C9x has adopted it.
C9x also has "complex" as an intrinsic type... but only after
you include <complex.h>. Hopefully the C++ committee will
steer clear of that one.
> Todd> Btw, if you're interested in what the fuss is over aliasing
> Todd> and restrict, there is some material which explains why aliasing
> Todd> can cause poor performance: see pp. 53--56 of the "Techniques
> Todd> for Scientific C++" slides available from
> Todd> http://seurat.uwaterloo.ca/blitz/papers/
> The problem isn't that I don't know aliasing side-effects on code
> performance. I *am* aware of the problem.
Apologies, Gaby. I got caught by the lack of a plural "you" in
english. I meant, "If you [gentle list-readers] are interested..."
I didn't mean to imply you didn't know about aliasing.
Quick summary of the restrict vs. valarray<> argument:
The "restrict" keyword allows you to tell the compiler that there
are no other pointers which refer to the same data. For example:
double* restrict a;
double* restrict b;
Here, the compiler can assume that the a and b arrays don't
overlap.
The C++ standard contains this note about valarray<>:
The valarray array classes are defined to be free of
certain forms of aliasing, thus allowing operations
on these classes to be optimized.
Some people have suggested that valarray<> can serve as a building
block for larger, more complete libraries. Chances are good that
very few compilers will actually implement this optimization
for valarray<>. But assuming they do, if library designers
wanted to take advantage of valarray's aliasing restrictions,
they would have to express everything in terms of valarray
operations. But valarray uses pairwise evaluation and
temporaries. (There are some clauses which hint that
an expression templates implementation is acceptable, but
David Vandevoorde says they aren't sufficient). So
this route would result in very poor performance.
The alternative is to use valarray as a glorified pointer
object, and turn it into a real pointer just before you do an
operation. This requires the compiler to see that
you've retrieved the pointer from a valarray, realize
that it is alias-free, and then propagate that knowledge
through any copies of the pointer you make. Again, it's
unlikely that any compilers will implement this optimization.
With the restrict keyword, it's very simple to indicate
that array data is alias-free: one just writes
class Array {
...
double* restrict data;
};