5 ms·

That't literally the only place where operator overloading makes any sense. In other places they monkey patch c++ defincies as a language. And they are confus

by fsloth 3y ago

That't literally the only place where operator overloading makes any sense. In other places they monkey patch c++ defincies as a language. And they are confusing and error prone. Nobody is pretending we will get rid of any c++ syntax ever. So the discussion is about a hypothetical language syntax that fits C++ slot. In that world C++ would have N x M matrices as native value types in the language (as fortran does) and those operators would be defined in the language spec for matrix types just as they are defined for standard number types at the moment. And it would not have any operator overloading.

crickey 3y ago
Making such assumptions about what is correct or proper use is why c++ is so successful, it doesnt make assumptions it leaves it up to the project / community using it. Go ahead make a language that dictates alot and makes srict assumptions it will be depricated or forced to open up before the end of the decade. Notr this is why i think python and lisp is so populare meta programing is very powerful and expressive.
- suby 3y ago
  That's a good observation about C++ not making assumptions, it strikes me as true. C++ apparently doesn't even make assumptions about what the C++ filename extension is. .h, .hh, .hpp, .hxx, .C, .cc, .cpp, .cxx, .ixx, cppm
- fsloth 3y ago
  The fact C++ has so many ways of defining things is not the reason it's so popular. The reason is the enormous industry investment on the language tooling and ecosystem. IMO the language itself is the worst part of the ecosystem, but the other parts create a totality that is the best development language ecosystem in industry for my niche (graphics and geometry) including libraries, copmpilers, debugger & profiling etc. Any language with the level of industrial support C++ has had would have grown to prominence. C++ came abut a judicious time in history when "object orientation" was becoming the latest buzzword. And now we have ended up with gazillions of lines of C++ code. It's a tragedy of our trade that two mongrels - C++ and Javascript - became to be among the most prominent in our trade.
  - crickey 3y ago
    But the reason C++ fits in so many industries from embedded system to high level gui libraries is its flexibility we see the end of OOP trend but C++ does bot lock its users into one paradigm or another so it will continue to be industry standard. Even if the industry is moving towards other paradigms of programing. Adding, javascript really inly has one industry its used in. Think it sais a bit about its versatility
deleted 3y ago
[deleted]
doodpants 3y ago
> That't literally the only place where operator overloading makes any sense. That may be true for C++ (I'll take your word for it), but not for all programming languages in general. For example, in C# it's fairly common to overload == and != to implement value equality for reference types (classes). Of course, you should really only do this for immutable classes that are mostly just records of plain old data. And C# 9 introduced record classes, which is a more convenient way of defining such classes. But record classes still overload these operators themselves, so you don't have to do it manually.
- throwaway894345 3y ago
  Honestly that sort of thing always confused me when I worked in Java, C#, etc. I could never tell at a glance whether the operator was doing an identity comparison or a value comparison, and I definitely contributed a few bugs from this misunderstanding. In Go which lacks operator overloading, we either `ptr1 == ptr2` or we do some `ptr1.Equals(ptr2)` for value comparisons and `ptr1 == ptr2` for pointer comparisons--in either case, there is no ambiguity and IME fewer bugs.
  - wizofaus 3y ago
    Java's the same regarding == and .equals( ) and when it's Java code written by devs who also work in other languages, it definitely still results in bugs, sometimes that go undiscovered for remarkably long times (particularly if == happens to return the right result in most cases). Meaning/needing to compare references for string (and similar) types is exceedingly uncommon, yet uses the more "natural" syntax for testing equality. FWIW I can't remember working with a codebase where unexpected behavior due to operator overloading was a serious problem.
  - gpderetta 3y ago
    That's more of a problem with languages that confuse value types and references.
noduerme 3y ago
What about the assignment operator?
eesmith 3y ago
> That't literally the only place where operator overloading makes any sense. So, no overloading for decimal types? Nor fraction types? I may be the oddball here, but I've used operator overloading on those types more than I have for vectors and arrays.
kazinator 3y ago
Fortran now has operator overloading, though.

by fsloth 3y ago

crickey 3y ago

Making such assumptions about what is correct or proper use is why c++ is so successful, it doesnt make assumptions it leaves it up to the project / community using it. Go ahead make a language that dictates alot and makes srict assumptions it will be depricated or forced to open up before the end of the decade. Notr this is why i think python and lisp is so populare meta programing is very powerful and expressive.

suby 3y ago
That's a good observation about C++ not making assumptions, it strikes me as true. C++ apparently doesn't even make assumptions about what the C++ filename extension is. .h, .hh, .hpp, .hxx, .C, .cc, .cpp, .cxx, .ixx, cppm
fsloth 3y ago
The fact C++ has so many ways of defining things is not the reason it's so popular. The reason is the enormous industry investment on the language tooling and ecosystem. IMO the language itself is the worst part of the ecosystem, but the other parts create a totality that is the best development language ecosystem in industry for my niche (graphics and geometry) including libraries, copmpilers, debugger & profiling etc. Any language with the level of industrial support C++ has had would have grown to prominence. C++ came abut a judicious time in history when "object orientation" was becoming the latest buzzword. And now we have ended up with gazillions of lines of C++ code. It's a tragedy of our trade that two mongrels - C++ and Javascript - became to be among the most prominent in our trade.
- crickey 3y ago
  But the reason C++ fits in so many industries from embedded system to high level gui libraries is its flexibility we see the end of OOP trend but C++ does bot lock its users into one paradigm or another so it will continue to be industry standard. Even if the industry is moving towards other paradigms of programing. Adding, javascript really inly has one industry its used in. Think it sais a bit about its versatility

deleted 3y ago

[deleted]

doodpants 3y ago

> That't literally the only place where operator overloading makes any sense. That may be true for C++ (I'll take your word for it), but not for all programming languages in general. For example, in C# it's fairly common to overload == and != to implement value equality for reference types (classes). Of course, you should really only do this for immutable classes that are mostly just records of plain old data. And C# 9 introduced record classes, which is a more convenient way of defining such classes. But record classes still overload these operators themselves, so you don't have to do it manually.

throwaway894345 3y ago
Honestly that sort of thing always confused me when I worked in Java, C#, etc. I could never tell at a glance whether the operator was doing an identity comparison or a value comparison, and I definitely contributed a few bugs from this misunderstanding. In Go which lacks operator overloading, we either `ptr1 == ptr2` or we do some `ptr1.Equals(ptr2)` for value comparisons and `ptr1 == ptr2` for pointer comparisons--in either case, there is no ambiguity and IME fewer bugs.
- wizofaus 3y ago
  Java's the same regarding == and .equals( ) and when it's Java code written by devs who also work in other languages, it definitely still results in bugs, sometimes that go undiscovered for remarkably long times (particularly if == happens to return the right result in most cases). Meaning/needing to compare references for string (and similar) types is exceedingly uncommon, yet uses the more "natural" syntax for testing equality. FWIW I can't remember working with a codebase where unexpected behavior due to operator overloading was a serious problem.
- gpderetta 3y ago
  That's more of a problem with languages that confuse value types and references.

noduerme 3y ago

What about the assignment operator?

eesmith 3y ago

> That't literally the only place where operator overloading makes any sense. So, no overloading for decimal types? Nor fraction types? I may be the oddball here, but I've used operator overloading on those types more than I have for vectors and arrays.

kazinator 3y ago

Fortran now has operator overloading, though.