3 ms·

No, I'd say that operators will always result in a primitive operation is actually a feature - everything more complex warrants a proper function.

HexDecOctBin 6y ago
I'd say they should probably go the other way, defining even built-in operators like: operator+(int a, int b) __gcc_internal_int_sum(a, b) This way, we can change (through overriding) the way these operations work (rounding, overflow, coercing, etc.), without having to define non-idiomatic functions to do so. A lot of undefined behavior can be made user-defined this way.
- gmueckl 6y ago
  There should be a middle ground. The main issue with operator overloading is that every overload exists in the global scope. Thus, you get issues and surprises with unknown or competing overloads. Sometimes, a workable solution would be to have overloads restricted to a kind of named scope that the calling code can enter explicitly. Maybe something like operator_context(mz_vector_ops) { ... } which makes all operators defined in the context of my_vector_ops apply to expressions within the block, but nowhere else.
FrozenVoid 6y ago
Consider arbitrary precision, rationals, interval arithmethic, countless algebraic types, matrices, vectors with all of them requiring typing and composing long functions versus intuitive formula: mpz_mul(res,x,y); mpz_mul(res,res,z); vs x*y*z; ```
- jstimpfle 6y ago
  The following style is much better: v3 r = Add_v3(v, w); v4 w = Scale_v3(r, 1.0); You can definitely write a little 3D graphics backend this way. C's lack of operator overloading can be annoying for some tasks, however I still like to use C for almost everything to this day, because of the lightness of going through old code and seeing instantly what happens - never have to run any type resolution in my head. And importantly, _knowing_ that I don't have to do this. Because I might almost never have to do this in cleanly written C++ code, but how do I know?
jjoonathan 6y ago
Math libraries are an exception. You want this: d + A*B*(c*(a*b)) Not this: vector_add(mv_multiply(matrix_multiply(A,B),vector_dot(a,b)*c),d)
- jcelerier 6y ago
  so are expression grammar libraries, etc
- wtetzner 6y ago
  It'd be cool to have the Haskell feature of putting backticks around a binary function so you can use it infix, e.g.: ((A `mmul` B) `mvmul` (a `vdot` b) * c) `vadd` d Still not as nice as operators, but not terrible either.
- flohofwoe 6y ago
  You can get this with clang's vector extension (https://clang.llvm.org/docs/LanguageExtensions.html#vectors-and-extended-vectors https://clang.llvm.org/docs/LanguageExtensions.html#vectors-...), and this would make a lot of sense to add to the C standard. IMHO vector math is about the only place where operator overloading is acceptable in C++.

HexDecOctBin 6y ago

I'd say they should probably go the other way, defining even built-in operators like: operator+(int a, int b) __gcc_internal_int_sum(a, b) This way, we can change (through overriding) the way these operations work (rounding, overflow, coercing, etc.), without having to define non-idiomatic functions to do so. A lot of undefined behavior can be made user-defined this way.

gmueckl 6y ago
There should be a middle ground. The main issue with operator overloading is that every overload exists in the global scope. Thus, you get issues and surprises with unknown or competing overloads. Sometimes, a workable solution would be to have overloads restricted to a kind of named scope that the calling code can enter explicitly. Maybe something like operator_context(mz_vector_ops) { ... } which makes all operators defined in the context of my_vector_ops apply to expressions within the block, but nowhere else.

FrozenVoid 6y ago

Consider arbitrary precision, rationals, interval arithmethic, countless algebraic types, matrices, vectors with all of them requiring typing and composing long functions versus intuitive formula: mpz_mul(res,x,y); mpz_mul(res,res,z); vs x*y*z; ```

jstimpfle 6y ago
The following style is much better: v3 r = Add_v3(v, w); v4 w = Scale_v3(r, 1.0); You can definitely write a little 3D graphics backend this way. C's lack of operator overloading can be annoying for some tasks, however I still like to use C for almost everything to this day, because of the lightness of going through old code and seeing instantly what happens - never have to run any type resolution in my head. And importantly, _knowing_ that I don't have to do this. Because I might almost never have to do this in cleanly written C++ code, but how do I know?

jjoonathan 6y ago

Math libraries are an exception. You want this: d + A*B*(c*(a*b)) Not this: vector_add(mv_multiply(matrix_multiply(A,B),vector_dot(a,b)*c),d)

jcelerier 6y ago
so are expression grammar libraries, etc
wtetzner 6y ago
It'd be cool to have the Haskell feature of putting backticks around a binary function so you can use it infix, e.g.: ((A `mmul` B) `mvmul` (a `vdot` b) * c) `vadd` d Still not as nice as operators, but not terrible either.
flohofwoe 6y ago
You can get this with clang's vector extension (https://clang.llvm.org/docs/LanguageExtensions.html#vectors-and-extended-vectors https://clang.llvm.org/docs/LanguageExtensions.html#vectors-...), and this would make a lot of sense to add to the C standard. IMHO vector math is about the only place where operator overloading is acceptable in C++.