เหตุใดฟังก์ชัน C จึงไม่สามารถเปลี่ยนชื่อได้

ฉันมีการสัมภาษณ์เมื่อเร็ว ๆ นี้และมีคำถามหนึ่งที่ถามคือการใช้extern "C"รหัส C ++ คืออะไร ฉันตอบว่ามันคือการใช้ฟังก์ชั่น C ในรหัส C ++ เนื่องจาก C ไม่ใช้ name-mangling ฉันถูกถามว่าทำไม C ถึงไม่ใช้ชื่อเล่นและพูดตามตรงว่าฉันไม่สามารถตอบได้

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

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

มันเป็นคำตอบข้างต้น แต่ฉันจะพยายามทำให้ทุกอย่างเป็นบริบท

อันดับแรกซีมาก่อน ดังนั้นสิ่งที่ C ทำคือ "ค่าเริ่มต้น" มันไม่ได้โกงชื่อเพราะมันไม่ได้ ชื่อฟังก์ชันคือชื่อฟังก์ชัน ทั่วโลกคือโลกและอื่น ๆ

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

int function(int a);
int function();

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

ตอนนี้เราเหลือปัญหา หากint function(int a)ได้รับการกำหนดไว้ในโมดูลเซลเซียสและเรากำลังเพียงการส่วนหัวของมัน (เช่นการประกาศ) ใน C ++ _function_intรหัสและใช้มันคอมไพเลอร์จะสร้างการเรียนการสอนให้กับตัวเชื่อมโยงที่จะนำเข้า เมื่อกำหนดฟังก์ชันในโมดูล C จะไม่เรียกสิ่งนั้น _functionมันถูกเรียกว่า สิ่งนี้จะทำให้เกิดข้อผิดพลาดตัวเชื่อมโยง

เพื่อหลีกเลี่ยงข้อผิดพลาดนั้นในระหว่างการประกาศฟังก์ชันเราจะบอกคอมไพเลอร์ว่าเป็นฟังก์ชันที่ออกแบบมาเพื่อเชื่อมโยงหรือคอมไพเลอร์โดยคอมไพเลอร์ C:

extern "C" int function(int a);

ขณะนี้คอมไพเลอร์ C ++ รู้ที่จะนำเข้า_functionมากกว่า_function_intและทุกอย่างเรียบร้อยดี

มันไม่ใช่ว่าพวกเขา "ไม่สามารถ" พวกเขาไม่ได้โดยทั่วไป

หากคุณต้องการเรียกใช้ฟังก์ชันในไลบรารี C ที่เรียกว่าfoo(int x, const char *y)ไม่เป็นการดีที่จะปล่อยให้คอมไพเลอร์ C ++ ของคุณเข้ามายุ่งfoo_I_cCP()(หรืออะไรก็ตามเพียงแค่สร้างโครงร่างที่ยุ่งเหยิงในจุดที่นี่) เพียงเพราะมันทำได้

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

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

เกิดอะไรขึ้นกับการอนุญาตให้คอมไพเลอร์ C ++ ทำลายฟังก์ชัน C ด้วย

พวกเขาจะไม่เป็นฟังก์ชัน C อีกต่อไป

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

เช่นเดียวกับ C ABI ในระบบของคุณ C ABI บางตัวมีรูปแบบการเปลี่ยนชื่อ (เช่น Visual Studio) ดังนั้นจึงเป็นเรื่องเกี่ยวกับ "การปิดการโกงชื่อ" น้อยกว่าและอื่น ๆ เกี่ยวกับการเปลี่ยนจาก C ++ ABI เป็น C ABI สำหรับฟังก์ชันบางอย่าง เราทำเครื่องหมายฟังก์ชัน C ว่าเป็นฟังก์ชัน C ซึ่งเกี่ยวข้องกับ C ABI (แทนที่จะเป็น C ++ ABI) คำประกาศต้องตรงกับคำจำกัดความ (ไม่ว่าจะเป็นในโปรเจ็กต์เดียวกันหรือในไลบรารีของบุคคลที่สามบางส่วน) มิฉะนั้นการประกาศจะไม่มีจุดหมาย หากไม่มีสิ่งนั้นระบบของคุณก็จะไม่รู้วิธีค้นหา / เรียกใช้ฟังก์ชันเหล่านั้น

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

MSVC ในความเป็นจริงไม่ชื่อ C ฉีกแม้ว่าในแฟชั่นที่เรียบง่าย บางครั้งก็ต่อท้าย@4หรือตัวเลขอื่น ๆ สิ่งนี้เกี่ยวข้องกับการเรียกประชุมและความจำเป็นในการล้างข้อมูลสแต็ก

ดังนั้นหลักฐานจึงมีข้อบกพร่อง

เป็นเรื่องปกติมากที่จะมีโปรแกรมที่เขียนด้วยภาษา C บางส่วนและบางส่วนเขียนด้วยภาษาอื่น (มักเป็นภาษาแอสเซมบลี แต่บางครั้งก็เป็นภาษาปาสคาลฟอร์แทรนหรืออย่างอื่น นอกจากนี้ยังเป็นเรื่องปกติที่โปรแกรมจะมีส่วนประกอบที่แตกต่างกันซึ่งเขียนโดยบุคคลอื่นซึ่งอาจไม่มีซอร์สโค้ดสำหรับทุกอย่าง

บนแพลตฟอร์มส่วนใหญ่มีข้อกำหนด - มักเรียกว่า ABI [Application Binary Interface] ซึ่งอธิบายถึงสิ่งที่คอมไพเลอร์ต้องทำเพื่อสร้างฟังก์ชันที่มีชื่อเฉพาะซึ่งยอมรับอาร์กิวเมนต์ของบางประเภทและส่งคืนค่าของบางประเภทโดยเฉพาะ ในบางกรณี ABI อาจกำหนด "รูปแบบการเรียก" มากกว่าหนึ่ง; คอมไพเลอร์สำหรับระบบดังกล่าวมักจะให้วิธีการระบุว่าควรใช้รูปแบบการเรียกใดสำหรับฟังก์ชันเฉพาะ ตัวอย่างเช่นใน Macintosh กิจวัตรของ Toolbox ส่วนใหญ่จะใช้รูปแบบการเรียก Pascal ดังนั้นต้นแบบของสิ่งต่างๆเช่น "LineTo" จะเป็นดังนี้:

/* Note that there are no underscores before the "pascal" keyword because
   the Toolbox was written in the early 1980s, before the Standard and its
   underscore convention were published */
pascal void LineTo(short x, short y);

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

ฉันจะเพิ่มคำตอบอีกหนึ่งคำตอบเพื่อจัดการกับการสนทนาเชิงสัมผัสที่เกิดขึ้น

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

ในทางตรงกันข้าม Pascal ABI ดั้งเดิมผลักอาร์กิวเมนต์จากซ้ายไปขวาและ callee จะต้องแสดงอาร์กิวเมนต์ C ABI ดั้งเดิมเหนือกว่า Pascal ABI ดั้งเดิมในสองจุดสำคัญ ลำดับการพุชอาร์กิวเมนต์หมายความว่าทราบค่าออฟเซ็ตสแต็กของอาร์กิวเมนต์แรกเสมอโดยอนุญาตให้ฟังก์ชันที่มีอาร์กิวเมนต์ไม่ทราบจำนวนโดยที่อาร์กิวเมนต์แรกจะควบคุมจำนวนอาร์กิวเมนต์อื่น ๆ (ala printf)

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

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

int function(int a)

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

Windows 32 บิตเป็นต้นไปให้ใช้stdcallABI แทน คล้ายกับ Pascal ABI ยกเว้นคำสั่งกดจะเหมือนใน C จากขวาไปซ้าย เช่นเดียวกับ Pascal ABI ชื่อที่ยุ่งเหยิงจะเปลี่ยนขนาดของอาร์กิวเมนต์ไบต์ในชื่อฟังก์ชันเพื่อหลีกเลี่ยงความเสียหายของสแต็ก

ซึ่งแตกต่างจากการอ้างสิทธิ์ที่อื่นที่นี่ C ABI จะไม่ยุ่งเกี่ยวกับชื่อฟังก์ชันแม้แต่ใน Visual Studio ในทางกลับกันฟังก์ชั่นการดัดแปลงที่ตกแต่งด้วยstdcallข้อกำหนด ABI นั้นไม่ซ้ำกับ VS GCC ยังรองรับ ABI นี้แม้ว่าจะคอมไพล์สำหรับ Linux ก็ตาม สิ่งนี้ถูกใช้อย่างกว้างขวางโดยWineซึ่งใช้ตัวโหลดของตัวเองเพื่อให้สามารถเชื่อมโยงเวลาทำงานของไบนารีที่คอมไพล์ของ Linux กับ DLL ที่คอมไพล์ของ Windows

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

C ไม่ต้องการสิ่งนี้เนื่องจากไม่อนุญาตให้มีการทำงานมากเกินไป

โปรดทราบว่าชื่อที่สับสนเป็นเหตุผลหนึ่ง (แต่ไม่ใช่อย่างเดียว!) ที่ไม่สามารถพึ่งพา 'C ++ ABI' ได้

C ++ ต้องการที่จะสามารถทำงานร่วมกับรหัส C ที่เชื่อมโยงกับมันหรือเชื่อมโยงกับ

C คาดหวังชื่อฟังก์ชันที่ไม่มีการเปลี่ยนแปลงชื่อ

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

การผสมผสานชื่อของฟังก์ชัน C และตัวแปรจะทำให้สามารถตรวจสอบประเภทของฟังก์ชันได้ในเวลาลิงก์ ในปัจจุบันการใช้งาน (?) C ทั้งหมดช่วยให้คุณกำหนดตัวแปรในไฟล์หนึ่งและเรียกมันว่าเป็นฟังก์ชันในอีกไฟล์หนึ่ง หรือคุณสามารถประกาศฟังก์ชันด้วยลายเซ็นที่ไม่ถูกต้อง (เช่นvoid fopen(double)แล้วเรียกมันว่า.

ฉันเสนอโครงร่างสำหรับการเชื่อมโยง type-safe ของตัวแปร C และฟังก์ชันผ่านการใช้ mangling ย้อนกลับไปในปี 1991 โครงร่างนี้ไม่เคยถูกนำมาใช้เพราะอย่างที่อื่น ๆ ได้กล่าวไว้ที่นี่สิ่งนี้จะทำลายความเข้ากันได้ย้อนหลัง