At least they managed to kill `auto_ptr`.
Turns out, these two are equivalent in practice (but UB in the C++ standard):
double solve(double a, double b, double c, double d) {
return a + b + c + d;
}
double solve(double a ...) {
return a + 1[&a] + 2[&a] + 3[&a];
} double solve(double a[]) {
return 0[a] + 1[a] + 2[a] + 3[a];
}
solve((double[]){1, 2, 3, 4});
Not in the x86-64 SysV ABI they aren’t. The arguments will be passed in registers (yes, even the variadic ones), so how your compiler will interpret 1[&a] is anybody’s guess. (For me, x86_64-unknown-linux-gnu-g++ -O2 yields, essentially, return a+a+a+a; which is certainly an interpretation. I’m also getting strange results from i686-unknown-linux-gnu-g++ -O2, but my x87 assembly is rusty enough that I don’t really get what’s going on there.)
double solve(double a,double b,double c,double d){return a+b+c+d;}
double solve(double a...){return a+1[&a]+2[&a]+3[&a];}
double solve(a,b,c,d)double a,c,b,d;{return a+b+c+d;}I guess that's a preview how C++ require a lifelong commitment.
All languages have some spikier edges, there are no languages I know where I think "Well, even if we could start over I have no idea how to improve this". What's notable about C++ is just how rich that "could do better" seam is, so very many of their defaults are wrong, so many of their keywords are the wrong word, so many of their standard library features are allowed, sometimes even mandated to be crap.
I love C, but C++ has worthwhile advantages even if you heavily restrict which features you use.