ที่อยู่ C ++ 11 เกี่ยวข้องกับการส่งวัตถุ std lib ระหว่างขอบเขตไลบรารีแบบไดนามิก / ใช้ร่วมกันหรือไม่? (เช่นที่กำลังเป็นต้น)?

หนึ่งในข้อร้องเรียนหลักของฉันเกี่ยวกับ C ++ คือวิธียากในทางปฏิบัติก็คือการส่งวัตถุไลบรารี std นอกขอบเขตไลบรารีแบบไดนามิก (เช่น dll / ดังนั้น)

ไลบรารี std มักเป็นส่วนหัวเท่านั้น ซึ่งเป็นสิ่งที่ดีสำหรับการเพิ่มประสิทธิภาพที่ยอดเยี่ยม อย่างไรก็ตามสำหรับ dll พวกเขามักจะสร้างด้วยการตั้งค่าคอมไพเลอร์ที่แตกต่างกันซึ่งอาจส่งผลกระทบต่อโครงสร้างภายใน / รหัสของคอนเทนเนอร์ไลบรารี std ตัวอย่างเช่นใน MSVC dll หนึ่งอาจสร้างขึ้นด้วยการดีบัก iterator ในขณะที่คนอื่นสร้างมันออก Dll ทั้งสองนี้อาจพบปัญหาในการส่งผ่านคอนเทนเนอร์มาตรฐาน หากฉันเปิดเผยstd::stringในส่วนต่อประสานของฉันฉันไม่สามารถรับประกันได้ว่ารหัสที่ลูกค้าใช้std::stringอยู่นั้นตรงกับห้องสมุดของฉันstd::stringทั้งหมด

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

คำถามของฉันคือ C ++ 11 พยายามทำสิ่งใดเพื่อแก้ไขปัญหาเหล่านี้หรือไม่

คุณถูกต้องว่าอะไร STL - อันที่จริงอะไรจากห้องสมุดบุคคลที่สามซึ่งเป็น templated - จะหลีกเลี่ยงได้ดีที่สุดใน C ++ API สาธารณะใด ๆ คุณต้องการติดตามรายการกฎที่ยาวที่http://www.ros.org/reps/rep-0009.html#definitionเพื่อยับยั้งการแตก ABI ซึ่งทำให้การเขียนโปรแกรม C ++ API สาธารณะเป็นงานที่น่าสนใจ

และคำตอบเกี่ยวกับ C ++ 11 คือไม่มาตรฐานนี้ไม่ได้สัมผัส ที่น่าสนใจคือทำไมไม่ คำตอบก็คือเพราะ C ++ 17 เป็นสิ่งที่สัมผัสได้อย่างมากและสำหรับโมดูล C ++ ที่จะนำไปใช้เราจำเป็นต้องมีเทมเพลตที่ส่งออกเพื่อทำงานและเพื่อที่เราต้องการคอมไพเลอร์ประเภท LLVM เช่นเสียงดังกราวซึ่งสามารถถ่ายโอน AST เต็มแผ่น ทำการค้นหาที่ขึ้นอยู่กับผู้โทรเพื่อจัดการกรณีละเมิด ODR จำนวนมากในโครงการ C ++ ขนาดใหญ่ - ซึ่งรวมถึงรหัส GCC และ ELF จำนวนมาก

ท้ายสุดฉันเห็นความเกลียดชังและความเห็นของ MSVC จำนวนมากเกี่ยวกับ MSVC สิ่งเหล่านี้ผิดไปมาก - GCC บน ELF นั้นเป็นพื้นฐานและไม่สามารถแก้ไขได้ในการผลิตรหัส C ++ ที่ถูกต้องและแก้ไขไม่ได้ สาเหตุของเรื่องนี้มีมากมายและหลากหลาย แต่ฉันจะอ้างตัวอย่างกรณีหนึ่งอย่างรวดเร็ว: GCC บน ELF ไม่สามารถสร้างส่วนขยาย Python ที่เขียนโดยใช้ Boost.Python อย่างปลอดภัยได้ซึ่งมีการโหลดส่วนขยายมากกว่าหนึ่งรายการจาก Boost.Python ลงใน Python อย่างปลอดภัย นั่นเป็นเพราะเอลฟ์ที่มีตารางสัญลักษณ์ C ทั่วโลกนั้นไม่สามารถทำได้โดยการออกแบบเพื่อป้องกันการละเมิด ODR ที่ก่อให้เกิด segfaults ในขณะที่ PE และ MachO และแน่นอนว่าข้อกำหนด C ++ Modules ที่เสนอทั้งหมดใช้ตารางสัญลักษณ์ต่อโมดูล และยังมีปัญหาอีกมากมาย: ดู StackOverflow ที่ฉันตอบเมื่อเร็ว ๆ นี้ที่https://stackoverflow.com/questions/14268736/symbol-visibility-exceptions-runtime-error/14364055#14364055ตัวอย่างเช่นที่การขว้างข้อยกเว้น C ++ นั้นแตกอย่างไม่สามารถแก้ไขได้ใน ELF

ประเด็นสุดท้าย: เกี่ยวกับการสอดแทรก STL ที่แตกต่างกันนี่เป็นความเจ็บปวดครั้งใหญ่สำหรับผู้ใช้องค์กรขนาดใหญ่จำนวนมากที่พยายามผสมผสานห้องสมุดบุคคลที่สามซึ่งมีการบูรณาการอย่างแน่นหนากับการนำ STL ไปใช้ ทางออกเดียวคือกลไกใหม่สำหรับ C ++ เพื่อจัดการกับ STL interop และในขณะที่พวกมันอยู่ในนั้นคุณอาจแก้ไขคอมไพเลอร์ interop ด้วยดังนั้นคุณสามารถ (ตัวอย่าง) ผสมไฟล์ MSVC, GCC และ clang รวบรวมวัตถุและมันใช้งานได้ . ฉันจะดูความพยายามของ C ++ 17 และดูว่ามีอะไรเกิดขึ้นบ้างในอีกไม่กี่ปีข้างหน้า - ฉันจะแปลกใจถ้าไม่มีอะไรเกิดขึ้น

สเปคไม่เคยมีปัญหานี้ นั่นเป็นเพราะมันมีแนวคิดที่เรียกว่า "หนึ่งนิยามกฎ" ซึ่งบังคับว่าสัญลักษณ์แต่ละอันมีคำจำกัดความเดียวในกระบวนการทำงาน

Windows DLLs ละเมิดข้อกำหนดนี้ นั่นเป็นเหตุผลที่มีปัญหาเหล่านี้ทั้งหมด ดังนั้นมันขึ้นอยู่กับ Microsoft ที่จะแก้ไขไม่ใช่คณะกรรมการมาตรฐาน C ++ Unix ไม่เคยมีปัญหานี้เพราะไลบรารีที่ใช้งานร่วมกันมีความแตกต่างกันและโดยค่าเริ่มต้นจะเป็นไปตามกฎความหมายเดียว (คุณสามารถทำลายมันได้อย่างชัดเจน แต่คุณจะทำอย่างชัดเจนถ้าคุณรู้ว่าคุณสามารถจ่ายได้

Windows DLLs ละเมิดกฎข้อกำหนดหนึ่งข้อเนื่องจาก:

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

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

ปัญหาอื่นเป็นของธงคอมไพเลอร์ ปัญหานั้นมีอยู่สำหรับโปรแกรมใด ๆ ที่ประกอบด้วยหน่วยการคอมไพล์หลายหน่วยไลบรารีแบบไดนามิกไม่จำเป็นต้องเกี่ยวข้อง อย่างไรก็ตามมันแย่กว่านั้นใน Windows บน Unix มันไม่สำคัญว่าคุณจะเชื่อมโยงแบบคงที่หรือแบบไดนามิกไม่มีใครเชื่อมโยงรันไทม์มาตรฐานแบบคงที่อยู่แล้ว (ใน Linux มันอาจผิดกฎหมาย) และไม่มีการดีบักพิเศษเป็นพิเศษดังนั้นการสร้างหนึ่งจึงดีพอ แต่วิธีที่ Microsoft ใช้การเชื่อมโยงแบบสแตติกและไดนามิกการดีบักและรีลีสรันไทม์และตัวเลือกอื่น ๆ หมายถึงพวกมันทำให้เกิดการระเบิดแบบ combinatorial ของไลบรารีที่ต้องการ ปัญหาแพลตฟอร์มอีกครั้งแทนที่จะเป็นปัญหาภาษา C ++

เลขที่

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