>>
>> AFAIK it was first proposed in the C++ committee who rejected it.
Todd> Yes, this was a shame. Nathan Myers suggested it will "almost
Todd> certainly" be adopted into C++ now that C9x has adopted it.
Todd> C9x also has "complex" as an intrinsic type... but only after
Todd> you include <complex.h>. Hopefully the C++ committee will
Todd> steer clear of that one.
There are many places were C9x chooses to diverge from C++.
BTW complex<>, valarray<> and several numerical algorithms
(e.g. inner_product<>) also have to be improved/corrected. The
standard only defines complex in catersian cordinates. Polar
representations are equally useful. I suspect one will need a
namespace std::math in which to put something like:
template<typename T> class polar { ... };
template<typename T> class cartesian { ... };
template<typename T, template<class> class R=cartesian>
class complex { ... }
making it possible both forms.
#include <map>
int main()
{
map<double, complex<double> > f;
map<double, complex<double, polar> > polar_curve;
//...
complex<double> z = integrate(f.begin(), f.end());
plot(curve);
}
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.
Todd> Apologies, Gaby. I got caught by the lack of a plural "you" in
I wish I read you post more carefully :-(
Todd> english. I meant, "If you [gentle list-readers] are interested..."
Todd> I didn't mean to imply you didn't know about aliasing.
Todd> Quick summary of the restrict vs. valarray<> argument:
Todd> The "restrict" keyword allows you to tell the compiler that there
Todd> are no other pointers which refer to the same data. For example:
Todd> double* restrict a;
Todd> double* restrict b;
Todd> Here, the compiler can assume that the a and b arrays don't
Todd> overlap.
Todd> The C++ standard contains this note about valarray<>:
Todd> The valarray array classes are defined to be free of
Todd> certain forms of aliasing, thus allowing operations
Todd> on these classes to be optimized.
Todd> Some people have suggested that valarray<> can serve as a building
Todd> block for larger, more complete libraries. Chances are good that
Todd> very few compilers will actually implement this optimization
Todd> for valarray<>. But assuming they do, if library designers
Todd> wanted to take advantage of valarray's aliasing restrictions,
Todd> they would have to express everything in terms of valarray
Todd> operations. But valarray uses pairwise evaluation and
Todd> temporaries. (There are some clauses which hint that
Todd> an expression templates implementation is acceptable, but
Todd> David Vandevoorde says they aren't sufficient). So
ternary-operator are possible (expression templates). I'll like to see
cases were expression templates aren't sufficient.
Todd> this route would result in very poor performance.
I don't think so. If valarray<> is implemented _and_ *optimized* then
I can't think of an algorithm you can write (by iterating over
restricted memory) which would lead to performance loss by iterating
over a valarray<>.
Todd> The alternative is to use valarray as a glorified pointer
Todd> object, and turn it into a real pointer just before you do an
Todd> operation. This requires the compiler to see that
Todd> you've retrieved the pointer from a valarray, realize
Todd> that it is alias-free, and then propagate that knowledge
Todd> through any copies of the pointer you make. Again, it's
Todd> unlikely that any compilers will implement this optimization.
Todd> With the restrict keyword, it's very simple to indicate
Todd> that array data is alias-free: one just writes
Todd> class Array {
Todd> ...
Todd> double* restrict data;
Todd> };
But if a C++ compiler writer don't care to optimize a valarray<> why
should (s)he care to honor restrict ?
Having a builtin alias-free array can benefit from the compiler
knowledge of the computer's memory-hierarchy management.
-- Gaby
"One reason that life is complex is that it has a
real part and imaginary part." -- Andrew Koenig