ฉันรู้ว่านี่เป็นกระทู้เก่า แต่ไม่มีใครพูดถึงอินเทอร์เฟซ ABI หรือปัญหาเฉพาะของคอมไพเลอร์ ฉันก็เลยคิดว่าฉันจะ
โดยพื้นฐานแล้วขึ้นอยู่กับแนวคิดของคุณไม่ว่าจะเป็นการเขียนไลบรารีที่มีส่วนหัวเพื่อแจกจ่ายให้กับผู้คนหรือใช้ซ้ำกับตัวเองเทียบกับการมีทุกอย่างในส่วนหัว หากคุณกำลังคิดที่จะนำไฟล์ส่วนหัวและไฟล์ต้นฉบับมาใช้ซ้ำและคอมไพล์ใหม่ในทุกโปรเจ็กต์สิ่งนี้ไม่ได้มีผลบังคับใช้
โดยทั่วไปถ้าคุณคอมไพล์โค้ด C ++ ของคุณและสร้างไลบรารีด้วยคอมไพเลอร์หนึ่งคอมไพเลอร์ผู้ใช้พยายามใช้ไลบรารีนั้นกับคอมไพเลอร์อื่นหรือคอมไพเลอร์รุ่นอื่นคุณอาจได้รับข้อผิดพลาดตัวเชื่อมโยงหรือพฤติกรรมรันไทม์แปลก ๆ เนื่องจากความไม่ลงรอยกันของไบนารี
ตัวอย่างเช่นผู้จำหน่ายคอมไพเลอร์มักเปลี่ยนการนำ STL ไปใช้ระหว่างเวอร์ชัน หากคุณมีฟังก์ชันในไลบรารีที่ยอมรับ std :: vector ก็คาดว่าไบต์ในคลาสนั้นจะถูกจัดเรียงตามวิธีการจัดเรียงเมื่อไลบรารีถูกคอมไพล์ หากในคอมไพเลอร์เวอร์ชันใหม่ผู้ขายได้ทำการปรับปรุงประสิทธิภาพให้กับ std :: vector แล้วโค้ดของผู้ใช้จะเห็นคลาสใหม่ซึ่งอาจมีโครงสร้างที่แตกต่างกันและส่งผ่านโครงสร้างใหม่นั้นไปยังไลบรารีของคุณ ทุกอย่างลงเนินจากที่นั่น ... นี่คือเหตุผลที่ไม่แนะนำให้ส่งวัตถุ STL ข้ามขอบเขตไลบรารี เช่นเดียวกับประเภท C Run-Time (CRT)
ในขณะที่พูดถึง CRT โดยทั่วไปแล้วไลบรารีของคุณและซอร์สโค้ดของผู้ใช้จะต้องเชื่อมโยงกับ CRT เดียวกัน ด้วย Visual Studio หากคุณสร้างไลบรารีของคุณโดยใช้ CRT แบบมัลติเธรด แต่ผู้ใช้เชื่อมโยงกับ Multithreaded Debug CRT คุณจะมีปัญหาในการเชื่อมโยงเนื่องจากไลบรารีของคุณอาจไม่พบสัญลักษณ์ที่ต้องการ ฉันจำไม่ได้ว่าเป็นฟังก์ชันใด แต่สำหรับ Visual Studio 2015 Microsoft ได้สร้างฟังก์ชัน CRT แบบอินไลน์หนึ่งฟังก์ชัน ทันใดนั้นมันอยู่ในส่วนหัวไม่ใช่ไลบรารี CRT ดังนั้นไลบรารีที่คาดว่าจะพบในเวลาลิงก์ไม่สามารถทำได้อีกต่อไปและเกิดข้อผิดพลาดในการเชื่อมโยง ผลลัพธ์ก็คือไลบรารีเหล่านี้จำเป็นต้องทำการคอมไพล์ใหม่ด้วย Visual Studio 2015
คุณยังสามารถได้รับข้อผิดพลาดในการเชื่อมโยงหรือพฤติกรรมแปลก ๆ หากคุณใช้ Windows API แต่คุณสร้างด้วยการตั้งค่า Unicode ที่แตกต่างกันสำหรับผู้ใช้ไลบรารี เนื่องจาก Windows API มีฟังก์ชันที่ใช้สตริง Unicode หรือ ASCII และมาโคร / กำหนดว่าจะใช้ประเภทใดที่ถูกต้องโดยอัตโนมัติตามการตั้งค่า Unicode ของโครงการ หากคุณส่งสตริงข้ามขอบเขตไลบรารีซึ่งเป็นประเภทที่ไม่ถูกต้องสิ่งต่าง ๆ จะพังเมื่อรันไทม์ หรือคุณอาจพบว่าโปรแกรมไม่ได้เชื่อมโยงในตอนแรก
สิ่งเหล่านี้ยังเป็นจริงสำหรับการส่งผ่านวัตถุ / ประเภทข้ามขอบเขตไลบรารีจากไลบรารีบุคคลที่สามอื่น ๆ (เช่นเวกเตอร์ Eigen หรือเมทริกซ์ GSL) หากไลบรารีของบุคคลที่สามเปลี่ยนส่วนหัวระหว่างคุณคอมไพล์ไลบรารีและผู้ใช้ของคุณคอมไพล์โค้ดของพวกเขาสิ่งต่างๆจะพัง
โดยพื้นฐานแล้วเพื่อความปลอดภัยสิ่งเดียวที่คุณสามารถข้ามผ่านขอบเขตไลบรารีได้ถูกสร้างขึ้นในประเภทและข้อมูลเก่าธรรมดา (POD) ตามหลักการแล้ว POD ใด ๆ ควรอยู่ในโครงสร้างที่กำหนดไว้ในส่วนหัวของคุณเองและอย่าพึ่งพาส่วนหัวของบุคคลที่สาม
หากคุณจัดเตรียมไลบรารีส่วนหัวเท่านั้นโค้ดทั้งหมดจะถูกคอมไพล์ด้วยการตั้งค่าคอมไพเลอร์เดียวกันและเทียบกับส่วนหัวเดียวกันดังนั้นปัญหาเหล่านี้จึงหมดไป (การให้ไลบรารีส่วนที่สามเวอร์ชันที่คุณและผู้ใช้ของคุณใช้นั้นเข้ากันได้กับ API)
อย่างไรก็ตามมีข้อเสียที่ได้กล่าวไว้ข้างต้นเช่นเวลาในการรวบรวมข้อมูลที่เพิ่มขึ้น นอกจากนี้คุณอาจดำเนินธุรกิจดังนั้นคุณอาจไม่ต้องการส่งรายละเอียดการติดตั้งซอร์สโค้ดทั้งหมดของคุณให้กับผู้ใช้ของคุณในกรณีที่หนึ่งในนั้นขโมยไป