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