C ++コンパイラがoperator ==とoperator！=を定義しないのはなぜですか？

私はコンパイラーにできる限り多くの仕事をさせてくれるという大ファンです。単純なクラスを作成する場合、コンパイラーは以下を「無料」で提供できます。

• デフォルトの（空の）コンストラクター
• コピーコンストラクタ
• デストラクタ
• 代入演算子（operator=）

しかし、operator==やなどの比較演算子を与えることはできませんoperator!=。例えば：

class foo
{
public:
    std::string str_;
    int n_;
};

foo f1;        // Works
foo f2(f1);    // Works
foo f3;
f3 = f2;       // Works

if (f3 == f2)  // Fails
{ }

if (f3 != f2)  // Fails
{ }

これには正当な理由がありますか？メンバーごとの比較の実行が問題になるのはなぜですか？もちろん、クラスがメモリを割り当てる場合は注意が必要ですが、単純なクラスの場合は、コンパイラがこれを実行できますか？

コンパイラーは、ポインター比較が必要か、深い（内部）比較が必要かを知りません。

実装せずにプログラマーが自分で実装する方が安全です。その後、彼らは好きなすべての仮定をすることができます。

コンパイラーがデフォルトのコピー・コンストラクターを提供できる場合、同様のデフォルトを提供できるはずであるという議論operator==()は、ある程度の意味があります。この演算子にコンパイラが生成したデフォルトを提供しないという決定の理由は、「C ++の設計と進化」（セクション11.4.1-コピーの制御）でStroustrupがデフォルトのコピーコンストラクターについて述べたことによって推測できると思います：

個人的には、コピー操作がデフォルトで定義されていることを残念に思い、多くのクラスのオブジェクトのコピーを禁止しています。ただし、C ++はデフォルトの割り当てとコピーコンストラクターをCから継承しており、頻繁に使用されます。

したがって、「C ++にデフォルトがないのはなぜoperator==()ですか」の代わりに、「C ++にデフォルトの割り当てとコピーコンストラクタがあるのはなぜですか？」という質問であるはずです。 （おそらくC ++のほとんどのいぼの原因ですが、おそらくC ++の人気の主な理由でもあります）。

私自身の目的のために、私のIDEでは、新しいクラスに使用するスニペットにプライベート割り当て演算子とコピーコンストラクターの宣言が含まれているため、新しいクラスを生成するときに、デフォルトの割り当てとコピー操作を取得できません-宣言を明示的に削除する必要がありますprivate:コンパイラーがそれらを生成できるようにしたい場合は、これらの操作のセクションから。

C ++ 20であっても、コンパイラーは暗黙的に生成operator==しません

struct foo
{
    std::string str;
    int n;
};

assert(foo{"Anton", 1} == foo{"Anton", 1}); // ill-formed

ただし、C ++ 20以降は、明示的にデフォルト設定することができます。==

struct foo
{
    std::string str;
    int n;

    // either member form
    bool operator==(foo const&) const = default;
    // ... or friend form
    friend bool operator==(foo const&, foo const&) = default;
};

デフォルト==はメンバーごとに行われます==（デフォルトのコピーコンストラクターがメンバーごとにコピーを作成するのと同じ方法で）。新しい規則はまたの間に予想される関係を与える==と!=。たとえば、上記の宣言では、両方を記述できます。

assert(foo{"Anton", 1} == foo{"Anton", 1}); // ok!
assert(foo{"Anton", 1} != foo{"Anton", 2}); // ok!

この特定の機能（デフォルト設定operator==と対称性の間==とは!=）から来ている一つの提案でより広範な言語機能の一部でしたoperator<=>。

私見、「良い」理由はありません。この設計上の決定に同意する人が非常に多いのは、彼らが値ベースのセマンティクスの力を習得する方法を学んでいないためです。実装では生のポインタを使用するため、多くのカスタムコピーコンストラクタ、比較演算子、デストラクタを記述する必要があります。

適切なスマートポインター（std :: shared_ptrなど）を使用する場合、デフォルトのコピーコンストラクターは通常は問題なく、仮想のデフォルト比較演算子の明らかな実装も問題ありません。

Cがしなかったため、C ++は==をしなかったと回答しました。Cがデフォルト=のみを提供し、==を最初から提供しないのは、ここが理由です。Cはシンプルにしたかった：C実装= memcpyによって。ただし、==は埋め込みのためにmemcmpで実装できません。パディングは初期化されていないため、memcmpは同じであっても異なると言います。同じ問題が空のクラスにも存在します。memcmpは、空のクラスのサイズがゼロでないため、それらが異なると言います。上記から、Cでの==の実装は、Cでの=の実装よりも複雑であることがわかります。これに関するいくつかのコード例。もし私が間違っていればあなたの訂正はありがたいです。

このビデオでは、STLの作成者であるAlex Stepanovが13:00頃にこの質問に対処しています。要約すると、C ++の進化を見守った彼は次のように主張しています。

• ==と！=が暗黙的に宣言されていないのは残念です（そしてBjarneは彼に同意します）。正しい言語はそれらの準備が整っているはずです（彼はさらに、==のセマンティクスを壊す！=を定義できないようにする必要があることを示唆しています）
• これがその理由である理由は、Cにルーツがある（C ++の問題の多くと同様）。そこで、代入演算子はビットごとの代入で暗黙的に定義されますが、==の場合は機能しません。この詳細については、Bjarne Stroustrupの記事をご覧ください。
• フォローアップの質問で、なぜメンバーごとの比較ではなかったのかと彼は驚くべきことを言いました：Cは自家製の言語であり、Ritchieのためにこれらを実装する男は、これを実装するのは難しいと彼に言った！

その後、彼は（遠い）将来的に==および！=が暗黙的に生成されると言います。

C ++ 20は、デフォルトの比較演算子を簡単に実装する方法を提供します。

cppreference.comの例：

class Point {
    int x;
    int y;
public:
    auto operator<=>(const Point&) const = default;
    // ... non-comparison functions ...
};

// compiler implicitly declares operator== and all four relational operators work
Point pt1, pt2;
if (pt1 == pt2) { /*...*/ } // ok, calls implicit Point::operator==
std::set<Point> s; // ok
s.insert(pt1); // ok
if (pt1 <= pt2) { /*...*/ } // ok, makes only a single call to Point::operator<=>

defaultを定義することはできませんが、通常は自分で定義する必要がある==default !=を定義でき==ます。このためには、次のことを行う必要があります。

#include <utility>
using namespace std::rel_ops;
...

class FooClass
{
public:
  bool operator== (const FooClass& other) const {
  // ...
  }
};

詳細については、http：//www.cplusplus.com/reference/std/utility/rel_ops/を参照してください。

さらに、を定義するとoperator< 、<=、>、> =の演算子は、を使用するときにそこから推定できますstd::rel_ops。

ただしstd::rel_ops、比較演算子は予期しない型に対して推定される可能性があるため、使用時には注意が必要です。

基本的な演算子から関連する演算子を推測するより好ましい方法は、boost :: operatorsを使用することです。

ブーストで使用されるアプローチは、スコープ内のすべてのクラスではなく、必要なクラスのみの演算子の使用法を定義するため、より優れています。

「+ =」から「+」を生成したり、「-=」から-を生成したりすることもできます（完全なリストはこちら）

C ++ 0xにはデフォルト関数の提案があるのでdefault operator==; 、これらのことを明示的にするのに役立つことがわかりました。

概念的には、平等を定義することは容易ではありません。PODデータの場合でも、フィールドは同じでも、オブジェクトが異なる（アドレスが異なる）場合でも、必ずしも同じであるとは限りません。これは実際には演算子の使用法に依存します。残念ながら、あなたのコンパイラは精神的ではなく、それを推測することはできません。

これに加えて、デフォルトの機能は足で自分を撃つための優れた方法です。あなたが説明するデフォルトは、基本的にはPOD構造体との互換性を保つためにあります。ただし、開発者がそれらを忘れたり、デフォルトの実装のセマンティクスを使用したりすると、十分な混乱が生じます。

これには正当な理由がありますか？メンバーごとの比較の実行が問題になるのはなぜですか？

機能的には問題ないかもしれませんが、パフォーマンスの点では、デフォルトのメンバーごとの比較は、デフォルトのメンバーごとの割り当て/コピーよりも最適ではない傾向があります。割り当ての順序とは異なり、最初の等しくないメンバーは残りをスキップできることを意味するため、比較の順序はパフォーマンスに影響を与えます。したがって、通常は等しいメンバーがいくつかある場合は、それらを最後に比較し、コンパイラーはどのメンバーが等しい可能性が高いかを認識していません。

この例を考えてみましょう。ここで、verboseDescriptionは、考えられる天気の説明の比較的小さなセットから選択された長い文字列です。

class LocalWeatherRecord {
    std::string verboseDescription;
    std::tm date;
    bool operator==(const LocalWeatherRecord& other){
        return date==other.date
            && verboseDescription==other.verboseDescription;
    // The above makes a lot more sense than
     // return verboseDescription==other.verboseDescription
     //     && date==other.date;
    // because some verboseDescriptions are liable to be same/similar
    }
}

（もちろん、コンパイラーは、副作用がないことを認識した場合、比較の順序を無視する資格がありますが、おそらくそれ自身のより良い情報を持たないソースコードからもクエリを取得します。）

時間が経過してもこの質問への回答が完全なままになるように：C ++ 20以降、コマンドで自動的に生成できます auto operator<=>(const foo&) const = default;

すべての演算子（==、！=、<、<=、>、> =）が生成されます。詳細については、https：//en.cppreference.com/w/cpp/language/default_comparisonsを参照してください。

オペレーターの見た目<=>から、宇宙船オペレーターと呼ばれています。また、C ++でspaceship <=>演算子が必要な理由を参照してください。。

編集：C ++ 11でも、その完全なコード例std::tieについてはhttps://en.cppreference.com/w/cpp/utility/tuple/tieを参照してくださいbool operator<(…)。動作するように変更された興味深い部分==は次のとおりです。

#include <tuple>

struct S {
………
bool operator==(const S& rhs) const
    {
        // compares n to rhs.n,
        // then s to rhs.s,
        // then d to rhs.d
        return std::tie(n, s, d) == std::tie(rhs.n, rhs.s, rhs.d);
    }
};

std::tie すべての比較演算子で機能し、コンパイラによって完全に最適化されます。

私は、PODタイプのクラスの場合、コンパイラーがそれを行うことができることに同意します。ただし、単純に考えるとコンパイラが間違っている可能性があります。そのため、プログラマーに任せるのが良いでしょう。

2つのフィールドが一意であるPODケースが1回ありました。そのため、比較が真と見なされることは決してありません。ただし、必要な比較はペイロードでのみ比較する必要がありました-コンパイラが理解できなかったもの、またはそれ自体で理解できるもの。

その上-彼らは書くのに時間がかかりませんか？！