В большинстве случаев, чем больше у вас выбор, тем лучше. Однако слишком большое количество библиотек времени выполнения приводит к различным проблемам. Главной проблемой является гарантия того, что все компоненты приложения — статические библиотеки, динамические библиотеки и исполняемые файлы — используют один и тот же вариант библиотеки времени выполнения, Если это не так, то приложение может не скомпоноваться или в нем могут появиться сложные с точки зрения диагностики сбои.
При использовании библиотек, разработанных другими, у вас не будет возможности выбрать библиотеки времени выполнения. В таких случаях вы будете вынуждены использовать в одном приложении несколько вариантов библиотек времени выполнения.
Итак, как же решить, какую библиотеку времени выполнения использовать? Два выбора — одно- или многопоточную и отладочную или окончательную — вполне очевидны.
Если проект использует несколько потоков или зависит от многопоточных библиотек, вы должны выбрать многопоточный вариант библиотеки времени выполнения (если такой имеется в поставке инструментария). Если библиотека времени выполнения была собрана без поддержки многопоточности, то вызов ее функций из нескольких потоков может привести к непредсказуемому поведению программы. Аналогично при создании отладочной сборки следует использовать отладочный вариант библиотеки времени выполнения (если он имеется).
Последний выбор — следует использовать статическую или динамическую библиотеку времени выполнения — более сложен. Использование статической библиотеки имеет несколько преимуществ. Во-первых, благодаря тому, что в приложение включаются только функции, реально используемые приложением, она может уменьшить суммарный размер дистрибутива программы, исключив необходимость распространять динамическую библиотеку времени выполнения. (Однако если известно, что динамическая библиотека в целевой системе уже имеется, компоновка со статической библиотекой сделает дистрибутив больше по размеру.) Во-вторых, при компоновке со статической библиотекой устраняется проблема версий библиотек, которая возникает, когда в системе присутствует несколько версий одной и той же динамической библиотеки.
Однако компоновка с динамической библиотекой времени выполнения также имеет свои преимущества. В первую очередь благодаря тому, что очень эффективным средством организации приложения является создание набора динамических библиотек. Во-первых, это позволяет обновлять части приложения, не требуя переустановки всего приложения. Далее, в некоторых случаях, благодаря использованию возможности отложенной загрузки DLL в Windows, значительно увеличивается производительность приложения. Но так как все компоненты приложения должны использовать один и тот же вариант библиотеки времени выполнения, то если приложение использует хотя бы одну динамическую библиотеку, все компоненты этого приложения должны использовать динамическую библиотеку времени выполнения. В результате использование динамической библиотеки времени выполнения облегчает разбиение приложения на модули.
Я рекомендую в большинстве случаев выбирать динамическую компоновку. Однако, как я упоминал выше, иногда предпочтительнее статическая компоновка. Иногда, когда неизвестно, как будет использоваться написанная библиотека, невозможно узнать заранее, какой тип компоновки предпочтительнее. В этом случае общим решением является создание нескольких вариантов библиотеки, скомпонованных с использованием различных вариантов библиотеки времени выполнения.
Смотри также
Рецепты 1.4, 1.5, 1.21 и 1.25.
1.24. Включение строгого соответствия стандарту C++
Проблема
Вы хотите, чтобы компилятор принимал только программы, которые соответствуют стандарту языка С++.
Решение
Опции командной строки для указания строгого соответствия стандарту C++ приведены в табл. 1.37. Инструкции для включения строгого соответствия в IDE приведены в табл. 1.38
Некоторые из показанных в табл. 1.6 опций компиляторов могут рассматриваться как опции соответствия. Примерами являются опции для включения основных языковых функций, таких как поддержка «широких» символов, исключений и информации о типе во время выполнения. В табл. 1.37 они не приведены.
Табл. 1.37. Включение строгого соответствия из командной строки
Инструментарий Опции командной строки компилятора GCC
-ansi -pedantic-errors Visual C++
-Za Intel (Windows)
-Za -Qms0 Intel (Linux)
-strict-ansi¹ Metrowerks
-ansi strict -iso_templates on -msext off Comeau (Windows)
-A Comeau (Unix)
-strict or -A Borland
-A² Digital Mars
-A¹ Версии компилятора Intel для Linux до 9.0 использовали опцию -strict_ansi. При использовании -strict-ansi или -strict_ansi может потребоваться с помощью опции -cxxlib-icc включить стандартную библиотеку Intel
² С опцией -А некоторые стандартные заголовочные файлы библиотеки STLPort могут не компилироваться.
Табл. 1.38. Включение строгого соответствия в IDE
IDE Конфигурация Visual C++ На страницах свойств проекта перейдите к Configuration Properties→C/C++→Language и установите в значение Yes (Да) опции Disable Language Extensions (Отключить расширения языка), Treat wchar_t as Built-in Type (Рассматривать wchar_t как встроенный тип) и Force Conformance in For Loop Scopes (Включить соответствие стандарту в циклах For) Metrowerks В окне Target Settings перейдите к Language Settings→C/C++ Language и установите ISO Template Parser (Синтаксический анализ шаблонов ISO), ANSI Strict (Строгий ANSI) и ANSI Keywords Only (Только ключевые слева ANSI). Убедитесь, что выбраны опции Enable C++ Exceptions (Включить исключений С++). Enable RTTI support (Включить поддержку RTTI). Enable bool Support (Включить поддержку bool) и Enable wchar_t Support (Включить поддержку wchar_t) C++Builder В Project Options перейдите к Advanced Compiler и в разделе Language Compliance (Соответствие языка) установите ANSI Dev-C++ См запись для GCC в табл. 1 37 и обратитесь к рецепту 1.20 Обсуждение
Язык C++ был стандартизирован Международной организацией по стандартизации (International Standards Organization — ISO) в 1998 году. В том же году стандарт ISO был одобрен и принят Национальным институтом стандартизации США (American National Standards Institute — ANSI). В 2003 году была одобрена вторая редакция стандарта, которая содержит исправления и пояснения, но также вводит несколько новых языковых возможностей. В настоящее время ведется работа над обновленной версией стандарта С++, которая будет включать несколько важных языковых функций и расширенную стандартную библиотеку.
В момент принятия стандарта в 1998 году ни один из компиляторов не достигал полного соответствия его требованиям, хотя многие были представлены как «ANSI-совместимые». Однако в течение нескольких прошедших лет поставщики много работали над тем, чтобы сделать свои инструменты более точно и строго соответствующими стандарту. По состоянию на сентябрь 2005 года последние версии компиляторов GNU, Microsoft, Intel, Metrowerks и Comeau обладают высокой степенью соответствия. Comeau и Intel с их поддержкой экспорта шаблонов могут рассматриваться как соответствующие стандарту почти на 100%[5].
Ни один из компиляторов не может обеспечить полного соответствия стандарту с точки зрения отказа компилировать любую неверную программу. И не только из-за того, что ни один из них не соответствует стандарту на 100%: более важной причиной является то, что стандарт C++ не требует от компилятора отвергать неверные программы. Имеется четкий перечень обстоятельств, в которых компилятор должен выдавать диагностическое сообщение, указывающее на неправильно написанную программу, однако для многих некорректных программ диагностики не требуется. Это программы, которые приводят к тому, что стандарт называет неопределенным поведением программы при ее выполнении. И даже тогда, когда диагностика обязательна, компилятор волен выдать сообщение и продолжить компиляцию, в результате которой возможно успешное создание исполняемого файла или библиотеки.
