Преимущества совместно используемого времени выполнения C++

При упаковке стандартной библиотеки C++, поскольку динамическая совместно используемая библиотека важна для обеспечения производительности и правильности программы. Если Ваша исполнимая программа соединяется с libstdc++.a и к нескольким динамическим совместно используемым библиотекам, и один или большему количеству тех совместно используемых библиотек также соединяется с libstdc++.a, тогда многократные копии библиотеки загружаются в память во время выполнения.

Для правильности все компоненты программы должны использовать ту же самую копию стандартной библиотеки C++. Причина состоит в том, что некоторые данные во время выполнения C++ должны быть совместно использованы всеми компонентами, или могут произойти неожиданные результаты. Например, если два компонента оба используют C++ механизм I/O для записи в стандартный вывод, результаты могут стать искаженными, если они используют различные буферы.

Для производительности наличие многократных копий той же библиотеки приводит к увеличенной активности диска, как каждая копия читается в память. Дополнительные копии могут также привести к увеличенной разбивке на страницы и неудачным обращениям в кэш вследствие увеличенного объема потребляемой памяти приложения. Устранение дублированных библиотек может сократить место Вашего приложения существенно. Например, считайте следующий “привет мировой” программой скомпилированный с libstdc++.a и GCC 3.3:

int main ()

{

    std::cout << "Hello, World!\n" << std::endl;

    return 0;

}

Размер получающегося двоичного файла на OS X v10.4 система составляет 650 КБ. Та же программа, скомпилированная в той же системе с помощью GCC 4.0 и libstdc++.dylib 17 КБ.

Совместимость на уровне двоичных кодов

GCC 4.0 приспосабливает C++ Itanium ABI, который является стандартом для скомпилированного кода C++. Спецификации для этого стандарта сохраняются консорциумом разных производителей и охватывают проблемы, такие как искажение имени, задействованное расположение класса, виртуальные протоколы вызова метода, обработка исключений и информация о типах во время выполнения (RTTI) форматы. Можно найти последнюю версию этой спецификации в http://www .codesourcery.com/cxx-abi/abi.html.

Поскольку GCC 4.0 приспосабливает C++ Itanium ABI, объекты C++ совместимы со ссылкой с объектами, созданными другими компиляторами OS X, соответствующими этой спецификации. Apple гарантирует, что будущие выпуски GCC для OS X также приспособят C++ Itanium ABI. Это означает, что разработчики могут безопасно поставить динамические совместно используемые библиотеки, интерфейсы которых включают классы C++, хотя с некоторыми протестами:

• Apple гарантирует устойчивость ABI только для функций базового языка. Это не гарантирует устойчивости для классов библиотеки, включая std::string, std::map<T>, и std::ostream среди других.

• Apple не гарантирует совместимости на уровне двоичных кодов между различными основными версиями libstdc++. GCC 4.0 поставляет с версией 6.0.3 библиотеки. Если новая основная версия (версия 7.0.0) будет выпущена в будущем, то та библиотека, как гарантируют, не будет совместима с 6.x версии.

• Совместимость на уровне двоичных кодов между различными версиями сторонней динамической совместно используемой библиотеки также зависит от проекта библиотеки, не только на поддержке компилятора стандартного ABI. Необходимо гарантировать, чтобы Вы не представляли проблемы совместимости.

При разработке динамической совместно используемой библиотеки для распределения это - все еще ответственность гарантировать, чтобы Вы не создавали проблемы совместимости на уровне двоичных кодов. Например, Вы не должны представлять задействованные переменные или виртуальные методы к базовому классу. Выполнение так вызывает проблему хрупкого базового класса и требует, чтобы были перекомпилированы клиенты библиотеки.

Для получения дополнительной информации о совместимости на уровне двоичных кодов посмотрите Создающие Совместимые Библиотеки.