多くのC ++標準ライブラリコードで不等式が（！（a == b））としてテストされるのはなぜですか？

これは、C ++標準ライブラリremoveコードのコードです。if (!(*first == val))ではなく、なぜ不等式がテストされるのif (*first != val)ですか？

 template <class ForwardIterator, class T>
      ForwardIterator remove (ForwardIterator first, ForwardIterator last, const T& val)
 {
     ForwardIterator result = first;
     while (first!=last) {
         if (!(*first == val)) {
             *result = *first;
             ++result;
         }
         ++first;
     }
     return result;
 }

これは、Tに対する唯一の要件がの実装であることを意味するためoperator==です。Tにを要求することもできますoperator!=が、ここでの一般的な考え方は、テンプレートのユーザーにできる限り負担をかけず、他のテンプレートが必要とすることですoperator==。

STLのほとんどの関数は、operator<またはでのみ機能しoperator==ます。これにより、ユーザーはこれら2つの演算子（または、少なくとも1つの演算子）を実装するだけで済みます。例えばstd::set用途operator<（より正確にはstd::less呼び出したoperator<デフォルトでは）ないoperator>順序を管理します。removeあなたの例のテンプレートは同様のケースです-それは使用するだけで使用operator==しないoperator!=ので、をoperator!=定義する必要はありません。

これは、C ++標準ライブラリのコードを削除したコードです。

違う。これは C ++標準ライブラリremoveコードではありません。これは、C ++標準ライブラリの1つの可能な内部実装ですremove関数。C ++標準は実際のコードを規定していません。関数のプロトタイプと必要な動作を規定します。

言い換えると、厳密な言語の観点から、あなたが見ているコードは は存在しません。コンパイラの標準ライブラリの実装に付属しているヘッダーファイルからのものである可能性があります。C ++標準では、これらのヘッダーファイルが存在する必要さえありません。ファイルは、コンパイラーのインプリメンターが#include <algorithm>（たとえば、std::removeおよびその他の関数を使用可能にする）のような行の要件を満たすための便利な方法です。

if (!(*first == val))ではなく、なぜ不等式がテストされるのif (*first != val)ですか？

operator==関数でのみ必要なため。

カスタム型の演算子のオーバーロードに関しては、この言語を使用すると、あらゆる種類の奇妙なことを実行できます。オーバーロードされたクラスを作成することもできますoperator==いないoperator!=。またはさらに悪いことに、あなたは過負荷になる可能性operator!=がありますが、それは完全に無関係なことをするでしょう。

この例を考えてみましょう：

#include <algorithm>
#include <vector>

struct Example
{
    int i;

    Example() : i(0) {}

    bool operator==(Example const& other) const
    {
        return i == other.i;
    }

    bool operator!=(Example const& other) const
    {
        return i == 5; // weird, but nothing stops you
                       // from doing so
    }

};

int main()
{
  std::vector<Example> v(10);
  // ...
  auto it = std::remove(v.begin(), v.end(), Example());
  // ...
}

std::remove使用した場合operator!=、結果はかなり異なります。

ここでいくつかの良い答え。ちょっとメモを追加したかっただけです。

すべての優れたライブラリと同様に、標準ライブラリは（少なくとも）2つの非常に重要な原則を念頭に置いて設計されています。

1. あなたが逃げることができるあなたのライブラリーのユーザーに最小限の責任を負わせてください。これの一部は、インターフェースを使用するときに最小限の作業を提供することに関係しています。（あなたが逃げることができる限り少ない数の演算子を定義するように）。それの他の部分は、それらを驚くことではなく、またはエラーコードをチェックするように要求することと関係があります（そのため、インターフェイスの一貫性を保ち、問題が発生した<stdexcept>ときに例外をスローします）。

2. すべての論理的な冗長性を排除します。すべての比較は、operator<ので、なぜユーザーに他のものを定義するよう要求するのでしょうか。例えば：

   （a> b）は（b <a）と同等

   （a> = b）は！（a <b）と同等

   （a == b）は！（（a <b）||（b <a））と同等です。

   等々。

   もちろん、このノートでは、なぜ（少なくともデフォルトでは）ではなくがunordered_map必要なのかを質問するかもしれません。答えは、ハッシュテーブルで必要な比較は、等しいかどうかの比較だけです。したがって、等価演算子を定義するように要求する方が論理的に整合性があります（つまり、ライブラリユーザーにとってより理にかなっています）。を必要とするのは、なぜそれが必要なのかがすぐにはわからないため、混乱を招くでしょう。operator==operator<operator<

EqualityComparableコンセプトは唯一のことが必要operator==定義します。

その結果、満足のいくタイプを処理EqualityComparable することを宣言する関数operator!=は、そのタイプのオブジェクトの存在に依存できません。（の存在を暗示する追加の要件がない限りoperator!=）。

最も有望なアプローチは、operator ==が特定の型に対して呼び出されるかどうかを決定し、それが利用可能な場合にのみそれをサポートする方法を見つけることです。他の状況では、例外がスローされます。ただし、これまでのところ、任意の演算子式f == gが適切に定義されているかどうかを検出する既知の方法はありません。既知の最良のソリューションには、以下の望ましくない性質があります。

• operator ==にアクセスできないオブジェクト（たとえば、プライベートであるため）のコンパイル時に失敗します。
• operator ==の呼び出しがあいまいな場合、コンパイル時に失敗します。
• operator ==がコンパイルされない場合でも、operator ==宣言が正しい場合は正しいように見えます。

Boost FAQから：ソース

==実装を要求することは負担であることがわかっているので、要求することで追加の負荷をかけたくない!=。

私個人的には、SOLID（オブジェクト指向設計）L部分-リスコフ置換の原則についてです：「プログラム内のオブジェクトは、そのプログラムの正確さを変更することなく、サブタイプのインスタンスで置き換え可能でなければなりません。」この場合、ブール論理で==およびブール逆に置き換えることができるのは演算子！=です。