7 ms·
While in most of my code, I don't really care about operator overloading (ie not having it would not make my life any worse), but when I write shader code (or a
by dkersten 6y ago
While in most of my code, I don't really care about operator overloading (ie not having it would not make my life any worse), but when I write shader code (or a C++ library like GLM) to do mathy stuff, but including vectors and matrices, I am very glad to have overloaded operators and dread the idea of having to work around the language to express what I want. I'm not thrilled about having to duplicate the code (once using X.add(Y) and a comment to show a clearer version) here, but its better than nothing.
Of course, if we just use s-expressions, then there's no difference between operators and functions and this whole thing becomes moot. Although, with the caveat that your nice infix math expressions are still not nice infix math expressions. Then again, if we are using sexps, then we're likely using a language with macros and writing an infix macro for those mathy parts wouldn't be such a bad idea... ;-)
- tsimionescu 6y agoIsn't operator overloading usually a bad idea for high-performance maths? It limits you to binary operations (unless you go down an even deeper rabbit hole of template meta-programming), when many oprimized algorithms are ternary or even higher arity (e.g. optimized matrix multiply-and-add).
- dkersten 6y agoI mean, I haven't had to write one myself, but as a user of GLM, I've been very happy and personally couldn't care less if they're template meta-programming heavy to achieve it. As a user of the library, it doesn't bother me. I use plenty of template-heavy libraries anyway. Maybe its hard to achieve absolute best performance, but I'm not arguing for that, I'm only arguing that operator overloading leads to better programmer ergonomics. I can benchmark and convert to optimised functions after I have it working nicely. Ergonomics first, optimisations after.
- tsimionescu 6y agoI'm not familiar with GLM, but it seems to be the perfet sweetspot for operator overloading - it works with fixed size, small matrices (up to 3x3), which probably don't require and may not even benefit from more advanced algorithms. The problems I had read about applied to operations on larger matrices, where the difference between n^3 and n^2.5 or whatever becomes extremely noticeable, and makes it worth to write mulAndAdd(a, b, c) rather than a*b+c.