เหตุใดเราจึงใส่ฟังก์ชันสมาชิกส่วนตัวไว้ในส่วนหัว

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

ทำไมเราต้องใส่สมาชิกส่วนบุคคลไว้ในหัว?

แต่มีเหตุผลใดที่จะประกาศฟังก์ชั่นส่วนตัวในคำจำกัดความของชั้นเรียน?

ทางเลือกจะเป็นสำนวน pimpl เป็นหลัก แต่ไม่มีทิศทางฟุ่มเฟือย

คุณสมบัติภาษานี้เป็นมากกว่าข้อผิดพลาดในอดีตหรือไม่?

ฟังก์ชั่นสมาชิกส่วนตัวอาจเป็นไปได้virtualและในการใช้งานทั่วไปของ C ++ (ที่ใช้ vtable) ลำดับที่เฉพาะเจาะจงและจำนวนของฟังก์ชั่นเสมือนจะต้องเป็นที่รู้จักโดยลูกค้าทั้งหมดของชั้นเรียน สิ่งนี้ใช้ได้แม้ว่าฟังก์ชันสมาชิกเสมือนหนึ่งฟังก์ชันprivateขึ้นไป

อาจดูเหมือนว่านี่เป็นเหมือน "การวางเกวียนก่อนม้า" เนื่องจากตัวเลือกการใช้งานคอมไพเลอร์ไม่ควรส่งผลกระทบต่อข้อกำหนดภาษา อย่างไรก็ตามในความเป็นจริงภาษา C ++ เองได้รับการพัฒนาในเวลาเดียวกันกับการใช้งาน ( Cfront ) ซึ่งใช้ vtables

หากคุณอนุญาตให้มีการเพิ่มวิธีการในชั้นเรียนนอกคำจำกัดความของพวกเขาก็สามารถเพิ่มได้ทุกที่ทุกคนในไฟล์ใด ๆ

นั่นจะทำให้ลูกค้าทุกคนเข้าถึงข้อมูลส่วนตัวและป้องกันข้อมูลได้เล็กน้อย

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

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

ตัวระบุการเข้าถึงเหล่านี้ไม่ได้พยายามป้องกันการโจมตีเหล่านี้เพราะมันเป็นไปไม่ได้ พวกเขาระบุว่าควรใช้คลาสอย่างไร

คำตอบที่ได้รับการยอมรับจะอธิบายสิ่งนี้สำหรับฟังก์ชั่นส่วนตัวเสมือนแต่ตอบเพียงแง่มุมหนึ่งของคำถามซึ่งมีข้อ จำกัด มากกว่าสิ่งที่ OP ถาม ดังนั้นเราจำเป็นต้องใช้ถ้อยคำใหม่: ทำไมเราจึงจำเป็นต้องประกาศฟังก์ชั่นส่วนตัวที่ไม่ใช่เสมือนในส่วนหัว?

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

ดังนั้นฉันต้องการที่จะให้คำตอบว่าแทนที่จะรวมถึงวิธีการส่วนตัวโดยค่าเริ่มต้นให้คะแนนที่เฉพาะเจาะจงแก่ผู้ใช้ที่มองเห็นได้ เหตุผลเชิงกลไกสำหรับฟังก์ชั่นส่วนตัวที่ไม่ใช่เสมือนจริงที่ต้องมีการประกาศสาธารณะในGotW # 100 ของ Herb Sutter เกี่ยวกับ Pimpl idiomซึ่งเป็นส่วนหนึ่งของเหตุผล ฉันจะไม่ไปเกี่ยวกับ Pimpl ที่นี่เพราะฉันแน่ใจว่าเราทุกคนรู้เกี่ยวกับมัน แต่นี่คือบิตที่เกี่ยวข้อง:

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

• ขนาดและเค้าโครง : [ของสมาชิกและฟังก์ชั่นเสมือนจริง - อธิบายตนเองและยอดเยี่ยมสำหรับประสิทธิภาพ แต่ไม่ใช่เหตุผลที่เรามาที่นี่]
• ฟังก์ชั่น : รหัสการโทรจะต้องสามารถแก้ไขการโทรไปยังฟังก์ชั่นสมาชิกของคลาสรวมถึงฟังก์ชั่นส่วนตัวที่ไม่สามารถเข้าถึงได้ซึ่งเกินพิกัดด้วยฟังก์ชั่นที่ไม่ใช่ส่วนตัว - ถ้าฟังก์ชั่นส่วนตัวตรงกันมากขึ้นรหัสโทรจะไม่สามารถรวบรวมได้ (C ++ ทำการตัดสินใจโดยเจตนาเพื่อทำการแก้ไขโอเวอร์โหลดก่อนการตรวจสอบการเข้าถึงเพื่อเหตุผลด้านความปลอดภัยตัวอย่างเช่นรู้สึกว่าการเปลี่ยนการเข้าถึงการใช้งานของฟังก์ชั่นจากส่วนตัวเป็นสาธารณะไม่ควรเปลี่ยนความหมายของรหัสโทรทางกฎหมาย)

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

มีสองเหตุผลในการทำเช่นนี้

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

ความรัดกุม

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

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

มีข้อได้เปรียบที่สำคัญอีกประการหนึ่งซึ่งก็คือ ...

ฟังก์ชั่นแบบอินไลน์

ฟังก์ชั่นส่วนตัวอาจจะสามารถ inline และจำเป็นต้องให้มันอยู่ในส่วนหัว พิจารณาสิ่งนี้:

class A {
  private:
    inline void myPrivateFunction() {
      ...
    }

  public:
    inline void somePublicFunction() {
      myPrivateFunction();
      ...
    }
};

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

อีกเหตุผลที่จะมีวิธีการส่วนตัวในไฟล์ส่วนหัว: มีหลายกรณีที่วิธีแบบอินไลน์สาธารณะไม่มากไปกว่าการโทรหนึ่งหรือหลายวิธีส่วนตัว การมีเมธอดไพรเวตในส่วนหัวหมายความว่าการเรียกเมธอดพับลิกสามารถอินไลน์เข้ากับโค้ดจริงของเมธอดส่วนตัวและการอินไลน์ไม่ได้หยุดด้วยการเรียกเมธอดไพรเวต แม้จะมาจากหน่วยรวบรวมที่แตกต่างกัน (และวิธีการสาธารณะมักจะถูกเรียกจากหน่วยการรวบรวมที่แตกต่างกัน)

แน่นอนว่ามีเหตุผลเช่นกันที่คอมไพเลอร์ไม่สามารถตรวจพบปัญหาเกี่ยวกับการแก้ปัญหาการโอเวอร์โหลดหากไม่ทราบวิธีการทั้งหมดรวมถึงวิธีส่วนตัว

เป็นการอนุญาตให้ฟังก์ชั่นเหล่านั้นเข้าถึงสมาชิกส่วนตัวได้ มิฉะนั้นคุณจะต้องให้friendพวกเขาในส่วนหัวต่อไป

หากฟังก์ชั่นใด ๆ สามารถเข้าถึงสมาชิกส่วนตัวของชั้นเรียนแล้วส่วนตัวจะไม่มีประโยชน์