เหตุใด C ให้ภาษา 'การผูก' ที่ C ++ สั้น

60

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

อย่างไรก็ตามหนึ่งรายการในโพสต์นั้นจะได้รับการแก้ไขซ้ำแล้วซ้ำอีกโดยไม่มีตัวอย่างการตรวจสอบหรือคำอธิบายใด ๆ :

"รหัส C เหมาะสำหรับเมื่อคุณต้องการผูกหลายภาษาสำหรับห้องสมุดของคุณ"

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

บางคนช่วยอธิบายเหตุผลที่ชัดเจนว่าทำไมการเขียนไลบรารี่ใน C ช่วยให้การผูกและ / หรือการพกพาในภาษาอื่นง่ายขึ้น?

programming-languages c portability binding

— smeeb
แหล่งที่มา

6

ส่วนใหญ่ด้วยเหตุผลทางประวัติศาสตร์และสังคม การใช้งานภาษาและระบบรันไทม์ส่วนใหญ่จะถูกสร้างขึ้นเหนือ C ตัวอย่างเช่น Ocaml, SBCL, Haskell runtimes จะถูกเข้ารหัสใน C (และจะไม่ได้รับมากนักจากการถูกบันทึกใน C ++)

— Basile Starynkevitch

8

ในทางปฏิบัติการติดไลบรารี่ C ++ ของแท้ (คิดว่า Qt) ลงใน runtimes เหล่านี้เป็นสิ่งที่เจ็บปวด

— Basile Starynkevitch

3

@Basile: Qt ไม่ใช่ไลบรารี C ++ ของแท้ ยิ่งไปกว่านั้นสำหรับห้องสมุดที่เจ็บปวดมากกว่านี้มันเจ็บปวดเพียงเพราะแสดงความหมายที่เป็นประโยชน์จริง ๆ

— DeadMG

2

กึ่งเกี่ยวข้อง: programmers.stackexchange.com/a/185159/20756

— Blrfl

2

อ่าน Essential COM by Don Box มันอธิบายกระบวนการสร้าง ABI ใน C ++ COM เป็นวิธีของ Microsoft ในการสร้าง ABI เช่นไลบรารี COM C ++ สามารถใช้ได้จาก C หรือ VB หรือภาษาอื่น ๆ

— user93353

69

C มีอินเทอร์เฟซที่เรียบง่ายกว่ามากและกฎสำหรับการแปลงอินเทอร์เฟซของรหัสแหล่งที่มาเป็นอินเทอร์เฟซแบบไบนารีนั้นตรงไปตรงมามากพอที่จะสร้างอินเทอร์เฟซภายนอกเพื่อผูกเข้าด้วยกัน ในทางกลับกัน C ++ นั้นมีอินเตอร์เฟซที่ซับซ้อนอย่างเหลือเชื่อและกฎสำหรับการผูก ABI นั้นไม่ได้มาตรฐานเลยไม่เป็นทางการหรือในทางปฏิบัติ ซึ่งหมายความว่าคอมไพเลอร์ใด ๆ สำหรับภาษาใด ๆ สำหรับแพลตฟอร์มใด ๆ สามารถผูกกับอินเตอร์เฟส C ภายนอกและรู้ว่าต้องคาดหวังอะไร แต่สำหรับอินเตอร์เฟส C ++ มันเป็นไปไม่ได้เพราะกฎเปลี่ยนแปลงขึ้นอยู่กับคอมไพเลอร์รุ่นใดและรุ่นไหน แพลตฟอร์มรหัส C ++ ถูกสร้างขึ้นด้วย

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

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

- C ++ มีข้อบกพร่อง

— Mason Wheeler
แหล่งที่มา

4

คุณควรทราบว่าในขณะที่เป็นไปได้ที่จะกำหนด API แบบ C-like ที่นำมาใช้ใน C ++ ( extern "C"แต่ก็ยังมีงานเพิ่มเติมที่ต้องทำเช่นนั้นซึ่งควรจะมีความสมดุลกับคุณสมบัติที่จัดทำโดย C ++)

— jhominal

5

c ++ ABI จะไม่เกี่ยวข้องในบริบทของคำถามที่ c ++ extern "C"ห้องสมุดสามารถส่งออกได้อย่างง่ายดายด้วย

— DeadMG

12

@ jhominal: มันดีกว่าการเขียนใน C ซึ่งคุณต้องกำหนดอินเตอร์เฟส C แล้วคุณต้องใช้มันใน C ในขณะที่ C ++ คุณสามารถกำหนด C interface ได้แล้วคุณไม่ต้องทำอะไรเลย ใน C ไม่ว่าคุณจะใช้ภาษาใดคุณยังคงต้องกำหนดอินเตอร์เฟส C ซึ่งแน่นอนว่าเป็นจริงใน C ++ เนื่องจากเป็น C หรือภาษาอื่น ๆ ที่สามารถแสดงการผูก C ได้

— DeadMG

9

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

— Martin Ba

2

@DocBrown: ดูเหมือนว่าฉันชอบคำถามเกี่ยวกับการผูกภาษา C กับการผูกภาษา C ++

— Mason Wheeler

32

หากคุณพยายามสื่อสารกับผู้พูดภาษาอื่นพิดกินก็ง่ายกว่าภาษาอังกฤษของเชกสเปียร์

แนวคิดของ C - การเรียกใช้ฟังก์ชันพอยน์เตอร์สตริงที่สิ้นสุดด้วยค่า NULL นั้นตรงไปตรงมามากดังนั้นภาษาอื่น ๆ สามารถนำไปปฏิบัติได้ดีพอที่จะเรียกใช้ฟังก์ชัน C ด้วยเหตุผลทางประวัติศาสตร์ภาษาอื่น ๆ จำนวนมากถูกนำไปใช้ใน C ซึ่งทำให้การเรียกฟังก์ชัน C ง่ายยิ่งขึ้น

C ++ เพิ่มเนื้อหาเล็กน้อย - คลาสพร้อมการสืบทอดและ vtables และตัวดัดแปลงการเข้าถึง ข้อยกเว้นกับกองคลี่คลายและเปลี่ยนการไหลของการควบคุม; แม่แบบ ทั้งหมดนี้ทำให้ยากสำหรับภาษาอื่น ๆ ที่จะใช้การผูก C ++: ที่ดีที่สุดมีมากกว่า "กาว" หรือรหัสการทำงานร่วมกันที่จะใช้และที่เลวร้ายที่สุดแนวคิดไม่ได้แปลโดยตรง (เนื่องจากความแตกต่างในรูปแบบการเรียนการจัดการข้อยกเว้น ฯลฯ ) สำหรับเทมเพลตโดยเฉพาะเพียงใช้ (การสร้างอินสแตนซ์) โดยทั่วไปแล้วพวกเขาต้องการขั้นตอนการคอมไพล์ด้วยคอมไพเลอร์ C ++ ซึ่งมีความซับซ้อนอย่างมากในการใช้พวกมันจากสภาพแวดล้อมอื่น ๆ

จากข้อมูลทั้งหมดที่กล่าวมาเป็นไปได้ที่จะกล่าวเกินความยากลำบากในการจัดเตรียมการเชื่อมโยงจากไลบรารี C ++ ไปยังภาษาอื่น:

การเชื่อมโยง C ++ สามารถทำงานร่วมกันได้เหมือนกับ C หากคุณเต็มใจที่จะทำงาน เมื่อ @DeadMG ชี้ให้เห็นว่า C ++ รองรับextern "C"ดังนั้นคุณสามารถส่งออกการผูกภาษา C-style (ด้วยความเรียบง่ายและความเข้ากันได้ของการผูก C) จากไลบรารี C ++ (ด้วยข้อ จำกัด ที่คุณไม่สามารถแสดง C ++ - ฟังก์ชันการทำงานเฉพาะ) .
อีกข้อคัดค้านที่พบบ่อยในการผูกภาษา C ++ คือการขาดเสถียรภาพ ABI สำหรับ C ++ แต่สิ่งนี้ก็เกินเลยไปเช่นกัน C ++ ABIs นั้นมีมาตรฐานน้อยกว่า C ABIs แต่มีมาตรฐานและมาตรฐานโดยพฤตินัย (Itanium C ++ ABI ซึ่งใช้กับ OS X ; GCC มาตรฐาน de factoสำหรับ Linux) Windows แย่กว่านั้นแม้ใน Windows การใช้งานVisual C ++ เวอร์ชั่นเดียวควรทำงานได้ดี

— Josh Kelley
แหล่งที่มา

1

ปัญหาอื่นที่มีการเชื่อมโยงจากไลบรารี C ++ ไปยังภาษาอื่นคือภาษาอื่นอาจต้องการการเชื่อมโยงใน Cหรือสำหรับภาษาที่มีสิ่งที่ต้องการ (.NET) P / Invoke หรือ (python) ctypes อาจไม่มีเครื่องมือใด ๆ สำหรับการใช้ C ++ ABI

— Random832

6

@ Random832: ซึ่งไม่เกี่ยวข้องอย่างสมบูรณ์เมื่อด้าน C ++ สามารถเสนออินเตอร์เฟส C คุณไม่ต้องใช้การรวมใน C เพื่อเสนอการรวม C

— DeadMG

21

C เป็นหนึ่งในภาษาที่เก่าแก่ที่สุดยังอยู่รอบ ๆ ABI มันเป็นเรื่องง่ายและแทบทุกระบบปฏิบัติการยังคงใช้อยู่ในปัจจุบันได้รับการเขียนในนั้น ในขณะที่บางส่วนของระบบปฏิบัติการเหล่านั้นอาจมีการเพิ่มสิ่งต่าง ๆ เช่นใน C # /. NET หรืออะไรก็ตามที่อยู่ด้านบนลงมาด้านล่าง

นั่นหมายความว่าในการที่จะใช้ฟังก์ชั่นที่มีให้โดยระบบปฏิบัติการแทบทุกภาษาโปรแกรมออกมีจำเป็นต้องมีวิธีการติดต่อกับห้องสมุด C อยู่แล้ว Perl, Java, C ++, พวกเขาทั้งหมดโดยกำเนิดให้วิธีการ "พูดคุย C" เพราะพวกเขาจะต้องหากพวกเขาไม่ต้องการที่จะบูรณาการทุกล้อเดียวมี

สิ่งนี้ทำให้ C เป็นภาษาละตินของภาษาโปรแกรม (อินเทอร์เน็ตกี่ปีก่อนที่คำอุปมาจะต้องเป็น "ภาษาอังกฤษของภาษาการเขียนโปรแกรม"?)

เมื่อคุณเขียนไลบรารีของคุณใน C คุณจะได้รับอินเตอร์เฟสที่เข้ากันได้กับ C ฟรี (ชัด) หากคุณกำลังเขียนห้องสมุดของคุณใน C ++ คุณสามารถรับการผูก C ผ่านextern "C"การประกาศตามที่คุณกล่าวถึง

แต่คุณจะได้รับการผูกเหล่านั้นเพียงสำหรับการทำงานที่สามารถแสดงใน C

ดังนั้นไลบรารี API ของคุณไม่สามารถใช้ ...

แม่แบบ
ชั้นเรียน
ข้อยกเว้น
ฟังก์ชั่นใด ๆ ที่รับหรือส่งคืนวัตถุ

ตัวอย่างง่ายๆหนึ่งตัวอย่างคุณจะต้องทำให้ฟังก์ชั่นที่ส่งออกของคุณรับและส่งคืนอาร์เรย์ ( []) แทนstd::vector(หรือstd::stringสำหรับเรื่องนั้น)

ดังนั้นไม่เพียง แต่คุณจะไม่สามารถมอบสิ่งดีๆที่ C ++ นำเสนอให้กับลูกค้าของห้องสมุดของคุณคุณยังต้องใช้ความพยายามเพิ่มเติมในการ "แปล" ไลบรารี API ของคุณจาก C ++ เป็น "เข้ากันได้กับ C" ( extern "C")

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

— DevSolar
แหล่งที่มา

Windows ดูเหมือนว่าจะพยายามยึดฐาน. NET ไว้ Android จะใช้ Java (เช่น C เป็นรายละเอียดการใช้งานสำหรับAPI บางตัว ) และ iOS / OSX นั้นยึดตาม Objective-C

— 253751

1

ภาษาอังกฤษเป็นภาษาที่ใช้กันอย่างแพร่หลายในโลกแห่งการเขียนโปรแกรม โดดเด่นกว่าในอาชีพอื่น

— Siyuan Ren

3

@immibis: Windows, Linux / Android และ BSD / OSX เป็นเคอร์เนลทั้งหมดที่เขียนด้วย C พร้อมด้วยอินเตอร์เฟสที่เขียนใน (และสำหรับ) C. ไม่ว่าสิ่งที่สร้างขึ้นบนนั้น Java ต้องการ JNI, Perl ต้องการการเรียก C NET ต้องการการโทร C, Python ต้องการการโทร C, Objective-C ต้องการการโทร C ไม่จำเป็นต้องมีการโทร C ++ ซึ่งเป็นจุดที่ฉันพยายามจะทำ

— DevSolar

@DevSolar หลาย ๆ สิ่งที่ Android เขียนขึ้นในภาษาจาวาและไม่ได้ใช้ JNI (คุณสามารถใช้ "ย้อนกลับ" เพื่อเรียกรหัส Java จาก C แต่นั่นเป็นการยืนยันต่อไปว่าเป็นภาษาจาวา) ไม่มีประสบการณ์กับ iOS / OSX แต่ฉันได้ยินว่าเหมือนกันกับ Objective-C

— 253751

3

@immibis: แต่คุณทำทราบความแตกต่างระหว่างเคอร์เนล OS และ userspace ของมัน, คุณไม่? ฉันสงสัยอย่างจริงจังว่าส่วนใหญ่ผู้ใช้ Java ทำให้ Android เคอร์เนลลินุกซ์ที่มีการเรียกระบบ C-style น้อยกว่าเคอร์เนล Linux ที่ทำงานบนเดสก์ท็อปของฉัน ฉันยังสงสัยว่าพวกเขากำลังใช้ Java ในเคอร์เนลหรือในมิดเดิลแวร์ ที่จริงฉันรู้ว่าพวกเขากำลังใช้ C ที่นั่น มันเป็นปัญหาของไก่กับไข่ มันถูกทำใน C ก่อนและทำให้มันจึงง่ายมากที่จะยังคงทำมันในซี

— DevSolar

6

ออกจากรายละเอียดคำตอบอื่น ๆ แล้วให้:

เหตุผลที่หลายภาษามีการเชื่อมโยง C คือระบบปฏิบัติการ * nix และ Windows ทั้งหมดเปิดเผย OS OS ส่วนใหญ่ผ่านทางอินเตอร์เฟส C ดังนั้นการติดตั้งภาษาจึงจำเป็นต้องเชื่อมต่อกับ C เพื่อให้สามารถทำงานบนระบบปฏิบัติการหลักได้ ดังนั้นจึงเป็นเรื่องง่ายที่จะเสนอการสื่อสารโดยตรงกับอินเตอร์เฟส C ใด ๆ จากภาษานั้น ๆ

— Martin Ba
แหล่งที่มา

5

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

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

— DeadMG
แหล่งที่มา

4

ฉันคิดว่าคุณถูกต้องและ downvoters เข้าใจผิดคำถาม แต่จริงๆแล้วคำตอบของคุณพลาดที่จะเน้นความเข้าใจผิดที่อาจเกิดขึ้น: คำถามไม่เกี่ยวกับ "ห้องสมุดที่มีอินเตอร์เฟซ C" กับ "ห้องสมุดที่มีอินเทอร์เฟซ C ++" "ไลบรารีที่เขียนด้วย C" กับ "ไลบรารีที่มีอินเตอร์เฟส C เขียนเป็น C ++"

— Doc Brown

@Snowman: การมีปัญหาการผูก C ++ นั้นไม่เกี่ยวข้องกับปัญหาใด ๆ กับการเปิดเผยการผูก C

— DeadMG

2

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

— prosfilaes

2

@prosfilaes: มันเป็นการง่ายที่จะแปลงข้อยกเว้นเป็นรหัสที่ส่งคืน คุณไม่จำเป็นต้องหลีกเลี่ยงการใช้คลาสเนื่องจากคลาสเหล่านั้นสามารถลดลงใน C API ได้อย่างง่ายดายและคุณไม่จำเป็นต้องหลีกเลี่ยงการใช้แม่แบบในการใช้งานของคุณ และผู้ใช้ของคุณไม่จำเป็นต้องพูดถึงเรื่องการปะทะกันของ C ++ ABI เว้นแต่ว่าพวกเขากำลังสร้างจากแหล่งข้อมูลในกรณีนี้คุณต้องจัดการกับภาษาต้นฉบับไม่ว่าจะเป็นอะไรก็ตาม

— DeadMG

4

ฉันไม่ได้ลงคะแนนเพราะไม่ควรเขียนไลบรารีด้วย C API ใน C ++ แต่เนื่องจากมีเหตุผลที่ดีในการใช้ C นอกเหนือจากการเป็นไดโนเสาร์ หากคุณกำลังเขียนสำหรับ API ในภาษา X ให้เป็น C, FORTRAN, COBOL, BLISS หรือ Java เสมอมีเวลาที่มันจะง่ายขึ้นง่ายขึ้นและถูกต้องมากขึ้นในการเขียนในภาษานั้นแล้วเขียนเป็นนักเล่น ภาษาสนุกมากขึ้นและอินเทอร์เฟซทั้งสอง

— prosfilaes

2

มีสองแกนหลักเมื่อเชื่อมต่อกับภาษาอื่น:

แนวคิดที่อินเทอร์เฟซสามารถดำเนินการ: เพียงแค่ค่า? อ้างอิง? generics?
วิธีการนำอินเตอร์เฟสมาใช้ใน "ไบนารี" (เรียกว่า ABI)

C มีข้อได้เปรียบมากกว่า C ++ ในสองแนวหน้า:

C มีแนวคิดแบบง่าย ๆ ส่วนใหญ่ซึ่งปรากฏในเกือบทุกภาษาอื่น ๆ¹
ABI ของ C ไบนารีได้รับการตัดสินโดย OS ²

ตอนนี้ทำไมภาษาส่วนใหญ่จึงมีแนวคิดที่คล้ายกันมากกว่า C อาจเป็นเพราะ "ง่าย" หรือ "มีอยู่ก่อน"; มันไม่สำคัญว่าประเด็นคือพวกเขาทำ

ในทางตรงกันข้าม C ++ มีแนวคิดที่ซับซ้อนและ ABI จะถูกตัดสินใจโดยคอมไพเลอร์แต่ละตัว (แม้ว่าหลายคนจะปฏิบัติตาม Itanimum ABI ยกเว้นใน Windows ... ) มีข้อเสนอจาก Herb Sutter เพื่อให้ระบบปฏิบัติการแก้ไข C ++ ABI (ตามระบบปฏิบัติการต่อ) เพื่อแก้ไขปัญหานี้บางส่วน นอกจากนี้หนึ่งควรทราบว่า c ++ FFI เป็นไปได้, D มันเป็นความพยายามที่3

¹ยกเว้น variadics ( ...) สิ่งเหล่านั้นไม่ง่าย

² C มีมาตรฐาน ABI หรือไม่

^{3 การ} เชื่อมต่อรหัส D ถึง Legacy C ++

— Matthieu M.
แหล่งที่มา

0

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

C ++ อาจมีมาตรฐาน ABI แต่ Stroustrup บอกว่าเขาไม่เห็นความต้องการสิ่งใดสิ่งหนึ่ง เขายังบอกด้วยว่ามันยากที่จะได้รับฉันทามติจากผู้เขียนคอมไพเลอร์ (แม้ว่าฉันสงสัยว่า - คณะกรรมการมาตรฐาน C ++ จะออก ABI คล้ายกับที่มีอยู่เดิมและผู้เขียนคอมไพเลอร์ก็จะแก้ไขคอมไพเลอร์รุ่นต่อไป สร้างขึ้นด้วยคอมไพเลอร์เวอร์ชันเก่า - ฉันจำการคอมไพล์ไลบรารีสองสามครั้งด้วยคอมไพเลอร์ Sun ใหม่และพบว่าพวกเขาไม่สามารถทำงานกับไลบรารีเก่าได้)

คุณจะทราบว่าบาง บริษัท ได้ย้ายไปใช้มาตรฐาน ABI, Microsoft เริ่มกระบวนการนี้ด้วยวิธี COM ใน 90s และวันนี้พวกเขาได้กลั่นกรองเรื่องนี้ใน WinRT ABI (เพื่อไม่ให้สับสนกับ WinRT อื่น ๆ ที่อ้างถึง ไปยังประเภทของตาราง OS) ที่อนุญาตให้โปรแกรมที่เขียนใน C # สื่อสารกับไลบรารีที่เขียนใน C หรือ C ++ (เช่นเลเยอร์ OS ของ Microsoft เองถูกเขียนใน C ++, เปิดเผยโดยใช้ WinRT และใช้งานโดย C # เมื่อเรียกรูทีน OS

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

ดังนั้นคำตอบคือจริงๆ C ไม่ได้ให้การเชื่อมโยงภาษา มันเกิดขึ้นที่ไม่มีใครฟังและกินพวกเขาโดยไม่คำนึงถึง

— gbjbaanb
แหล่งที่มา

-2

คำตอบทั้งหมดขาดปัญหาที่แท้จริง: การคอมไพล์ C ++ แนะนำ "mangling" ดังนั้นไบนารีจะไม่เข้ากันกับการเรียกใช้ฟังก์ชัน "ง่าย"

สิ่งทั้งหมดของ ABI นั้นเล็กไปกว่าความพยายามทำให้เป็นมาตรฐาน

โดยทั่วไปไม่รับประกันว่าคุณจะสามารถใช้งานฟังก์ชั่น cross-link ที่คอมไพล์เลอร์ต่าง ๆ ได้แม้ว่าคุณจะใช้ C ++ ธรรมดาก็ตาม ก่อนหน้านี้มันแน่ใจว่าพวกเขาเข้ากันไม่ได้ แต่ปัจจุบันมาตรฐานกำลังคืบคลานเข้ามา;)

OTOH C ได้รับการออกแบบอย่างแม่นยำเพื่อให้เป็น "การประกอบระดับสูง" และให้การเชื่อมต่อที่ง่ายทุกประเภท ไม่ควรแปลกใจว่ามันดีกว่าที่จะชอบภาษาข้าม

หมายเหตุด้านข้าง: คอมไพเลอร์ C ++ ดั้งเดิม (cfront) สร้างแหล่ง C ที่ต้องเรียบเรียงเหมือนกับ gcc ที่สร้างชุดประกอบ "ภายใต้ประทุน"

— ZioByte
แหล่งที่มา