4 ms·
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 ch
by 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 agoThere 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.