ทำไมการทดสอบความไม่เท่าเทียมกันเป็น (! (a == b)) ในรหัสไลบรารีมาตรฐาน C ++ จำนวนมาก

นี่คือรหัสจากremoveรหัสไลบรารีมาตรฐาน C ++ ทำไมไม่เท่าเทียมกันทดสอบเป็น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==สิ่งนี้ต้องการให้ผู้ใช้ดำเนินการตัวดำเนินการสองตัวนี้ (หรือบางครั้งก็อย่างน้อยหนึ่งตัว) ตัวอย่างเช่นstd::setใช้operator<(แม่นยำยิ่งขึ้นstd::lessซึ่งเรียกoperator<ตามค่าเริ่มต้น) และไม่operator>จัดการสั่งซื้อ removeแม่แบบในตัวอย่างของคุณเป็นกรณีคล้ายกัน - มันใช้เพียงoperator==และไม่ได้operator!=ดังนั้นoperator!=ไม่จำเป็นต้องมีการกำหนดไว้

นี่คือรหัสจากรหัสลบไลบรารีมาตรฐาน C ++

ไม่ถูกต้อง. มันไม่ได้เป็นc ++ มาตรฐานห้องสมุดรหัส มันเป็นหนึ่งในการนำไปใช้ภายในของฟังก์ชันไลบรารีมาตรฐาน C ++ มาตรฐาน C ++ ไม่ได้กำหนดรหัสจริง มัน prescibes ฟังก์ชั่นต้นแบบและพฤติกรรมที่ต้องการremoveremove

ในคำอื่น ๆ : จากจุดภาษาเข้มงวดในมุมมองของรหัสที่คุณจะได้เห็นไม่ได้อยู่ อาจมาจากไฟล์ส่วนหัวบางไฟล์ที่มาพร้อมกับการใช้งานไลบรารีมาตรฐานของคอมไพเลอร์ของคุณ โปรดทราบว่ามาตรฐาน 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!=แล้วผลจะแตกต่างกันมาก

คำตอบที่ดีที่นี่ ฉันแค่อยากจะเพิ่มโน้ตเล็กน้อย

เช่นเดียวกับห้องสมุดที่ดีห้องสมุดมาตรฐานได้รับการออกแบบโดยมีหลักการสำคัญสองประการ (อย่างน้อย):

1. ให้ความรับผิดชอบต่อผู้ใช้ห้องสมุดน้อยที่สุดเท่าที่จะเป็นไปได้ ส่วนหนึ่งของสิ่งนี้เกี่ยวข้องกับการให้งานน้อยที่สุดเมื่อใช้อินเทอร์เฟซของคุณ (เช่นกำหนดผู้ประกอบการน้อยตามที่คุณสามารถไปด้วย) ส่วนอื่น ๆ นั้นเกี่ยวข้องกับพวกเขาไม่น่าแปลกใจหรือต้องการให้พวกเขาตรวจสอบรหัสข้อผิดพลาด (เพื่อให้อินเตอร์เฟซที่สอดคล้องกันและโยนข้อยกเว้นจาก<stdexcept>เมื่อสิ่งผิดปกติ)

2. กำจัดทุกความซ้ำซ้อนตรรกะ การเปรียบเทียบทั้งหมดสามารถอนุมานได้เพียงจากoperator<เหตุใดจึงต้องการให้ผู้ใช้กำหนดผู้อื่น เช่น:

   (a> b) เทียบเท่ากับ (b <a)

   (a> = b) เทียบเท่ากับ! (a <b)

   (a == b) เทียบเท่ากับ! ((<<) || (b <a))

   และอื่น ๆ

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

EqualityComparableแนวคิดเพียงต้องการให้operator==มีการกำหนดไว้

ดังนั้นฟังก์ชั่นใด ๆ ที่ยอมรับการทำงานกับประเภทที่น่าพอใจEqualityComparable ไม่สามารถพึ่งพาการดำรงอยู่ของoperator!=วัตถุประเภทนั้น (เว้นแต่มีข้อกำหนดเพิ่มเติมที่บ่งบอกถึงการมีอยู่ของoperator!=)

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

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

จากคำถามที่พบบ่อย Boost: แหล่งที่มา

การรู้ว่าต้องมี==การนำไปปฏิบัติเป็นภาระคุณไม่ต้องการสร้างภาระเพิ่มเติมโดยต้องมี!=การนำไปปฏิบัติเช่นกัน

สำหรับฉันเป็นการส่วนตัวเกี่ยวกับSOLID (การออกแบบเชิงวัตถุ) ส่วน L - หลักการทดแทน Liskov:“ วัตถุในโปรแกรมควรเปลี่ยนได้ด้วยอินสแตนซ์ของชนิดย่อยโดยไม่ต้องแก้ไขความถูกต้องของโปรแกรมนั้น” ในกรณีนี้มันคือโอเปอเรเตอร์! =ที่ฉันสามารถแทนที่ด้วย==และบูลีนผกผันในตรรกะบูลีน