Scalaの演算子が「良い」のに、C ++の「悪い」のオーバーロードが発生するのはなぜですか。

C ++での演算子のオーバーロードは、多くの人にとってA Bad Thing（tm）であると考えられており、新しい言語ではミスを繰り返さないでください。確かに、これはJavaの設計時に特に削除された機能の1つでした。

Scalaについて読み始めたところ、演算子のオーバーロードに非常によく似ていることがわかりました（ただし、技術的には演算子がないため、関数だけなので、演算子のオーバーロードはありません）。ただし、C ++での演算子のオーバーロードとは質的に異なるようには思われません。C++では、演算子は特別な関数として定義されています。

それで私の質問は、Scalaで "+"を定義するアイデアがC ++でのアイデアよりも優れている理由は何ですか？

C ++はCからtrue blue演算子を継承します。つまり、6 + 4の「+」は非常に特殊です。たとえば、その+関数へのポインタを取得することはできません。

一方、Scalaにはそのような演算子はありません。メソッド名の定義に非常に柔軟性があるだけでなく、単語以外の記号の組み込み優先順位が少しあります。したがって、技術的にはScalaには演算子のオーバーロードはありません。

何を呼び出しても、C ++であっても、演算子のオーバーロードは本質的に悪いことではありません。問題は、悪いプログラマがそれを乱用するときです。しかし率直に言って、私は、プログラマーがオペレーターのオーバーロードを悪用する能力を取り除いても、プログラマーが悪用する可能性のあるすべてのものを修正するというバケツを落とすことはないと考えています。本当の答えはメンタリングです。 http://james-iry.blogspot.com/2009/03/operator-overloading-ad-absurdum.html

それにもかかわらず、C ++の演算子のオーバーロードとScalaの柔軟なメソッドの名前付けには違いがあります。これにより、ImhoはScalaの乱用を少なくし、乱用しやすくなります。

C ++では、インフィックス表記を取得する唯一の方法は、演算子を使用することです。それ以外の場合は、object.message（argument）またはpointer-> messsage（argument）またはfunction（argument1、argument2）を使用する必要があります。したがって、コードに特定のDSL風のスタイルが必要な場合は、演算子を使用する必要があります。

Scalaでは、任意のメッセージ送信でインフィックス表記を取得できます。「オブジェクトメッセージ引数」は完全に問題ありません。つまり、中置表記を取得するためだけに非単語記号を使用する必要はありません。

C ++演算子のオーバーロードは、基本的にC演算子に制限されています。「+」や「>>」などの比較的少数の記号に関連のない広範な概念をマッピングしようとするように人々に圧力をかける演算子のみを使用できるという制限と組み合わせる

Scalaでは、メソッド名として、単語以外の有効な記号を幅広く使用できます。たとえば、私はあなたが書くことができる組み込みPrologっぽいDSLを持っています

female('jane)!         // jane is female
parent('jane,'john)!   // jane is john's parent
parent('jane, 'wendy)! // jane is wendy's parent

mother('Mother, 'Child) :- parent('Mother, 'Child) & female('Mother) //'// a mother of a child is the child's parent and is female

mother('X, 'john)?  // find john's mother
mother('jane, 'X)?  // find's all of jane's children

：-、！、？、および＆記号は、通常のメソッドとして定義されています。C ++のみで＆は有効であるため、このDSLをC ++にマップするには、すでに非常に異なる概念を呼び起こすいくつかのシンボルが必要です。

もちろん、これはScalaを別の種類の虐待にさらします。Scalaでは、必要に応じてメソッドに$！＆^％という名前を付けることができます。

Scalaのように、非単語関数とメソッド名の使用に柔軟性がある他の言語については、Smalltalkを参照してください。Scalaのように、すべての「演算子」は単なる別のメソッドであり、プログラマーが柔軟な名前の優先順位と固定性を定義できるようにするHaskellです。関数。

C ++での演算子のオーバーロードは、多くの人が悪いことだと考えています（tm）

無知のみによって。これはC ++のような言語では絶対に必要であり、「純粋」な見方から始まった他の言語は、設計者がその必要性を理解すると、それを追加したことは注目に値します。

演算子のオーバーロードは、C ++では一般的に悪い考えであると決して考えられていませんでした。単に演算子のオーバーロードの悪用は悪い考えであると考えられていました。いずれにせよ、より詳細な関数呼び出しでシミュレートできるため、言語でのオペレーターのオーバーロードは実際には必要ありません。Javaでのオペレーターのオーバーロードを回避することで、Javaの実装と仕様が少し単純になり、プログラマーがオペレーターを乱用しないようになりました。演算子のオーバーロードの導入について、Javaコミュニティではいくつかの議論がありました。

Scalaでの演算子のオーバーロードの利点と欠点はC ++と同じです。演算子のオーバーロードを適切に使用すれば、より自然なコードを記述できます。使用しない場合は、より暗号化された難読化されたコードを記述できます。

参考：演算子はC ++では特別な関数として定義されていません。演算子は他の関数と同じように動作します。ただし、名前の検索、メンバー関数である必要があるかどうか、および2つの方法で呼び出すことができるという事実は異なります。1 ）演算子の構文、および2）operator-function-id構文。

この記事「C ++とJavaのポジティブレガシー」は、質問に直接答えます。

「C ++にはスタック割り当てとヒープ割り当ての両方があり、すべての状況を処理してメモリリークを引き起こさないように、オペレーターをオーバーロードする必要があります。確かに困難です。しかし、Javaには単一のストレージ割り当てメカニズムとガベージコレクターがあり、オペレーターのオーバーロードを簡単にします。」 ..

作者によると、JavaはC ++で複雑なため、誤って演算子のオーバーロードを省略しましたが、その理由を忘れていました（またはJavaに適用されないことを理解していませんでした）。

ありがたいことに、Scalaのような高水準言語は、同じJVMで実行しながら開発者に選択肢を提供します。

演算子のオーバーロードに問題はありません。実際、数値型の演算子のオーバーロードがないことには何か問題があります。（BigIntegerとBigDecimalを使用するJavaコードを見てください。）

ただし、C ++にはその機能を悪用する伝統があります。よく引用される例は、ビットシフト演算子がI / Oを実行するためにオーバーロードされていることです。

一般的にそれは悪いことではありません。
C＃などの新しい言語にも演算子のオーバーロードがあります。

悪いことは、オペレーターのオーバーロードの悪用です。

しかし、C ++で定義されている演算子のオーバーロードにも問題があります。オーバーロードされた演算子はメソッド呼び出しの単なる構文上の糖なので、メソッドと同じように動作します。一方、通常の組み込み演算子はメソッドのように動作しません。これらの不整合は問題を引き起こす可能性があります。

頭の上のオペレーター||と&&。
これらの組み込みバージョンはショートカット演算子です。これはオーバーロードされたバージョンには当てはまらず、いくつかの問題を引き起こしています。

+-* /すべてが操作対象と同じタイプを返すという事実（オペレーターの昇格後）
オーバーロードされたバージョンは何でも返すことができます（これは、乱用が発生した場所であり、オペレーターがユーザーが予期していないアービトレータータイプを返し始めた場合物事は丘を下ります）。

演算子のオーバーロードは、あなたが本当に頻繁に「必要」とするものではありませんが、Javaを使用しているときに、本当に必要なところに到達した場合は、タイピングをやめる言い訳をするために、指の爪を引き離したくなるでしょう。 。

あなたが見つけたそのコードは長いオーバーフローですか？うん、BigIntegerで動作させるには、全体を再入力する必要があります。変数の型を変更するためだけにホイールを再発明しなければならないことほどイライラすることはありません。

ガイスティール氏は、オペレーターのオーバーロードもJavaで行うべきだと主張し、基調講演「Growing a language」でビデオとその書き起こしがあり、それは本当に素晴らしいスピーチです。彼が最初の数ページについて何を話しているのか不思議に思うかもしれませんが、読み続けると、そのポイントがわかり、悟りが開かれます。そして、彼がそのようなスピーチをまったく行うことができたという事実も驚くべきことです。

同時に、この講演は、おそらくScalaを含む多くの基礎研究に影響を与えました。これは、現場で働くために誰もが読むべき論文の1つです。

ちなみに、彼の例は主に数値クラス（BigIntegerなどの奇妙なもの）に関するものですが、それは必須ではありません。

ただし、演​​算子のオーバーロードの誤用はひどい結果を招く可能性があり、使用するライブラリを少しも検討せずにコードを読み込もうとすると、適切な使用法でも問題が複雑になる可能性があることは事実です。しかし、それは良い考えでしょうか？OTOH、そのようなライブラリーは、オペレーターのチートシートをオペレーターに含めようとすべきではありませんか？

私はすべての答えがこれを逃したと信じています。C ++では、演算子を必要なだけオーバーロードできますが、演算子を評価する優先順位を変更することはできません。IIRC、Scalaにはこの問題はありません。

優先順位の問題に加えて、それが悪い考えであることに関して、人々はオペレーターにとって本当に意味のない意味を思いつき、それが読みやすさを助けることはめったにありません。Scalaライブラリーは、特にこれを嫌いです。毎回覚えなければならない間抜けなシンボルであり、ライブラリーのメンテナーは「一度学ぶだけでよい」と言って砂に頭を抱えています。すばらしい、今私はいくつかの '賢い'作者の不可解な構文*使用したいライブラリの数を学ぶ必要があります。演算子の読み書き可能なバージョンを常に提供する規則が存在していたとしても、それほど悪くはありません。

オペレーターのオーバーロードはC ++の発明ではありませんでした-それはアルゴールIIRCから来たものであり、ゴスリングでさえそれが一般的に悪い考えであると主張していません。

C ++で間違っていることがわかっている唯一のことは、個別の演算子として[] =をオーバーロードする機能がないことです。これはおそらく明白な理由ではないが、それだけの価値があるため、C ++コンパイラに実装するのは難しいかもしれません。

他の答えが指摘したように; 演算子自体のオーバーロードは必ずしも悪いことではありません。結果のコードがわかりにくくなるような方法で使用すると何が悪いのでしょうか。一般的に、それらを使用するときは、最も驚くべきことを行わないようにする必要があります（operator + do除算を使用すると、有理クラスの使用で問題が発生します）、またはScott Meyersが言うように：

クライアントはintのような型がどのように動作するかをすでに知っているので、妥当な場合は常に同じように型が動作するように努力する必要があります... 疑わしい場合は、intと同じようにしてください。（Effective C ++ 3rd Edition item 18から）

現在、一部の人々は、boost :: spiritのようなものでオペレーターの過負荷を極端にしています。このレベルでは、それがどのように実装されるかはわかりませんが、やりたいことを実行するための興味深い構文になります。これが良いのか悪いのかわかりません。いい感じですが、使ったことはありません。

C ++の演算子のオーバーロードが悪いと主張する記事を見たことがありません。

ユーザー定義可能な演算子を使用すると、言語のユーザーがより高いレベルの表現力と使いやすさを実現できます。

ただし、C ++での演算子のオーバーロードとは質的に異なるようには思われません。C++では、演算子は特別な関数として定義されています。

AFAIK、「通常の」メンバー関数と比較して、演算子関数には特別なものはありません。もちろん、オーバーロードできる特定の演算子のセットしかありませんが、それはそれらを特別なものにするわけではありません。