4 ms·

Both C and C++ can represent matrices and vectors as types with related operations. In my view, the key difference between these two languages is RAII.

jcelerier 8y ago
but only C++ allows you to write `c = a * x + b` instead of mat a, b, x, tmp, c; // ... mat_mul(&tmp, &a, &x); mat_sum(&c, &tmp, &b); which is what OP meant if I'm not mistaken.
- fauigerzigerk 8y ago
  True, operator overloading is definitely convenient for math.
  - Mister_Snuggles 8y ago
    As a real world (-ish) example, I wrote some Python code to do some effects on DMX lights. OpenLighting did all the talking to the lights, so the Python code was really just focused on constructing a list of numbers that would eventually find their way into OpenLighting and onto a DMX cable. Inside the Python code, each light has a Colour, and I built the Colour class with support for various math operators. Want to make a Colour that's half as bright as another? Colour = OtherColour * 0.5. Want to blend two Colours? BlendedColour = OneColour + AnotherColour. Doing this made all of the stuff that the code was doing incredibly obvious and straight forward. The alternative would have involved non-obvious helper functions and object methods or doing math directly on the rgb components encapsulated by each Colour object. This was, for me, somewhat of a "light bulb" moment for operator overloading.
    - maxxxxx 8y ago
      If it's done in good taste overloading is fine. But if abused it makes code totally unreadable and unmaintainable.
    - fauigerzigerk 8y ago
      Color me skeptical :) The reason why unnamed operators work so well for math code is that their meaning is already well established. OneColor + AnotherColor does not have any obvious meaning. If colors are RGBA vectors, it could be vector addition. But is that what your blend operation does? What's wrong with: BlendedColor = blend(OneColor, AnotherColor)
      - Mister_Snuggles 8y ago
        I agree, this is where you have to be careful. The meaning makes sense to me which, for a one developer codebase, is OK, but it's not something I'd want to do in a codebase supported by a larger team. I expect that in a more complete product that even the term "blend" would have multiple meanings.
  - maxxxxx 8y ago
    And it's also one of the easiest ways to write unmaintainable codes. I once inherited a code where the previous developer seemed to just have found out how cool operator overloading is. So there were a ton of overloads everywhere and you couldn't really tell what is just built-in operators and which is our own code. Total nightmare. After this I would be fine with operator overloading removed from languages. Nothing wrong with writing: Matrix_Multiply(m1,m2); vs. m1*m2 The first is not harder to read and not harder to write but I know exactly what's going on.
    - fauigerzigerk 8y ago
      So this code is from Go's big.Int documentation (slightly adapted): func main() { a := big.NewInt(0) b := big.NewInt(1) var limit big.Int limit.Exp(big.NewInt(10), big.NewInt(99), nil) for a.Cmp(&limit) < 0 { a.Add(a, b) a, b = b, a } fmt.Println(a) } I can't say I'm particularly keen on having to read a.Cmp(&limit) < 0 instead of a < limit The question is whether it's worth it to write code like this in order to prevent others from misusing operator overloading. I guess it may depend on how much math code you write and how disciplined your coworkers are.
    - AnimalMuppet 8y ago
      > The first is not harder to read and not harder to write but I know exactly what's going on. For your example, maybe so. But: m = a * b * c + d * e + f will be clearer than three Matrix_Multiply and two Matrix_Add calls. And one screen full of lines like mine will be far clearer than five screens full of Matrix_Add and Matrix_Multiply calls.
      - maxxxxx 8y ago
        I agree if it’s very mathy but I have seen operator overloading for things like invoices and orders. That’s just horrible.
        AnimalMuppet 8y ago
- Crinus 8y ago
  FWIW i prefer mul_x, even in languages such as C++ where operator overloading is available i put methods with names like mul, div, etc instead of operators as i am not fan of infix function calls. Also specifically for vectors and matrices for 3D graphics, i prefer to use float mtx[16], vec[3], etc instead of specifying custom types (then i can use the vec_foo calls with matrices with the proper offsets or the normal part of a float plane[4] which is encoded as normal+distance or use the vec_foo calls directly in a vertex buffer, etc).

jcelerier 8y ago

but only C++ allows you to write `c = a * x + b` instead of mat a, b, x, tmp, c; // ... mat_mul(&tmp, &a, &x); mat_sum(&c, &tmp, &b); which is what OP meant if I'm not mistaken.

fauigerzigerk 8y ago
True, operator overloading is definitely convenient for math.
- Mister_Snuggles 8y ago
  As a real world (-ish) example, I wrote some Python code to do some effects on DMX lights. OpenLighting did all the talking to the lights, so the Python code was really just focused on constructing a list of numbers that would eventually find their way into OpenLighting and onto a DMX cable. Inside the Python code, each light has a Colour, and I built the Colour class with support for various math operators. Want to make a Colour that's half as bright as another? Colour = OtherColour * 0.5. Want to blend two Colours? BlendedColour = OneColour + AnotherColour. Doing this made all of the stuff that the code was doing incredibly obvious and straight forward. The alternative would have involved non-obvious helper functions and object methods or doing math directly on the rgb components encapsulated by each Colour object. This was, for me, somewhat of a "light bulb" moment for operator overloading.
  - maxxxxx 8y ago
    If it's done in good taste overloading is fine. But if abused it makes code totally unreadable and unmaintainable.
  - fauigerzigerk 8y ago
    Color me skeptical :) The reason why unnamed operators work so well for math code is that their meaning is already well established. OneColor + AnotherColor does not have any obvious meaning. If colors are RGBA vectors, it could be vector addition. But is that what your blend operation does? What's wrong with: BlendedColor = blend(OneColor, AnotherColor)
    - Mister_Snuggles 8y ago
      I agree, this is where you have to be careful. The meaning makes sense to me which, for a one developer codebase, is OK, but it's not something I'd want to do in a codebase supported by a larger team. I expect that in a more complete product that even the term "blend" would have multiple meanings.
- maxxxxx 8y ago
  And it's also one of the easiest ways to write unmaintainable codes. I once inherited a code where the previous developer seemed to just have found out how cool operator overloading is. So there were a ton of overloads everywhere and you couldn't really tell what is just built-in operators and which is our own code. Total nightmare. After this I would be fine with operator overloading removed from languages. Nothing wrong with writing: Matrix_Multiply(m1,m2); vs. m1*m2 The first is not harder to read and not harder to write but I know exactly what's going on.
  - fauigerzigerk 8y ago
    So this code is from Go's big.Int documentation (slightly adapted): func main() { a := big.NewInt(0) b := big.NewInt(1) var limit big.Int limit.Exp(big.NewInt(10), big.NewInt(99), nil) for a.Cmp(&limit) < 0 { a.Add(a, b) a, b = b, a } fmt.Println(a) } I can't say I'm particularly keen on having to read a.Cmp(&limit) < 0 instead of a < limit The question is whether it's worth it to write code like this in order to prevent others from misusing operator overloading. I guess it may depend on how much math code you write and how disciplined your coworkers are.
  - AnimalMuppet 8y ago
    > The first is not harder to read and not harder to write but I know exactly what's going on. For your example, maybe so. But: m = a * b * c + d * e + f will be clearer than three Matrix_Multiply and two Matrix_Add calls. And one screen full of lines like mine will be far clearer than five screens full of Matrix_Add and Matrix_Multiply calls.
    - maxxxxx 8y ago
      I agree if it’s very mathy but I have seen operator overloading for things like invoices and orders. That’s just horrible.
      - AnimalMuppet 8y ago
Crinus 8y ago
FWIW i prefer mul_x, even in languages such as C++ where operator overloading is available i put methods with names like mul, div, etc instead of operators as i am not fan of infix function calls. Also specifically for vectors and matrices for 3D graphics, i prefer to use float mtx[16], vec[3], etc instead of specifying custom types (then i can use the vec_foo calls with matrices with the proper offsets or the normal part of a float plane[4] which is encoded as normal+distance or use the vec_foo calls directly in a vertex buffer, etc).