Overloading

Posted Apr 29, 2014 11:51 UTC (Tue) by simlo (guest, #10866)
In reply to: Overloading by HelloWorld
Parent article: Porting the Go compiler to Go

The problem with overloading is when people use it for something completely different than their basic meaning. It is fine to define an + operator for complex, vector, matrix etc. But it is not ok to define operator+=() instead of a method addListener().

I actually find STL's string + operator a bad extension of +: It works as a concatenation rather than an addition. Usually an + operation is commutable, concatenation isn't. In math * is not always commutable so it is ok to use it for matrix multiplication for instance.

In short: The operator should express only what the reader of the code expects for that symbol. The usual rules of calculus should be respected. And except for the assignment and call operators, there shall be no side effects.

Overloading

Posted Apr 29, 2014 17:08 UTC (Tue) by HelloWorld (guest, #56129) [Link] (11 responses)

> The problem with overloading is when people use it for something completely different than their basic meaning.
This has nothing to do with operator overloading but with poor naming of functions, and that can be done no matter what restrictions you impose.

Overloading

Posted Apr 30, 2014 6:00 UTC (Wed) by bronson (subscriber, #4806) [Link] (10 responses)

But C++ encourages it. It even canonicalized it with << and >>.

If one person gets it wrong then, sure, it's a user problem. But look at how many C++ coders have screwed it up. No, you can't blame this one on a just a few poor programmers.

Overloading

Posted Apr 30, 2014 9:55 UTC (Wed) by HelloWorld (guest, #56129) [Link] (7 responses)

> If one person gets it wrong then, sure, it's a user problem. But look at how many C++ coders have screwed it up.
I have no idea how many screwed this up, but I have no reason to believe it's a significant problem. And besides, I have yet to see any true problem caused by the use of << for iostreams.

Overloading

Posted Apr 30, 2014 13:37 UTC (Wed) by etienne (guest, #25256) [Link] (6 responses)

> true problem caused by the use of << for iostreams

People around me say that if you use << to put objects in an iostream, it is logical to use >> to get from an iostream. And why limit that to iostream, why not streams, queues, vectors, bags, dictionaries?
The operator priority of "<<" is not the right one if you want to use it to put to an iostream.

Overloading

Posted Apr 30, 2014 16:41 UTC (Wed) by cry_regarder (subscriber, #50545) [Link] (4 responses)

Parenthesis? What's the issue?

Overloading

Posted May 1, 2014 13:18 UTC (Thu) by Funcan (guest, #44209) [Link] (3 responses)

The issue is that it is none-intuitive and easy to get wrong.

Much like PHP - it is so internally inconsistent and unintuitive that actually writing correct code in it requires you to keep a heroic number of things in your mind at the same time.

Overloading

Posted May 1, 2014 15:45 UTC (Thu) by jwakely (subscriber, #60262) [Link] (2 responses)

> The issue is that it is none-intuitive and easy to get wrong.

(We're still talking about the operator precedence of << as it relates to ostreams, right?)

Do you have an example of getting it wrong? Easily?

More importantly, do you have an example of getting it wrong that isn't caught immediately by the compiler? i.e. actually compiles, runs, but does the wrong thing.

I'll admit these days I don't have much idea of how beginners approach C++, but I seriously can't understand how someone could find writing to ostreams takes heroic effort.

Overloading

Posted May 1, 2014 23:14 UTC (Thu) by dtlin (subscriber, #36537) [Link] (1 responses)

I don't usually complain about iostreams, but this one's easy.

cout << flags & 0xff;  // (cout << flags) & 0xff
cout << b ? yes : no;  // (cout << b) ? yes : no

Overloading

Posted May 2, 2014 9:57 UTC (Fri) by jwakely (subscriber, #60262) [Link]

The first one obviously doesn't compile. The second one gets a warning from a half decent compiler, and why is it inherently worse than similar expressions not involving operator<< or iostreams?

int j = i * b ? 10 : 100;

Does this mean operator* is "non-intuitive and easy to get wrong" for multiplication of integers, and "so internally inconsistent and unintuitive that actually writing correct code in it requires you to keep a heroic number of things in your mind at the same time"?

Or does it just mean you should probably use parentheses for expressions that use more than just the familiar mathematical operators we learnt at school?

Overloading

Posted May 1, 2014 16:20 UTC (Thu) by HelloWorld (guest, #56129) [Link]

> People around me say that if you use << to put objects in an iostream, it is logical to use >> to get from an iostream. And why limit that to iostream, why not streams, queues, vectors, bags, dictionaries?
Because inserting something into a collection is something *entirely different* from doing I/O. And besides, non-symbolic names like push_back are used in the STL.

Overloading

Posted Apr 30, 2014 16:40 UTC (Wed) by cry_regarder (subscriber, #50545) [Link] (1 responses)

How many? I've never heard of anyone screwing it up and I've been teaching C++ can CS for 9 years now. You look at it and say "oh, that's cute. Got it." and then carry-on. Straw man.

The chaos that is java auto boxing and un-boxing just to get around the issues with not having operator overloads is ridiculous.

Overloading

Posted Apr 30, 2014 20:27 UTC (Wed) by mathstuf (subscriber, #69389) [Link]

> I've never heard of anyone screwing it up

I think bronson is referring to operator overloading in general, not the stream overload of the bitshift operators in particular.

Overloading

Posted Apr 29, 2014 20:53 UTC (Tue) by mathstuf (subscriber, #69389) [Link] (3 responses)

When is multiplication noncommutative? If you mean quaternions, octanions also are non-associative, so the (a * b * c) must be done left-to-right (which I think may be optimized either way by the standard).

Overloading

Posted Apr 29, 2014 21:18 UTC (Tue) by khim (subscriber, #9252) [Link] (2 responses)

Matrix multiplication is most definitely not commutation. Vector multiplication can be commutative or anticommutative (and these are two different operations which immediately put C++ in the more-or-less the same bucket as Go because you can not create new operators there).

The whole story looks like such a tempest in a teapot to me that it's not even funny. What's the #1 general purpose language used by mathematicians and scientists? Right: Fortran. Does it support operator overloading? Yup. So what are we discussing here? IMNSHO it's pointless to discuss taste of oysters with the ones who are regularly consuming them.

Overloading

Posted Apr 29, 2014 22:18 UTC (Tue) by mathstuf (subscriber, #69389) [Link]

They mentioned matrix multiplication and the sentence seemed to indicate that there was some other instance HelloWorld was referring to.

> What's the #1 general purpose language used by mathematicians and scientists? Right: Fortran. Does it support operator overloading? Yup. So what are we discussing here? IMNSHO it's pointless to discuss taste of oysters with the ones who are regularly consuming them.

And they're the only group that cares about matrix multiplication? See game developers, visualization and rendering programmers, etc.. Anyways, I think operator overloading is working from flawed principles (that operators work on concrete types rather than type classes), but since Go lacks generics, that's not even a remote possibility[1].

[1]There's interface{}, but that's only slightly better than C's void* in that you can still type match on it safely.

Overloading

Posted Apr 30, 2014 6:15 UTC (Wed) by torquay (guest, #92428) [Link]

What's the #1 general purpose language used by mathematicians and scientists? Right: Fortran.

Not these days. It used to be in 1970s and 80s. In the 1990s its popularity among scientists and engineers dropped quite considerably, ceding ground to Matlab, C and C++. These days Fortran is largely considered as a "legacy language", akin to Cobol. Yes, the often used LAPACK and BLAS are still written in Fortran, but that's simply due to momentum. Matlab is in effect a user-friendly wrapper for LAPACK. Similarly, C++ has many good libraries providing wrappers for LAPACK.

The grounds are shifting yet again, with many scientists, quants, etc moving to the R language and Python (using numpy etc). The point is that due to Go's inherent limitations (lack of operator overloading being one of them), it will never be seriously considered as a suitable language by mathematicians, engineers and scientists. While Go was designed by a bunch of well intentioned people, in the end they have proven to be myopic and only concerned with specific use cases.