Чи стосувалась C ++ 11 адреса проходження об'єктів std lib між динамічними / спільними межами бібліотеки? (т. е. дл і так)?

Однією з моїх головних скарг на C ++ є те, наскільки важко на практиці передавати std бібліотечні об'єкти поза динамічними межами бібліотеки (тобто dll / so).

Бібліотека std часто використовується лише в заголовку. Що чудово підходить для отримання дивовижних оптимізацій. Однак для DLL вони часто будуються з різними налаштуваннями компілятора, які можуть впливати на внутрішню структуру / код контейнерів бібліотеки std. Наприклад, у MSVC один dll може будуватись із налагодженням ітератора, тоді як інший будується з ним. Ці два dll можуть зіткнутися з проблемами, передаючи std-контейнери навколо. Якщо я експоную std::stringв своєму інтерфейсі, я не можу гарантувати, що код, який використовує клієнт, є std::stringточною відповідністю моєї бібліотеки std::string.

Це призводить до важких проблем налагодження, головних болів тощо. Ви або жорстко керуєте налаштуваннями компілятора у вашій організації, щоб запобігти цим проблемам, або використовуєте простіший C-інтерфейс, у якого цих проблем не буде. Або вкажіть для своїх клієнтів очікувані налаштування компілятора, які вони повинні використовувати (що виходить, якщо інша бібліотека визначає інші настройки компілятора).

Моє запитання - чи намагався C ++ 11 зробити щось для вирішення цих питань?

Ви впевнені, що будь-якого STL - насправді, нічого з будь-якої сторонньої бібліотеки, на яку шаблонується - краще уникати в будь-якому публічному API C ++. Ви також хочете дотримуватися довгого списку правил за адресою http://www.ros.org/reps/rep-0009.html#definition для запобігання злому ABI, що робить програмування загальнодоступними API C ++ справжньою справою.

І відповідь щодо C ++ 11 - ні, цей стандарт цього не стосується. Більш цікаво, чому ні? Відповідь тому, що C ++ 17 дуже доторкається до цього, і для реалізації модулів C ++ нам потрібні експортовані шаблони для роботи, і для цього нам потрібен компілятор типу LLVM, такий як clang, який може скинути повний AST на диск, а потім робити підходи, що залежать від виклику, для обробки багатьох випадків, що порушують ODR, у будь-якому великому проекті C ++ - який, до речі, включає багато GCC та код ELF.

Нарешті, я бачу чимало коментарів MSVC до ненависті та коментарів про GCC. Вони дуже дезінформовані - GCC на ELF принципово і безповоротно нездатний створювати дійсний і правильний код C ++. Причин цього багато і легіон, але я швидко наведу один приклад випадку: GCC на ELF не може безпечно створювати розширення Python, написані за допомогою Boost.Python, де більше ніж одне розширення на основі Boost.Python завантажено в Python. Це тому, що ELF зі своєю глобальною таблицею символів C просто не може бути спроектованим, щоб запобігти порушенням ODR, викликаючи segfault, тоді як PE та MachO, і справді запропонована специфікація модулів C ++ використовують усі таблиці символів на модулі - що, до речі, також означає набагато більш швидкий процес упродовж часу. І є ще багато проблем: див. StackOverflow, на який я нещодавно відповівhttps://stackoverflow.com/questions/14268736/symbol-visibility-exceptions-runtime-error/14364055#14364055, наприклад, коли викиди винятків C ++ безповоротно порушуються на ELF.

Останній пункт: що стосується взаємодії різних STL, це є великим болем для багатьох великих корпоративних користувачів, які намагаються змішати сторонні бібліотеки, які тісно інтегровані в деяку реалізацію STL. Єдине рішення - це новий механізм для C ++ для обробки інтеропу STL, і, хоча вони у нього є, ви також можете виправити інтероп компілятора, щоб ви могли (наприклад) змішати MSVC, GCC і кланг-компільовані об’єктні файли, і все це просто працює . Я б спостерігав, як C ++ 17 намагається бачити, що з’явиться в найближчі кілька років - я здивуюсь, якщо нічого не вийде.

У специфікації ніколи не було цієї проблеми. Це тому, що в ньому є концепція під назвою "одне правило визначення", яка передбачає, що кожен символ має точно одне визначення в процесі запуску.

DLL-файли Windows порушують цю вимогу. Тому є всі ці проблеми. Тож Microsoft має це виправити, а не комітет зі стандартизації C ++. У Unix ніколи не було цієї проблеми, тому що спільні бібліотеки там працюють по-різному і за замовчуванням відповідають одному правилу визначення (ви можете явно його порушити, але ви, очевидно, це робите лише якщо знаєте, що можете собі це дозволити і потрібно вичавити кілька додаткових циклів).

DLL-файли Windows порушують одне правило визначення, оскільки:

• Вони вказують жорсткий код, з якого буде використаний символ динамічної бібліотеки протягом статичного часу зв'язку, і розв’язують символи статично в бібліотеці, яка їх визначає. Отже, якщо той самий слабкий символ генерується в декількох спільних бібліотеках і цих бібліотеках, ніж звикнути в одному процесі, динамічний лінкер не має шансів об'єднати ці символи. Зазвичай такі символи є статичними членами або класовими імпедиментами шаблонів шаблонів, і це викликає проблеми при передачі екземплярів між кодом у різних DLL.
• Вони твердо кодують, чи буде імпортовано символ із динамічної бібліотеки вже під час компіляції. Таким чином, код, пов'язаний з деякою бібліотекою статично, несумісний з кодом, динамічно пов'язаним з тією ж бібліотекою.

Unix, використовуючи експорт у форматі ELF, неявно імпортує всі експортовані символи, щоб уникнути першої проблеми та не розрізняє статично та динамічно розв'язані символи до тих пір, поки статичний час зв'язку не уникне другого.

Інше питання - це прапори компілятора. Ця проблема існує для будь-якої програми, що складається з декількох одиниць компіляції, динамічні бібліотеки не повинні бути задіяні. Однак це набагато гірше в Windows. У Unix не дуже важливо, чи ви пов'язуєте статично чи динамічно, ніхто так чи інакше не пов'язує стандартний цикл виконання (в Linux це навіть може бути незаконним), і немає спеціального часу налагодження, тому одна збірка є досить хорошою. Але те, як Microsoft впроваджував статичне та динамічне з'єднання, час налагодження та випуску та деякі інші варіанти, означає, що вони спричинили комбінаторний вибух потрібних варіантів бібліотеки. Знову випуск платформи, а не мова C ++.

Ні.

Проводиться велика робота по заміні заголовкової системи, функція якої називається Модулі і яка може вплинути на це, але, безумовно, не велика.