Чому функції C не можна керувати іменами?

Нещодавно у мене було інтерв'ю, і одне запитання було в чому полягає в застосуванні extern "C"коду C ++. Я відповів, що це використовувати функції C у коді C ++, оскільки C не використовує керування іменами. Мене запитали, чому C не використовує керування іменами, і якщо чесно, я не зміг відповісти.

Я розумію, що коли компілятор C ++ компілює функції, він дає особливу назву функції головним чином, тому що ми можемо перевантажувати функції одного і того ж імені в C ++, які повинні бути вирішені під час компіляції. У C ім'я функції залишиться незмінним або, можливо, з _ перед ним.

Мій запит: що поганого в тому, щоб дозволити компілятору C ++ також маніпулювати функціями C? Я б припустив, що не має значення, які імена дає їм компілятор. Функції ми називаємо однаково в C і C ++.

На це було свого роду відповідь, але я постараюся поставити речі в контекст.

По-перше, С прийшов першим. Таким чином, те, що робить C - це, начебто, "за замовчуванням". Він не манить імена, тому що це просто не так. Ім'я функції - це ім'я функції. Глобал - це глобальний тощо.

Потім прийшов C ++. C ++ хотів мати можливість використовувати той же лінкер, що і C, і мати можливість зв’язатися з кодом, написаним на C. Але C ++ не міг залишити C "маніпулювання" (або його відсутність), як є. Перегляньте наступний приклад:

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

У C ++ це окремі функції, з чіткими тілами. Якщо жоден з них не буде заблокований, обидва будуть називатися "функція" (або "_функція"), і лінкер поскаржиться на перезначення символу. Рішенням C ++ було вписати типи аргументів у ім'я функції. Отже, одне викликається, _function_intа інше викликається _function_void(не реальна схема керування), а зіткнення уникається.

Тепер у нас залишилася проблема. Якщо це int function(int a)було визначено в модулі C, і ми просто беремо його заголовок (тобто декларацію) у код 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.

Функція - це не просто підпис і визначення; як функціонує функція, багато в чому визначається такими факторами, як виклик конвенції. "Бінарний інтерфейс програми", визначений для використання на вашій платформі, описує, як системи спілкуються один з одним. Використовувана вашою системою AB + C ++ визначає схему керування іменами, щоб програми в цій системі знали, як викликати функції в бібліотеках тощо. (Прочитайте відмінний приклад C ++ Itanium ABI. Ви дуже швидко зрозумієте, для чого це потрібно.)

Те саме стосується і C ABI у вашій системі. Деякі C ABI насправді мають схему керування іменами (наприклад, Visual Studio), тому мова йде менше про "вимкнення керування іменами" та більше про перехід з C ++ ABI на C ABI для певних функцій. Позначимо функції C як функції C, до яких відноситься C ABI (а не C ++ ABI). Декларація повинна відповідати визначенню (будь то в тому ж проекті або в якійсь сторонній бібліотеці), інакше декларація є безглуздою. Без цього ваша система просто не знатиме, як знайти / викликати ці функції.

Що стосується того, чому платформи не визначають CI і C ++ ABI як однакові та позбавляються від цієї "проблеми", це частково історично - оригінальні C ABI були недостатніми для C ++, у якому є простори імен, класи та перевантаження оператора. з яких потрібно якось представити ім'я символу в зручному для комп’ютера способі - але можна також стверджувати, що дотримання програм C сьогодні, дотримуючись C ++, є несправедливим для спільноти C, що повинно було б миритися з значно складнішими ABI лише заради деяких інших людей, які хочуть сумісності.

MSVC насправді має назву mangle C, хоча просто. Іноді додається @4чи інша невелика кількість. Це стосується умовних вимог і необхідності очищення стека.

Отже, приміщення просто недосконале.

Дуже часто зустрічаються програми, які частково написані на C, а частково написані якоюсь іншою мовою (часто мова асемблера, але іноді Pascal, FORTRAN чи щось інше). Також звичайно, щоб програми містили різні компоненти, написані різними людьми, які можуть не мати вихідного коду для всього.

На більшості платформ є специфікація - часто її називають ABI [Application Binary Interface], яка описує, що повинен робити компілятор, щоб створити функцію з певним іменем, яка приймає аргументи певних типів і повертає значення певного типу. У деяких випадках ABI може визначати кілька "конвенцій, що викликають"; компілятори для таких систем часто надають засоби вказівки, яка умова виклику повинна використовуватися для певної функції. Наприклад, на Macintosh більшість підпрограм Toolbox використовують конвенцію виклику Паскаля, тому прототип для чогось типу "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 ABI (двійковий інтерфейс програми) спочатку закликав передавати аргументи на стеку у зворотному порядку (тобто - натисканням справа наліво), де абонент також звільняє сховище стека. Сучасний ABI фактично використовує регістри для передачі аргументів, але багато міркувань щодо керування повертаються до передачі цього оригінального аргументу стека.

Оригінальний Pascal ABI, навпаки, відсунув аргументи зліва направо, і виклик повинен був викласти аргументи. Оригінальний C ABI перевершує оригінальний Pascal ABI у двох важливих моментах. Порядок поштовху аргументів означає, що зміщення стеку першого аргументу завжди відомо, дозволяючи функціям, які мають невідому кількість аргументів, де ранні аргументи контролюють, скільки інших аргументів є (алаprintf ).

Другий спосіб перевершити C ABI - це поведінка у випадку, якщо абонент та позивач не погоджуються щодо кількості аргументів. У випадку С, якщо ви фактично не отримаєте доступ до аргументів минулого, нічого поганого не відбувається. У Паскалі неправильна кількість аргументів вискакує зі стека, і вся стека зіпсована.

Оригінальний Windows 3.1 ABI був заснований на Pascal. Як такий, він використовував Паскаль ABI (аргументи в лівому та правому порядку, виклику виклику). Оскільки будь-яка невідповідність аргументації може призвести до корупції, склалася схема керування. Кожне ім'я функції було змінено числом, що вказує на розмір, в байтах, його аргументів. Отже, на 16-бітній машині функція (синтаксис C):

int function(int a)

Був розіграний function@2, бо intшириною два байти. Це було зроблено для того, що якщо невідповідність декларації та визначення, лінкер не зможе знайти функцію, а не пошкодить стек під час виконання. І навпаки, якщо програма посилається, то ви можете бути впевнені, що правильна кількість байтів вискакує зі стека в кінці дзвінка.

32-бітний Windows і далі використовуйте stdcallABI. Він схожий на Pascal ABI, за винятком того, що порядок натискань є як у C, справа наліво. Як і ABC Pascal, ім'я mangling змінює розмір байту аргументів у ім'я функції, щоб уникнути пошкодження стека.

На відміну від претензій, викладених деінде тут, C ABI не манить назви функцій навіть у Visual Studio. І навпаки, функції керування, прикрашені stdcallспецифікацією ABI, не властиві лише VS. GCC також підтримує цей ABI, навіть при компіляції для Linux. Це широко використовується Wine , що використовує власний завантажувач, щоб дозволити час запуску ліній компільованих бінарних файлів Linux до компільованих DLL файлів Windows.

Компілятори C ++ використовують керування іменами, щоб дозволити унікальні імена символів для перевантажених функцій, підпис яких інакше був би однаковим. Він в основному кодує і типи аргументів, що дозволяє здійснювати поліморфізм на функціональному рівні.

C цього не вимагає, оскільки не допускає перевантаження функцій.

Зауважте, що керування іменами є однією (але, безумовно, не єдиною!) Причиною того, що не можна покладатися на "C ++ ABI".

C ++ хоче мати можливість взаємодіяти з кодом C, який посилається на нього, або проти якого він посилається.

C очікує імен функцій, не керованих іменами.

Якщо C ++ керував ним, він не знайде експортовані некеровані функції з C, або C не знайде експортовані функції C ++. C-лінкер повинен отримати ім'я, яке він очікує сам, оскільки не знає, що він надходить або переходить на C ++.

Змінення імен функцій C та змінних дозволить перевірити їх типи в час зв'язку. В даний час всі (?) Реалізації C дозволяють визначити змінну в одному файлі та викликати її як функцію в іншому. Або ви можете оголосити функцію неправильним підписом (наприклад, void fopen(double)а потім викликати її.

Я запропонував схему для безпечного типу взаємозв'язку змінних та функцій C за допомогою використання mangling ще в 1991 році. Ця схема так і не була прийнята, оскільки, як зазначали інші, це знищило б сумісність.