Можно ли скомпилировать библиотеку C ++ 11 (lib, dll и т. Д.) В более старых компиляторах C ++?

Могут ли старые компиляторы C ++ (например, VS2008 и gcc3.4) связываться с внешними библиотеками, написанными на C ++ 11?

Я думаю, что файлы .lib C ++ 11 на данном этапе являются просто байтовым кодом, и он не должен беспокоить старые компиляторы, как он был сгенерирован, если он каким-то образом разрешаем и вызывается.

Я разрабатываю небольшую библиотеку, API которой все еще должен поддерживать пользователей C ++ 03. Итак, с нетерпением жду, я задаюсь вопросом, нормально ли реализовать мою библиотеку, используя такие полезные функции, как std::unique_ptrи тому подобное, или мне просто нужно придерживаться boost::?

При условии, что ваша библиотека использует только C ++ 11 в своей реализации и не раскрывает средства или типы C ++ 11 публично, особенно если вы используете статическую связь, тогда да, это возможно и даже стандартно.

Рассмотрим распространенный случай, когда библиотека предоставляет интерфейс уровня C (который может использоваться самыми разными клиентами), но который реализован внутри C ++. Клиентам, которые ссылаются на такую ​​библиотеку, нужно беспокоиться только об общедоступном двоичном API (экспортируемых функциях), который вы должны использовать как устаревший C / C ++ для максимальной совместимости. Java-программа может ссылаться на API уровня C, которые внутренне реализованы на C ++. Это не означает, что Java должна «поддерживать C ++». Точно так же клиент C / C ++ старого стиля может ссылаться на API уровня C или уровня C ++, который внутренне использует более авангардную версию библиотек C ++ или любых других библиотек. Две отдельные вещи: что требуется для связи с интерфейсом библиотеки, и что внутренняя ссылка на библиотеку (или статическая загрузка).

Вы просто не подвергаете клиентов вашей библиотеки зависимостям вашей реализации.

Если вы можете статически связать свои зависимости (C ++ 11 или что-то еще) с вашей библиотекой, это чисто и автономно. Библиотека - это настоящий черный ящик: ничего, кроме байт-кода. Но даже если ваша библиотека связывается с вашими зависимостями через «неявную динамическую» связь (не путать с типом explicity LoadLibrary / GetProcAddress и аналогичными методами в * nix и OS X), старые клиенты все равно должны иметь возможность ссылаться на эту библиотеку. общедоступный интерфейс, даже если они не могут ссылаться на библиотеки, от которых зависит библиотека .

Похоже, вы хотите написать новую библиотеку для использования другими, и что вы хотели бы использовать C + 11 в качестве языка реализации. Есть ряд вопросов для рассмотрения:

• представив новую версию C ++, вы обнаружите необходимость развертывания новых библиотек времени выполнения C ++ вместе с вашей библиотекой, это нормально?
• Вы не должны использовать новые типы C + 11 в вашем публичном интерфейсе, иначе они не смогут вызывать его.
• В общем, вам следует избегать сложных типов, таких как unique_ptr, даже vector и т. Д. Если вы не распространяете свою библиотеку в качестве исходного кода, компоновка объектов в вашей библиотеке может отличаться от компоновки в коде клиента. Придерживайтесь простых типов, которые не имеют риска изменения макета объекта.