&&と||をオーバーロードする理由は実際にありますか？短絡しませんか？

短絡演算子の振る舞い&&とは、||プログラマのための素晴らしいツールです。

しかし、なぜオーバーロードするとこの動作が失われるのですか？演算子は関数の単なる構文糖であると理解していますが、演算子にboolはこのような振る舞いがあります。なぜこの単一の型に制限する必要があるのですか？この背後に技術的な理由はありますか？

すべての設計プロセスは、相互に互換性のない目標間の妥協をもたらします。残念ながら、&&C ++でオーバーロードされた演算子の設計プロセスは、混乱を招く最終結果を生み出しました。つまり、必要な機能（&&その短絡動作）が省略されています。

設計プロセスがどのようにしてこの不幸な場所に到達したかについての詳細は、私にはわかりません。ただし、後の設計プロセスでこの不快な結果がどのように考慮されたかを確認することは重要です。C＃では、過負荷の&&演算子は短絡です。C＃の設計者はそれをどのように達成しましたか？

他の回答の1つは「ラムダリフティング」を示唆しています。あれは：

A && B

道徳的に同等のものとして実現することができます：

operator_&& ( A, ()=> B )

ここで、2番目の引数は遅延評価のメカニズムを使用するため、評価されると、式の副作用と値が生成されます。オーバーロードされた演算子の実装は、必要な場合にのみ遅延評価を行います。

これは、C＃設計チームが行ったことではありません。（脇：ラムダリフティングはかかわらず、であるそれを行うための時間に来たときに私が何をしたかの式ツリー表現のを??。。特定の変換操作を必要とする作業を、遅延し実行することが詳細にしかし主要な余談になるとの記述十分を言うために：ラムダリフティング動作しますが、回避したかったほど十分に重いです。）

むしろ、C＃ソリューションは問題を2つの別個の問題に分解します。

• 右側のオペランドを評価する必要がありますか？
• 上記の答えが「はい」の場合、2つのオペランドをどのように組み合わせるのでしょうか。

したがって、&&直接オーバーロードすることを違法にすることで問題は解決します。むしろ、C＃では2つの演算子をオーバーロードする必要があり、それぞれがこれら2つの質問の1つに答えます。

class C
{
    // Is this thing "false-ish"? If yes, we can skip computing the right
    // hand size of an &&
    public static bool operator false (C c) { whatever }

    // If we didn't skip the RHS, how do we combine them?
    public static C operator & (C left, C right) { whatever }
    ...

（脇に：実際には3つあります。C＃では、演算子falseが指定されている場合は演算子trueも指定する必要があります。これは、「これは本当ですか？」という質問に答えます。通常、そのような演算子を1つだけ指定する理由はないため、C＃両方が必要です。）

次の形式のステートメントについて考えてみます。

C cresult = cleft && cright;

コンパイラは、この疑似C＃を記述したと考えられるように、このためのコードを生成します。

C cresult;
C tempLeft = cleft;
cresult = C.false(tempLeft) ? tempLeft : C.&(tempLeft, cright);

ご覧のとおり、常に左側が評価されます。「偽っぽい」と判断された場合はその結果です。それ以外の場合は、右側が評価され、熱心なユーザー定義演算子&が呼び出されます。

||オペレータは、オペレータの呼び出し真と熱心なように、類似の方法で定義される|演算子。

cresult = C.true(tempLeft) ? tempLeft : C.|(tempLeft , cright);

-すべての4つの演算子を定義することでtrue、false、&および|- C＃は、あなたが言うできるだけでなくcleft && crightだけでなく、非短絡cleft & crightし、またif (cleft) if (cright) ...、とc ? consequence : alternativeしてwhile(c)、そしてそうで。

今、私はすべての設計プロセスが妥協の結果であると述べました。ここで、C＃言語の設計者は短絡&&と||正しい結果を得ることができましたが、そのためには2つではなく4つの演算子をオーバーロードする必要があり、混乱する人もいます。オペレーターのtrue / false機能は、C＃で最もよく理解されていない機能の1つです。C ++ユーザーに馴染みのある賢明でわかりやすい言語を使用するという目標は、短絡させたいという欲求や、ラムダリフティングやその他の形式の遅延評価を実装しないという欲望によって反対されました。私は、それが合理的な妥協の位置だったと思うが、それがあることを認識することが重要であるである妥協の位置。ただ違う C ++の設計者が上陸したときよりも妥協の立場。

そのような演算子の言語設計の主題に興味がある場合は、C＃がこれらの演算子をnull許容ブールで定義しない理由についての私のシリーズを読むことを検討してください。

http://ericlippert.com/2012/03/26/null-is-not-false-part-one/

重要なのは、（C ++ 98の範囲内で）右側のオペランドがオーバーロードされた演算子関数に引数として渡されることです。そうすることで、すでに評価されます。operator||()またはoperator&&()コードがこれを回避することができる、またはできないことは何もありません。

元の演算子は関数ではないため異なりますが、言語の低レベルで実装されます。

追加の言語機能は、可能性があり、右の非評価オペランド構文的に行われている可能性が。ただし、これが意味的に役立つケースはほんの一部しかないため、問題はありませんでした。（と同様に? :、オーバーロードにはまったく使用できません。

（ラムダを標準化するのに16年かかりました...）

意味的な使用については、以下を考慮してください。

objectA && objectB

これは要約すると：

template< typename T >
ClassA.operator&&( T const & objectB )

への変換演算子を呼び出す以外に、ここでobjectB（不明なタイプの）boolをどのように処理したいのか、およびそれを言語定義の単語にどのように挿入するのかを考えてください。

そして、もしあなたが boolへの変換を呼んでいるなら、まあ...

objectA && obectB

同じことをします、今それをしますか？では、なぜ最初からオーバーロードなのでしょうか。

機能は、考慮、設計、実装、文書化、および出荷する必要があります。

さて、それを考えて、なぜ今それが簡単なのか（そして、そうするのが難しいのか）見てみましょう。また、リソースは限られているため、追加すると他の要素が途切れる可能性があることにも注意してください（そのために何を差し控えますか？）。

理論的には、C ++ 11（ラムダが導入されたとき、1979年に「クラス付きC」が開始されてから32年後）で、すべての演算子は1つの「マイナー」追加言語機能のみで短絡動作を許可できましたc ++ 98以降）：

C ++は、必要に応じて許可される（前提条件が満たされる）まで評価を回避するために、遅延評価された引数（隠しラムダ）として引数に注釈を付ける方法が必要です。

その理論的な機能はどのように見えますか（どんな新しい機能も広く使用できるはずです）。

lazyfunction-argumentに適用されるアノテーションは、関数をファンクターを想定したテンプレートにし、コンパイラーに式をファンクターにパックさせます。

A operator&&(B b, __lazy C c) {return c;}

// And be called like
exp_b && exp_c;
// or
operator&&(exp_b, exp_c);

それは次のようにカバーの下に見えます：

template<class Func> A operator&&(B b, Func& f) {auto&& c = f(); return c;}
// With `f` restricted to no-argument functors returning a `C`.

// And the call:
operator&&(exp_b, [&]{return exp_c;});

ラムダは隠されたままであり、多くても一度だけ呼び出されることに注意してください。
これにより、共通部分式が削除される可能性が低くなることを除いて、パフォーマンスが低下することはありません。

実装の複雑さと概念の複雑さ（他の機能の複雑さを十分に緩和しない限り、すべての機能が両方とも増加します）のほかに、別の重要な考慮事項である下位互換性を見てみましょう。

この言語機能はコードを壊すことはありませんが、それを利用してAPIを微妙に変更します。つまり、既存のライブラリでの使用はサイレントブレーク変更になります。

ちなみに、この機能は使いやすくはありますが、C＃で分割&&し||て2つの関数に分割し、それぞれを個別に定義するよりも厳密に強力です。

遡及的合理化では、主に

• （新しい構文を導入せずに）短絡を保証するには、演算子を次のように制限する必要があります。 結果に変換可能な実際の最初の引数bool、および

• 短絡は、必要に応じて他の方法で簡単に表現できます。

たとえば、クラスTに&&and ||演算子が関連付けられている場合、式

auto x = a && b || c;

ここaで、、bおよびcはタイプの式でありT、次のように短絡して表すことができます

auto&& and_arg = a;
auto&& and_result = (and_arg? and_arg && b : and_arg);
auto x = (and_result? and_result : and_result || c);

またはおそらくより明確に

auto x = [&]() -> T_op_result
{
    auto&& and_arg = a;
    auto&& and_result = (and_arg? and_arg && b : and_arg);
    if( and_result ) { return and_result; } else { return and_result || b; }
}();

見かけ上の冗長性により、オペレーターの呼び出しによる副作用が保持されます。

ラムダの書き換えはより詳細ですが、そのより良いカプセル化により、そのような演算子を定義できます。

以下のすべての標準準拠（まだ少し影響があります）は完全にはわかりませんが、Visual C ++ 12.0（2013）およびMinGW g ++ 4.8.2で正常にコンパイルされます。

#include <iostream>
using namespace std;

void say( char const* s ) { cout << s; }

struct S
{
    using Op_result = S;

    bool value;
    auto is_true() const -> bool { say( "!! " ); return value; }

    friend
    auto operator&&( S const a, S const b )
        -> S
    { say( "&& " ); return a.value? b : a; }

    friend
    auto operator||( S const a, S const b )
        -> S
    { say( "|| " ); return a.value? a : b; }

    friend
    auto operator<<( ostream& stream, S const o )
        -> ostream&
    { return stream << o.value; }

};

template< class T >
auto is_true( T const& x ) -> bool { return !!x; }

template<>
auto is_true( S const& x ) -> bool { return x.is_true(); }

#define SHORTED_AND( a, b ) \
[&]() \
{ \
    auto&& and_arg = (a); \
    return (is_true( and_arg )? and_arg && (b) : and_arg); \
}()

#define SHORTED_OR( a, b ) \
[&]() \
{ \
    auto&& or_arg = (a); \
    return (is_true( or_arg )? or_arg : or_arg || (b)); \
}()

auto main()
    -> int
{
    cout << boolalpha;
    for( int a = 0; a <= 1; ++a )
    {
        for( int b = 0; b <= 1; ++b )
        {
            for( int c = 0; c <= 1; ++c )
            {
                S oa{!!a}, ob{!!b}, oc{!!c};
                cout << a << b << c << " -> ";
                auto x = SHORTED_OR( SHORTED_AND( oa, ob ), oc );
                cout << x << endl;
            }
        }
    }
}

出力：

000-> !! !! || 偽
001-> !! !! || 本当
010-> !! !! || 偽
011-> !! !! || 本当
100-> !! && !! || 偽
101-> !! && !! || 本当
110-> !! && !! 本当
111-> !! && !! 本当

ここで、各!!bang-bangはへの変換bool、つまり引数値のチェックを示しています。

コンパイラは同じことを簡単に行うことができ、さらに最適化できるため、これは可能な実装の実証であり、不可能の主張は一般に不可能の主張と同じカテゴリ、つまり一般的にはbollocksに分類する必要があります。

tl; dr：かなり高いコスト（特別な構文が必要）と比較して、需要が非常に低い（誰が機能を使用するのか）ため、努力する価値はありません。

最初に頭に浮かぶのは、演算子のオーバーロードは関数を書くための空想的な方法にすぎないのに対し、演算子||とのブール型&&はbuitlinのものであるということです。コンパイラは表現しながら、ショート彼らに自由を持っていることをそれは意味x = y && znonbooleanとyとzのような関数の呼び出しにつながることがありますX operator&& (Y, Z)。これは、奇妙な名前の関数の呼び出しであり、関数を呼び出す前に両方のパラメーターを評価する必要がある（短絡回路の適切と見なされるものを含む）ことy && zを書くための、派手な方法であることを意味します。operator&&(y,z)

ただし、演算子を変換して関数を呼び出し、その後にコンストラクターを呼び出す&&場合のように、演算子の変換をいくらか洗練させることが可能であると主張することもできます。newoperator new

技術的にはこれは問題になりません。短絡を可能にする前提条件に固有の言語構文を定義する必要があります。しかし、短絡回路の使用は、例に制限されるだろうYとconvetibleであるXか、あるいは実際に短絡（最初のパラメータだけから、すなわち計算結果）を行う方法の追加情報があることがありました。結果は次のようになります。

X operator&&(Y const& y, Z const& z)
{
  if (shortcircuitCondition(y))
    return shortcircuitEvaluation(y);

  <"Syntax for an evaluation-Point for z here">

  return actualImplementation(y,z);
}

operator||and をオーバーロードするoperator&&ことはめったにありません。なぜなら、書き込みがa && b実際には非ブールコンテキストで直感的であるケースはほとんどないからです。私が知っている唯一の例外は、たとえば組み込みDSL用の式テンプレートです。そして、これらの数少ないケースのほんの一握りだけが短絡評価から利益を得るでしょう。式テンプレートは、後で評価される式ツリーを形成するために使用されるため、通常は使用しません。したがって、常に式の両側が必要です。

要するに：コンパイラの作家でも基準もない筆者は百万では、ユーザ定義の上で短絡を持っていいだろうという考えを得るかもしれないという理由だけで、フープを介してジャンプし、追加の面倒な構文を定義し、実装する必要性を感じましたoperator&&し、operator||-ちょうど手作業でロジックを書くことほど簡単ではないという結論に達します。

ラムダスは、怠惰を導入する唯一の方法ではありません。C ++の式テンプレートを使用すると、遅延評価は比較的簡単です。キーワードは必要なくlazy、C ++ 98で実装できます。式ツリーはすでに上記で言及されています。表現テンプレートは貧弱な（しかし賢い）男性の表現ツリーです。トリックは、式をExprテンプレートの再帰的にネストされたインスタンス化のツリーに変換することです。ツリーは、構築後に個別に評価されます。

次のコードは、関数を提供して解放し、に変換できる限り、クラスの短絡演算子&&と||演算子を実装します。コードはC ++ 14にありますが、アイデアはC ++ 98にも適用できます。ライブサンプルをご覧ください。Slogical_andlogical_orbool

#include <iostream>

struct S
{
  bool val;

  explicit S(int i) : val(i) {}  
  explicit S(bool b) : val(b) {}

  template <class Expr>
  S (const Expr & expr)
   : val(evaluate(expr).val)
  { }

  template <class Expr>
  S & operator = (const Expr & expr)
  {
    val = evaluate(expr).val;
    return *this;
  }

  explicit operator bool () const 
  {
    return val;
  }
};

S logical_and (const S & lhs, const S & rhs)
{
    std::cout << "&& ";
    return S{lhs.val && rhs.val};
}

S logical_or (const S & lhs, const S & rhs)
{
    std::cout << "|| ";
    return S{lhs.val || rhs.val};
}


const S & evaluate(const S &s) 
{
  return s;
}

template <class Expr>
S evaluate(const Expr & expr) 
{
  return expr.eval();
}

struct And 
{
  template <class LExpr, class RExpr>
  S operator ()(const LExpr & l, const RExpr & r) const
  {
    const S & temp = evaluate(l);
    return temp? logical_and(temp, evaluate(r)) : temp;
  }
};

struct Or 
{
  template <class LExpr, class RExpr>
  S operator ()(const LExpr & l, const RExpr & r) const
  {
    const S & temp = evaluate(l);
    return temp? temp : logical_or(temp, evaluate(r));
  }
};


template <class Op, class LExpr, class RExpr>
struct Expr
{
  Op op;
  const LExpr &lhs;
  const RExpr &rhs;

  Expr(const LExpr& l, const RExpr & r)
   : lhs(l),
     rhs(r)
  {}

  S eval() const 
  {
    return op(lhs, rhs);
  }
};

template <class LExpr>
auto operator && (const LExpr & lhs, const S & rhs)
{
  return Expr<And, LExpr, S> (lhs, rhs);
}

template <class LExpr, class Op, class L, class R>
auto operator && (const LExpr & lhs, const Expr<Op,L,R> & rhs)
{
  return Expr<And, LExpr, Expr<Op,L,R>> (lhs, rhs);
}

template <class LExpr>
auto operator || (const LExpr & lhs, const S & rhs)
{
  return Expr<Or, LExpr, S> (lhs, rhs);
}

template <class LExpr, class Op, class L, class R>
auto operator || (const LExpr & lhs, const Expr<Op,L,R> & rhs)
{
  return Expr<Or, LExpr, Expr<Op,L,R>> (lhs, rhs);
}

std::ostream & operator << (std::ostream & o, const S & s)
{
  o << s.val;
  return o;
}

S and_result(S s1, S s2, S s3)
{
  return s1 && s2 && s3;
}

S or_result(S s1, S s2, S s3)
{
  return s1 || s2 || s3;
}

int main(void) 
{
  for(int i=0; i<= 1; ++i)
    for(int j=0; j<= 1; ++j)
      for(int k=0; k<= 1; ++k)
        std::cout << and_result(S{i}, S{j}, S{k}) << std::endl;

  for(int i=0; i<= 1; ++i)
    for(int j=0; j<= 1; ++j)
      for(int k=0; k<= 1; ++k)
        std::cout << or_result(S{i}, S{j}, S{k}) << std::endl;

  return 0;
}

関連する真理値表の評価における「最適化」であるため、論理演算子の短絡は許可されます。これはロジック自体の機能であり、このロジックは定義されています。

実際に過負荷&&で||短絡しない理由はありますか？

カスタムのオーバーロードされた論理演算子は、これらの真理値表のロジックに従う必要はありません。

しかし、なぜオーバーロードするとこの動作が失われるのですか？

したがって、関数全体を通常どおりに評価する必要があります。コンパイラーはそれを通常のオーバーロードされた演算子（または関数）として扱う必要があり、他の関数と同様に最適化を適用できます。

人々はさまざまな理由で論理演算子に負荷をかけます。例えば; それらは、人々が慣れている「通常の」論理的なものではない特定のドメインで特定の意味を持つ場合があります。

短絡は「and」と「or」の真理値表によるものです。ユーザーが定義する操作をどのようにして知ることができ、2番目の演算子を評価する必要がないことをどのようにして知ることができますか？

しかしboolの演算子はこの振る舞いをします、なぜそれをこの単一の型に制限する必要があるのですか？

私はこの部分に答えたいだけです。その理由は、組み込みの式&&と||式が、多重定義された演算子のように関数で実装されていないためです。

コンパイラーが特定の式を理解するために、短絡ロジックを組み込むのは簡単です。他の組み込み制御フローと同じです。

ただし、演​​算子のオーバーロードは代わりに関数で実装され、特定のルールがあります。その1つは、引数として使用されるすべての式が、関数が呼び出される前に評価されることです。明らかに異なるルールを定義することもできますが、それはより大きな仕事です。