ทำไมไม่มีการสร้าง 'สุดท้าย' ใน C ++

การจัดการข้อยกเว้นใน C ++ นั้น จำกัด ให้ลอง / โยน / จับ ไม่เหมือนกับ Object Pascal, Java, C # และ Python แม้ใน C ++ 11 finallyโครงสร้างจะไม่ถูกนำมาใช้

ฉันได้เห็นวรรณกรรม C ++ จำนวนมากที่พูดถึง "ข้อยกเว้นรหัสปลอดภัย" Lippman เขียนว่ารหัสความปลอดภัยยกเว้นเป็นหัวข้อที่มีความสำคัญ แต่ขั้นสูงและยากเกินกว่าขอบเขตของไพรเมอร์ของเขา - ซึ่งดูเหมือนว่าบอกเป็นนัยว่ารหัสความปลอดภัยไม่ได้เป็นพื้นฐานของ C ++ Herb Sutter อุทิศ 10 บทในหัวข้อในภาษา C ++ อันยอดเยี่ยมของเขา!

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

เมื่อพิจารณาถึง 'ระฆังและเสียงนกหวีด' ทั้งหมดที่ใช้ใน C ++ 11 ฉันประหลาดใจที่พบว่า 'ในที่สุด' ก็ยังไม่อยู่ที่นั่น

ดังนั้นทำไมfinallyโครงสร้างไม่เคยถูกนำมาใช้ใน C ++ ไม่ใช่เรื่องยากหรือแนวคิดขั้นสูงที่จะเข้าใจและไปไกลเพื่อช่วยโปรแกรมเมอร์เขียน 'รหัสที่ปลอดภัยยกเว้น'

ในฐานะที่เป็นความเห็นเพิ่มเติมเกี่ยวกับคำตอบของ @ Nemanja (ซึ่งเนื่องจากคำพูดของ Stroustrup นั้นเป็นคำตอบที่ดีพอ ๆ กับที่คุณจะได้รับ)

มันเป็นเพียงเรื่องของการทำความเข้าใจปรัชญาและสำนวนของ C ++ ใช้ตัวอย่างของการดำเนินการที่เปิดการเชื่อมต่อฐานข้อมูลในคลาสถาวรและต้องตรวจสอบให้แน่ใจว่าได้ปิดการเชื่อมต่อนั้นหากมีข้อยกเว้นเกิดขึ้น นี่เป็นเรื่องของความปลอดภัยยกเว้นและใช้กับภาษาใด ๆ ที่มีข้อยกเว้น (C ++, C #, Delphi ... )

ในภาษาที่ใช้try/ finallyรหัสอาจมีลักษณะดังนี้:

database.Open();
try {
    database.DoRiskyOperation();
} finally {
    database.Close();
}

เรียบง่ายและตรงไปตรงมา อย่างไรก็ตามมีข้อเสียบางประการ:

• หากภาษานั้นไม่มีตัวทำลายล้างแบบกำหนดแน่นอนฉันต้องเขียนfinallyบล็อกเสมอมิฉะนั้นฉันจะรั่วไหลทรัพยากร
• ถ้าDoRiskyOperationเป็นมากกว่าการเรียกเมธอดเดียว - ถ้าฉันมีการประมวลผลที่ต้องทำในtryบล็อก - จากนั้นการCloseดำเนินการอาจสิ้นสุดลงเล็กน้อยจากการOpenดำเนินการ ฉันไม่สามารถเขียนการล้างข้อมูลของฉันถัดจากการได้มา
• หากฉันมีทรัพยากรหลายอย่างที่จำเป็นต้องได้รับจากนั้นปลดปล่อยในลักษณะที่ปลอดภัยยกเว้นฉันสามารถจบลงด้วยtry/ finallyบล็อกหลายชั้นลึก

วิธี C ++ จะมีลักษณะเช่นนี้:

ScopedDatabaseConnection scoped_connection(database);
database.DoRiskyOperation();

วิธีนี้จะช่วยแก้ไขข้อเสียทั้งหมดของfinallyวิธีการนี้อย่างสมบูรณ์ มันมีข้อเสียของตัวเองสองสามข้อ แต่ค่อนข้างเล็ก:

• มีโอกาสที่ดีที่คุณจะต้องเขียนScopedDatabaseConnectionชั้นเรียนด้วยตัวเอง อย่างไรก็ตามมันเป็นการใช้งานที่ง่ายมาก - มีโค้ดเพียง 4 หรือ 5 บรรทัด
• มันเกี่ยวข้องกับการสร้างตัวแปรท้องถิ่นเพิ่มเติม - ซึ่งคุณไม่ได้เป็นแฟนของความเห็นของคุณเกี่ยวกับ "การสร้างและทำลายคลาสอย่างต่อเนื่องเพื่อพึ่งพา destructors ของพวกเขาในการทำความสะอาดระเบียบของคุณแย่มาก" - แต่คอมไพเลอร์ที่ดีจะปรับให้เหมาะสม หางานพิเศษใด ๆ ที่ตัวแปรเฉพาะที่เกี่ยวข้อง การออกแบบ C ++ ที่ดีนั้นอาศัยการเพิ่มประสิทธิภาพหลายประเภท

โดยส่วนตัวเมื่อพิจารณาถึงข้อดีและข้อเสียเหล่านี้ฉันพบว่า RAII เป็นเทคนิคที่เป็นที่นิยมfinallyมากกว่า ไมล์สะสมของคุณอาจแตกต่างกันไป

ท้ายที่สุดเพราะ RAII เป็นสำนวนที่ได้รับการยอมรับเป็นอย่างดีในภาษาซีพลัสพลัสและเพื่อลดภาระของนักพัฒนาในการเขียนScoped...คลาสจำนวนมากจึงมีห้องสมุดเช่นScopeGuardและBoost.ScopeExitที่อำนวยความสะดวกในการล้างข้อมูลแบบกำหนด

จากเหตุใด C ++ จึงไม่สร้างโครงสร้าง "ในที่สุด" ในC ++ สไตล์และเทคนิคของ Bjarne Stroustrup คำถามที่พบบ่อย :

เนื่องจาก C ++ สนับสนุนทางเลือกที่เกือบจะดีกว่าเสมอ: เทคนิค "การได้มาซึ่งทรัพยากรเป็นการเริ่มต้น" (TC ++ PL3 ส่วน 14.4) แนวคิดพื้นฐานคือการแสดงทรัพยากรโดยวัตถุในท้องถิ่นเพื่อให้ตัวทำลายวัตถุในท้องถิ่นจะปล่อยทรัพยากร ด้วยวิธีนี้โปรแกรมเมอร์ไม่สามารถลืมที่จะปล่อยทรัพยากร

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

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

เหตุผลที่กล่าวถึงความปลอดภัยของข้อยกเว้นเพิ่มเติมในชุมชน C ++ อาจเกิดจากข้อเท็จจริงที่ว่าใน C ++ คุณต้องระวังสิ่งที่ผิดพลาดมากขึ้นเนื่องจากมีเครือข่ายความปลอดภัยเริ่มต้นน้อยกว่าในภาษา

คนอื่นพูดถึง RAII เป็นวิธีแก้ปัญหา มันเป็นทางออกที่ดีอย่างสมบูรณ์ แต่นั่นไม่ได้ระบุว่าทำไมพวกเขาถึงไม่เพิ่มfinallyเช่นกันเพราะมันเป็นสิ่งที่ต้องการอย่างกว้างขวาง คำตอบนั้นเป็นพื้นฐานในการออกแบบและพัฒนา C ++: ตลอดการพัฒนาของ C ++ ผู้ที่เกี่ยวข้องได้ต่อต้านการแนะนำคุณสมบัติการออกแบบที่สามารถทำได้โดยใช้คุณสมบัติอื่น ๆ โดยไม่ต้องยุ่งยากมาก ของคำหลักใหม่ที่อาจทำให้โค้ดที่เก่ากว่าไม่สามารถทำงานร่วมกันได้ เนื่องจาก RAII ให้ทางเลือกที่มีประสิทธิภาพสูงfinallyและคุณสามารถม้วนตัวคุณเองfinallyใน C ++ 11 ได้ดังนั้นจึงมีการเรียกใช้เล็กน้อย

สิ่งที่คุณต้องทำคือสร้างคลาสFinallyที่เรียกฟังก์ชันที่ส่งผ่านไปยัง constructor ของมันใน destructor จากนั้นคุณสามารถทำสิ่งนี้:

try
{
    Finally atEnd([&] () { database.close(); });

    database.doRisky();
}

โดยทั่วไปโปรแกรมเมอร์ภาษา C ++ ส่วนใหญ่จะชอบวัตถุของ RAII ที่ออกแบบมาอย่างหมดจด

คุณสามารถใช้รูปแบบ "กับดัก" - แม้ว่าคุณไม่ต้องการใช้บล็อกลอง / catch

วางวัตถุอย่างง่ายในขอบเขตที่ต้องการ ใน destructor ของวัตถุนี้วางตรรกะ "finaly" ของคุณ ไม่ว่าจะเกิดอะไรขึ้นเมื่อสแต็กไม่คลายตัวจะมีการเรียกตัวทำลายวัตถุและคุณจะได้ขนมของคุณ

คุณสามารถเรียงลำดับม้วนของคุณเองfinallyโดยใช้ Lambdas ซึ่งจะได้รับดังต่อไปนี้เพื่อรวบรวมค่าปรับ (ใช้ตัวอย่างที่ไม่มี RAII แน่นอนไม่ใช่รหัสที่ดีที่สุด):

{
    FILE *file = fopen("test","w");

    finally close_the_file([&]{
        cout << "We're closing the file in a pseudo-finally clause." << endl;
        fclose(file);
    });
}

ดูบทความนี้

ผมไม่แน่ใจว่าผมเห็นด้วยกับยืนยันว่านี่คือ RAII superset finallyของ ส้นเท้าของจุดอ่อนของ RAII นั้นง่าย: มีข้อยกเว้น RAII ถูกนำไปใช้กับ destructors และมันผิดเสมอใน C ++ ที่จะโยนออกจาก destructor นั่นหมายความว่าคุณไม่สามารถใช้ RAII ได้เมื่อคุณต้องการให้โค้ดการล้างข้อมูลของคุณโยน หากfinallyมีการใช้งานในทางกลับกันก็ไม่มีเหตุผลที่จะเชื่อได้ว่ามันจะไม่ถูกกฎหมายที่จะโยนจากfinallyบล็อก

พิจารณาเส้นทางรหัสเช่นนี้

void foo() {
    try {
        ... stuff ...
        complex_cleanup();
    } catch (A& a) {
        handle_a(a);
        complex_cleanup();
        throw;
    } catch (B& b) {
        handle_b(b);
        complex_cleanup();
        throw;
    } catch (...) {
        handle_generic();
        complex_cleanup();
        throw;
    }
}

ถ้าเรามีfinallyเราสามารถเขียน:

void foo() {
    try {
        ... stuff ...
    } catch (A& a) {
        handle_a(a);
        throw;
    } catch (B& b) {
        handle_b(b);
        throw;
    } catch (...) {
        handle_generic();
        throw;
    } finally {
        complex_cleanup();
    }
}

แต่ไม่มีทางที่ฉันสามารถค้นหาเพื่อให้ได้พฤติกรรมที่เท่าเทียมกันโดยใช้ RAII

หากมีคนรู้วิธีการทำเช่นนี้ใน C ++ ฉันสนใจในคำตอบมาก ฉันยังมีความสุขกับสิ่งที่ต้องพึ่งพาเช่นบังคับให้ข้อยกเว้นทั้งหมดที่สืบทอดมาจากคลาสเดียวที่มีความสามารถพิเศษหรือบางอย่าง