Operator overloading or alternatives to expression templates
Martin Nowak via Digitalmars-d
digitalmars-d at puremagic.com
Sun Sep 13 07:06:03 PDT 2015
On 09/13/2015 05:03 AM, Andrei Alexandrescu wrote:
> Yah, understood. Problem here is the approach is bound to run into walls
> at every few steps. Say you fix the comparisons to work. Then you have
> operators such as LIKE that are necessary yet not representable in D. So
> more tricks are in order. This is what I've seen with ET in C++ - an
> endless collection of tricks to achieve modest outcomes at enormous costs.
But this is not an argument to rule out `opBinary!"<"`.
To summarize the arguments.
- logical indexing x[x < 20]
e.g. opBinary!"<" returns a bit mask to select entries of a large vector
- faster comparison
struct Foo
{
size_t id;
int opCmp(Foo rhs)
{
if (id < rhs.id) return -1;
if (id == rhs.id) return 0;
else return 1;
}
bool opBinary(string s:"<")(Foo rhs)
{
return id < rhs.id;
}
}
Sorting a million Foos w/ random ids is 37.5% slower with opCmp.
foos.sort!((a, b) => a.opBinary!"<"(b))(); // 104ms
foos.sort!((a, b) => a < b)(); // 143ms
- expression templates
I'm well aware of the limitations, but still think it will work out
nicely for an ORM b/c there is precedence in other language, e.g. Rails'
(ActiveRecord) query syntax.
- language regularization
It's surprising to find these "arbitrary" language limitations.
The non-predictability of what's possible has always been a huge issue
for me with C++, i.e. you come up with an idea, spend 4 hours
implementing it only to find out that the small detail x isn't feasible.
More information about the Digitalmars-d
mailing list