มีเหตุผลจริงหรือไม่ที่ทำให้เกิดการ && และ || มากเกินไป อย่าลัดวงจร?

พฤติกรรมการลัดวงจรของผู้ปฏิบัติงาน&&และ||เป็นเครื่องมือที่ยอดเยี่ยมสำหรับโปรแกรมเมอร์

แต่ทำไมพวกเขาถึงสูญเสียพฤติกรรมนี้เมื่อทำงานหนักเกินไป? ฉันเข้าใจว่าตัวดำเนินการเป็นเพียงน้ำตาลเชิงซ้อนสำหรับฟังก์ชั่น แต่ผู้ปฏิบัติงานboolมีพฤติกรรมนี้ทำไมจึงต้อง จำกัด ประเภทเดียวนี้ มีเหตุผลทางเทคนิคที่อยู่เบื้องหลังสิ่งนี้หรือไม่?

กระบวนการออกแบบทั้งหมดส่งผลให้เกิดการประนีประนอมระหว่างเป้าหมายที่เข้ากันไม่ได้ น่าเสียดายที่กระบวนการออกแบบสำหรับ&&ผู้ดำเนินการที่มีการโอเวอร์โหลดใน C ++ นั้นสร้างผลลัพธ์ที่น่าสับสน: ซึ่งจะไม่มีการแสดงคุณลักษณะที่คุณต้องการจาก&&พฤติกรรมการลัดวงจรที่สั้นมาก

รายละเอียดว่ากระบวนการออกแบบนั้นสิ้นสุดลงอย่างไรในสถานที่ที่โชคร้ายเหล่านี้ที่ฉันไม่รู้ อย่างไรก็ตามมีความเกี่ยวข้องเพื่อดูว่ากระบวนการออกแบบในภายหลังนำผลลัพธ์ที่ไม่พึงประสงค์นี้มาพิจารณาอย่างไร ใน C # ตัว&&ดำเนินการที่โอเวอร์โหลดคือการลัดวงจร นักออกแบบของ C # ประสบความสำเร็จได้อย่างไร

หนึ่งในคำตอบอื่น ๆ ชี้ให้เห็น "แลมบ์ดายก" นั่นคือ:

A && B

สามารถตระหนักได้ว่าเป็นสิ่งที่มีคุณธรรมเทียบเท่ากับ:

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

โดยที่อาร์กิวเมนต์ที่สองใช้กลไกบางอย่างสำหรับการประเมินผลแบบขี้เกียจดังนั้นเมื่อประเมินผลข้างเคียงและมูลค่าของนิพจน์จะถูกสร้างขึ้น การใช้งานโอเปอเรเตอร์ที่โอเวอร์โหลดจะทำการประเมินแบบเลหลังเมื่อจำเป็นเท่านั้น

นี่ไม่ใช่สิ่งที่ทีมออกแบบ C # ทำ (นอกเหนือจาก: แม้ว่าการยกแลมบ์ดาเป็นสิ่งที่ฉันทำเมื่อถึงเวลาที่ต้องทำนิพจน์การเป็นตัวแทนของ??โอเปอเรเตอร์ซึ่งต้องการการดำเนินการแปลงบางอย่างที่จะดำเนินการอย่างเกียจคร้านอธิบายว่าในรายละเอียด ใช้งานได้ แต่มีน้ำหนักมากพอที่เราต้องการหลีกเลี่ยง)

แต่วิธีการแก้ปัญหา C # แบ่งปัญหาออกเป็นสองปัญหาที่แยกจากกัน:

• เราควรประเมินตัวถูกดำเนินการทางขวาหรือไม่?
• ถ้าคำตอบข้างต้นคือ "ใช่" แล้วเราจะรวมตัวถูกดำเนินการทั้งสองได้อย่างไร?

ดังนั้นจึงแก้ปัญหาได้โดยทำให้ผิดกฎหมายเกินพิกัด&&โดยตรง แต่ใน C # คุณต้องโอเวอร์โหลดโอเปอเรเตอร์สองตัวซึ่งแต่ละอันตอบคำถามหนึ่งในสองข้อนั้น

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 }
    ...

(นอกเหนือจาก: จริง ๆ สามข้อ C # ต้องการว่าหากfalseมีการให้โอเปอเรเตอร์แล้วtrueต้องให้โอเปอเรเตอร์ซึ่งตอบคำถาม: สิ่งนี้คือ "true-ish?" โดยทั่วไปแล้วไม่มีเหตุผลที่จะให้โอเปอเรเตอร์เดียว ต้องใช้ทั้งคู่)

พิจารณาข้อความของแบบฟอร์ม:

C cresult = cleft && cright;

คอมไพเลอร์สร้างรหัสสำหรับสิ่งนี้ตามที่คิดว่าคุณเขียน pseudo-C # นี้:

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

อย่างที่คุณเห็นด้านซ้ายมือจะถูกประเมินเสมอ ถ้ามันถูกกำหนดให้เป็น "false-ish" มันก็จะเป็นผลลัพธ์ มิฉะนั้นทางด้านขวาจะได้รับการประเมินและผู้ดำเนินการที่ผู้ใช้กำหนดเองกระตือรือร้น&จะถูกเรียกใช้

ตัว||ดำเนินการถูกกำหนดในลักษณะที่คล้ายคลึงกันเป็นการเรียกใช้ตัวดำเนินการจริงและตัว|ดำเนินการกระตือรือร้น:

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

โดยการกำหนดทั้งสี่ผู้ประกอบการ - true, false, &และ|- C # ช่วยให้คุณไม่เพียง แต่พูดcleft && crightแต่ยังไม่ใช่ลัดวงจรcleft & crightและif (cleft) if (cright) ...และc ? consequence : alternativeและwhile(c)และอื่น ๆ

ตอนนี้ฉันบอกว่ากระบวนการออกแบบทั้งหมดเป็นผลมาจากการประนีประนอม ที่นี่นักออกแบบภาษา C # ได้รับการลัดวงจร&&และ||ถูกต้อง แต่การทำเช่นนั้นต้องใช้ตัวดำเนินการจำนวนมากเกินสี่ตัวแทนที่จะเป็นสองตัวซึ่งบางคนรู้สึกสับสน ผู้ประกอบการคุณสมบัติจริง / เท็จเป็นหนึ่งในคุณสมบัติที่เข้าใจกันน้อยที่สุดใน C # เป้าหมายของการมีภาษาที่เข้าใจง่ายและตรงไปตรงมาซึ่งผู้ใช้ C ++ คุ้นเคยนั้นถูกต่อต้านโดยความปรารถนาที่จะมีการลัดวงจรและความปรารถนาที่จะไม่ใช้การยกแลมบ์ดาหรือการประเมินแบบขี้เกียจในรูปแบบอื่น ๆ ฉันคิดว่านั่นเป็นตำแหน่งการประนีประนอมที่สมเหตุสมผล แต่สิ่งสำคัญคือต้องตระหนักว่ามันเป็นตำแหน่งการประนีประนอม ต่างกันเพียง ประนีประนอมตำแหน่งมากกว่าผู้ออกแบบของ C ++

หากหัวเรื่องของการออกแบบภาษาสำหรับผู้ให้บริการดังกล่าวสนใจคุณให้พิจารณาอ่านซีรี่ส์ของฉันว่าเพราะเหตุใด C # จึงไม่ได้กำหนดโอเปอเรเตอร์เหล่านี้ไว้ใน Booleans ที่ไม่มีค่า:

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และวิธีที่คุณต้องการใส่ลงไปในคำว่าสำหรับความหมายภาษา

และถ้าคุณกำลังเรียกร้องการแปลงบูลดี ...

objectA && obectB

ทำสิ่งเดียวกันตอนนี้หรือไม่ ดังนั้นทำไมเกินในครั้งแรก?

คุณสมบัติจะต้องคำนึงถึงการออกแบบการใช้งานเอกสารและการจัดส่ง

ตอนนี้เราคิดถึงมันมาดูกันว่าทำไมตอนนี้อาจเป็นเรื่องง่าย (และยากที่จะทำ) โปรดทราบว่ามีทรัพยากรในปริมาณที่ จำกัด ดังนั้นการเพิ่มอาจมีการสับอย่างอื่น (คุณต้องการนำมาใช้เพื่ออะไร)

ในทางทฤษฎีผู้ปฏิบัติงานทุกคนสามารถอนุญาตให้มีพฤติกรรมการลัดวงจรเพียงภาษาเดียวที่มี " ภาษารอง" เพิ่มเติมในภาษา C ++ 11 (เมื่อมีการแนะนำ lambdas, 32 ปีหลังจาก "C กับคลาส" เริ่มในปี 2522 หลังจาก c ++ 98):

C ++ จะต้องมีวิธีในการใส่คำอธิบายข้อโต้แย้งที่ขี้เกียจ - ประเมิน - แลมบ์ดา - เพื่อหลีกเลี่ยงการประเมินผลจนจำเป็นและได้รับอนุญาต (พบเงื่อนไขก่อน)

คุณลักษณะทางทฤษฎีจะมีลักษณะอย่างไร (โปรดจำไว้ว่าคุณลักษณะใหม่ใด ๆ ควรใช้งานได้อย่างกว้างขวาง)

คำอธิบายประกอบlazyซึ่งใช้กับฟังก์ชั่นอาร์กิวเมนต์ทำให้ฟังก์ชั่นแม่แบบที่คาดหวังว่านักแสดงและทำให้คอมไพเลอร์แพ็คการแสดงออกใน functor:

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 ใด ๆ ที่ใช้ประโยชน์จากมันซึ่งหมายความว่าการใช้งานใด ๆ ในห้องสมุดที่มีอยู่จะเป็นการเปลี่ยนแปลงที่เงียบ

BTW: คุณลักษณะนี้ในขณะที่ใช้งานง่ายกว่านั้นจะแข็งแกร่งกว่าโซลูชัน C # ในการแยก&&และแบ่งออก||เป็นสองฟังก์ชั่นสำหรับการแยกคำจำกัดความ

ด้วยการหาเหตุผลเข้าข้างตนเองย้อนหลังส่วนใหญ่เป็นเพราะ

• เพื่อรับประกันการลัดวงจร (โดยไม่แนะนำไวยากรณ์ใหม่) ผู้ประกอบการจะต้องถูก จำกัด ผลอาร์กิวเมนต์แรกที่สามารถแปลงเป็นboolจริงและ

• การลัดวงจรสามารถแสดงได้อย่างง่ายดายในวิธีอื่นเมื่อจำเป็น

ตัวอย่างเช่นถ้าชั้นTมีความเกี่ยวข้อง&&และ||ผู้ประกอบการแล้วการแสดงออก

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; }
}();

ความซ้ำซ้อนที่เห็นได้ชัดช่วยรักษาผลข้างเคียงใด ๆ จากการเรียกใช้ตัวดำเนินการ

ในขณะที่การเขียนแลมบ์ดานั้นมีความละเอียดมากขึ้นการห่อหุ้มที่ดีขึ้นทำให้ผู้ใช้สามารถกำหนดตัวดำเนินการดังกล่าวได้

ฉันไม่แน่ใจทั้งหมดของการปฏิบัติตามมาตรฐานของทั้งหมดต่อไปนี้ (ยังคงเป็นบิตของ influensa) แต่มันคอมไพล์อย่างสะอาดด้วย 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 -> !! && !! จริง

ที่นี่!!บางปังแสดงให้เห็นถึงการแปลงboolคือการตรวจสอบค่าอาร์กิวเมนต์

เนื่องจากคอมไพเลอร์สามารถทำเช่นเดียวกันได้อย่างง่ายดายและเพิ่มประสิทธิภาพให้ดียิ่งขึ้นนี่คือการดำเนินการที่เป็นไปได้และการเรียกร้องใด ๆ ที่เป็นไปไม่ได้จะต้องอยู่ในหมวดหมู่เดียวกันกับข้อเรียกร้องที่เป็นไปไม่ได้

tl; dr : มันไม่คุ้มค่ากับความพยายามเนื่องจากมีความต้องการต่ำมาก (ใครจะใช้คุณสมบัตินี้) เปรียบเทียบกับค่าใช้จ่ายที่ค่อนข้างสูง (จำเป็นต้องใช้ไวยากรณ์พิเศษ)

สิ่งแรกที่ควรคำนึงถึงคือการใช้งานตัวดำเนินการมากเกินไปเป็นวิธีแฟนซีในการเขียนฟังก์ชั่นในขณะที่เวอร์ชันบูลีนของโอเปอเรเตอร์||และ&&เป็นของ buitlin นั่นหมายความว่าคอมไพเลอร์มีอิสระในการลัดวงจรพวกเขาในขณะที่การแสดงออกx = y && zกับ nonboolean yและมีจะนำไปสู่การเรียกร้องให้ฟังก์ชั่นเช่นz X operator&& (Y, Z)นี่หมายถึงว่าy && zเป็นวิธีแฟนซีในการเขียนoperator&&(y,z)ซึ่งเป็นเพียงการเรียกใช้ฟังก์ชันที่มีชื่อแปลก ๆ ซึ่งพารามิเตอร์ทั้งสองจะต้องถูกประเมินก่อนเรียกฟังก์ชัน (รวมถึงสิ่งใดก็ตามที่จะถือว่าเป็นการลัดวงจรที่เหมาะสม)

แต่หนึ่งได้ยืนยันว่ามันควรจะเป็นไปได้ที่จะทำให้การแปลของ&&ผู้ประกอบการที่ค่อนข้างมีความซับซ้อนมากขึ้นเช่นมันเป็นสำหรับnewผู้ประกอบการที่จะแปลเป็นฟังก์ชั่นการโทรoperator newตามด้วยโทรคอนสตรัค

เทคนิคนี้จะไม่มีปัญหาใครจะต้องกำหนดไวยากรณ์ภาษาเฉพาะสำหรับเงื่อนไขที่เปิดใช้งานการลัดวงจร อย่างไรก็ตามการใช้ไฟฟ้าลัดวงจรจะถูก จำกัด ในกรณีที่Yไม่สามารถใช้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||และoperator&&เนื่องจากมีไม่ค่อยมีกรณีที่การเขียนa && bจริงเป็นธรรมชาติในบริบท nonboolean ข้อยกเว้นเดียวที่ฉันรู้คือเทมเพลตนิพจน์เช่นสำหรับ DSL แบบฝัง และมีเพียงไม่กี่รายเท่านั้นที่จะได้รับประโยชน์จากการประเมินการลัดวงจร โดยปกติแล้วเทมเพลตนิพจน์จะไม่ทำเช่นนั้นเนื่องจากจะใช้สร้างฟอร์มนิพจน์ที่ประเมินในภายหลังดังนั้นคุณจึงจำเป็นต้องใช้ทั้งสองด้านของนิพจน์เสมอ

ในระยะสั้น: ค่าคอมไพเลอร์นักเขียนมิได้มาตรฐานผู้เขียนรู้สึกว่าจำเป็นต้องกระโดดผ่านห่วงและกำหนดและใช้ไวยากรณ์ที่ยุ่งยากเพิ่มเติมเพียงเพราะหนึ่งในล้านอาจได้รับความคิดที่ว่ามันจะดีที่จะมีการลัดวงจรในที่ผู้ใช้กำหนดoperator&&และoperator||- เพียงแค่ เพื่อให้ได้ข้อสรุปว่าการพยายามเขียนลอจิกต่อมือไม่น้อยกว่านั้น

แลมบ์ดาไม่ใช่วิธีเดียวที่จะแนะนำความขี้เกียจ การประเมิน Lazy ค่อนข้างตรงไปตรงมาโดยใช้เทมเพลตนิพจน์ใน C ++ ไม่จำเป็นต้องใช้คำหลักlazyและสามารถนำไปใช้ใน C ++ 98 ต้นไม้แสดงอารมณ์ได้กล่าวถึงข้างต้นแล้ว เทมเพลตนิพจน์นั้นเป็นต้นไม้แสดงอารมณ์ของมนุษย์ที่น่าสงสาร (แต่ฉลาด) เคล็ดลับคือการแปลงนิพจน์เป็นแผนผังของอินสแตนซ์ที่ซ้อนกันซ้ำ ๆ ของExprแม่แบบ ต้นไม้จะถูกประเมินแยกต่างหากหลังจากการก่อสร้าง

ดำเนินต่อไปรหัสลัดวงจร&&และ||ผู้ประกอบการสำหรับการเรียนSตราบใดที่มันยังมีบริการlogical_andและฟังก์ชั่นฟรีและมันเป็นแปลงสภาพให้แก่logical_or boolรหัสอยู่ใน C ++ 14 แต่แนวคิดนี้ใช้ใน C ++ 98 ได้เช่นกัน ดูตัวอย่างจริง

#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;
}

ลัดวงจรตัวดำเนินการเชิงตรรกะได้รับอนุญาตเพราะมันเป็น "การเพิ่มประสิทธิภาพ" ในการประเมินผลของตารางความจริงที่เกี่ยวข้อง มันเป็นฟังก์ชั่นของตรรกะตัวเองและตรรกะนี้ถูกกำหนดไว้

จริงๆแล้วมีเหตุผลทำไมโอเวอร์โหลด&&และ||ไม่เกิดไฟฟ้าลัดวงจร?

ตัวดำเนินการโลจิคัลที่โอเวอร์โหลดแบบกำหนดเองไม่จำเป็นต้องทำตามตรรกะของตารางความจริงเหล่านี้

แต่ทำไมพวกเขาถึงสูญเสียพฤติกรรมนี้เมื่อทำงานหนักเกินไป?

ดังนั้นฟังก์ชั่นทั้งหมดจะต้องมีการประเมินตามปกติ คอมไพเลอร์จะต้องถือว่ามันเป็นตัวดำเนินการโอเวอร์โหลดแบบปกติ

ผู้คนโอเวอร์โหลดตัวดำเนินการเชิงตรรกะด้วยเหตุผลหลายประการ ตัวอย่างเช่น; พวกเขาอาจมีความหมายเฉพาะในโดเมนเฉพาะที่ไม่ใช่คนธรรมดา "ตรรกะ" คนคุ้นเคย

การลัดวงจรเป็นเพราะตารางความจริงของ "และ" และ "หรือ" คุณจะรู้ได้อย่างไรว่าการดำเนินการที่ผู้ใช้กำลังจะกำหนดและคุณจะรู้ได้อย่างไรว่าคุณไม่จำเป็นต้องประเมินผู้ประกอบการรายที่สอง?

แต่ตัวดำเนินการสำหรับบูลมีลักษณะการทำงานนี้ทำไมจึงควร จำกัด ประเภทเดียวนี้

ฉันแค่อยากตอบส่วนนี้ เหตุผลคือบิวด์อิน&&และ||นิพจน์ไม่ถูกนำไปใช้กับฟังก์ชันเนื่องจากตัวดำเนินการโอเวอร์โหลด

การมีตรรกะการลัดวงจรในตัวเพื่อความเข้าใจของคอมไพเลอร์เกี่ยวกับนิพจน์เฉพาะนั้นเป็นเรื่องง่าย มันเหมือนกับโฟลว์การควบคุมในตัวอื่น ๆ

แต่โอเปอเรเตอร์การบรรทุกเกินพิกัดจะถูกนำไปใช้กับฟังก์ชันแทนซึ่งมีกฎเฉพาะซึ่งหนึ่งในนั้นคือนิพจน์ทั้งหมดที่ใช้เป็นอาร์กิวเมนต์จะได้รับการประเมินก่อนที่จะเรียกใช้ฟังก์ชัน เห็นได้ชัดว่าสามารถกำหนดกฎที่แตกต่างกันได้ แต่นั่นเป็นงานที่ใหญ่กว่า