C++. Сборник рецептов - [45]
>// ВНИМАНИЕ: некорректный код!
>int main() {
> for (int i = 0; i < 10; ++i)
> ;
> int j = i; // j == 10
>}
Стандартом это не допускается и не имеет никаких преимуществ по сравнению со стандартными правилами областей видимости. Требование компилировать код, подобный этому, возникает только при сопровождении устаревших приложений.
Другой категорией некорректного кода является код, который использует экспериментальные расширения языка, которые по какой-либо причине не вошли в конечный стандарт C++. Например, многие компиляторы предоставляют встроенный тип >long long, длина которого гарантированно имеет не менее 64 бит. Как еще один пример, некоторые компиляторы предоставляют встроенный оператор >typeof, имеющий такой же синтаксис, как и оператор >sizeof, и возвращающий тип выражения. Обе эти функции, скорее всего, появятся в следующей версии стандарта C++, хотя ожидается, что написание >typeof изменится на, возможно, >decltype.
Будьте осторожны при использовании подобного рода расширений: вы можете столкнуться с тем, что вам потребуется портировать код на платформу, не реализующую какого-либо расширения или реализующую его по-другому.
Третья категория некорректного кода — это код, который использует платформенно-зависимые расширения языка, необходимые для использования функций операционной системы. В эту категорию попадают атрибуты >__declspec(dllexport) и >__declspec(dllimport), используемые для сборки динамических библиотек в Windows, и атрибуты >__stdcall, >__fastcall и >__cdecl, представляющие соглашения о вызовах в Windows. Хотя это и расширения языка, большая часть компиляторов для Windows принимает код, содержащий эти расширения, даже если используется опция строгого соответствия стандарту.
Последней категорией некорректного кода является код, нарушающий стандарт С++, но полностью соответствующий некоторым другим стандартам. Главным примером такого стандарта является C++/CLI, который сейчас проходит последние стадии стандартизации в ECMA. C++/CLI — это расширение С++, которое состоит из интерфейса C++ к Command Language Infrastructure — ядру Microsoft .NET Framework. При компиляции приложения, использующего определенные расширения C++/CLI, соответствующий стандарту компилятор C++ должен выдавать диагностику, но при поддержке стандарта C++/CLI он может свободно генерировать работоспособное приложение.
Если вам требуется скомпилировать код, не соответствующий стандарту, вначале проверьте, будет ли он компилироваться при использовании опций, приведенных в табл. 1.37 и 138. Если нет, то некоторые компиляторы предлагают набор «дробных» опций совместимости, позволяющих использовать некоторые несовместимые конструкции, но запрещающих другие. Например, Comeau предоставляет опцию --long_long, указывающую на необходимость распознавания типа >long long. Наконец, некоторые компиляторы предоставляют опции, заставляющие их сообщать о большинстве нарушений стандарта как о предупреждениях, а не ошибках. Например, GCC для этой цели предоставляет опцию -pedantic, a Comeau для Windows предоставляет опцию --a, а для других платформ — опции --strict_warnings или -a.
Рецепт 1.2.
1.25. Указание определенной библиотеки для автоматической компоновки с исходным файлом
Вы написали библиотеку, которую хотите распространять в виде набора заголовочных файлов и готовых статических или динамических библиотек, но не хотите, чтобы пользователи вашей библиотеки должны были сами указывать имена библиотек при компоновке приложений.
При программировании для Windows с использованием инструментария Visual C++, Intel, Metrowerks, Borland или Digital Mars для указания имен и (при необходимости) путей готовых библиотек, с которыми должен компоноваться код, включающий заголовочные файлы вашей библиотеки, используйте в этих заголовочных файлах >pragma comment.
Например, предположим, что вы хотите распространить библиотеку из примера 1.1, состоящую из статической библиотеки libjohnpaul.lib и заголовочного файла johnpaul.hpp. Измените этот заголовочный файл так, как показано в примере 1.26.
Пример 1.26. Использование pragma comment
>#ifndef JОНNPAUL_HPP_INCLUDED
>#define JOHNPAUL_HPP_INCLUDED
>#pragma comment(lib, "libjohnpaul")
>void johnpaul();
>#endif // JOHNPAUL_HPP_INCLUDED
После этого изменения компоновщики Visual С++, Intel, Metrowerks, Borland и Digital Mars при компоновке кода, включающего заголовочный файл johnpaul.hpp, будут автоматически находить библиотеку libjohnpaul.lib.
В некоторых ситуациях компоновка может оказаться более сложным этапом процесса сборки, чем компиляция. Одна из наиболее часто возникающих проблем компоновки создается тогда, когда компоновщик находит неверную версию какой-либо библиотеки. Это в основном проблема Windows, где библиотеки времени выполнения и зависящие ar них библиотеки часто имеют множество вариантов. По этой причине библиотеки для Windows часто поставляются с именами, измененными так, чтобы они отражали различные конфигурации сборки. Хотя это и помогает снизить число конфликтов версий, это также затрудняет процесс компоновки, так как теперь вы должны указывать компоновщику правильное измененное имя.
