Д. Стефенс - C++. Сборник рецептов Страница 2

Наиболее важными людьми, которых я хочу поблагодарить, являются моя жена Дафна (Daphne) и мои дети Джесс (Jesse), Паскаль (Pascal) и Хлоя (Chloe). Написание книги это тяжелый труд, но еще важнее, что он отнимает много времени, и моя семья поддерживала меня и стойко терпела мою работу допоздна.

Я также благодарю технических редакторов, сделавших эту книгу лучше, чем она могла бы быть. Как и во многих других случаях, всегда полезно иметь вторую, третью и четвертую пару глаз, которые оценят ясность изложения и его правильность. Большое спасибо Дэну Саксу (Dan Saks), Уве Шниткер (Uwe Schnitker) и Дэвиду Тизу (David Theese).

Наконец, я должен поблагодарить моего редактора Джонатана Генника (Jonathan Gennick) за его всегда полезные советы по вопросам грамматики, стиля изложения и за философскую поддержку.

Я хочу поблагодарить Криса Ангера (Kris Unger), Джонатана Турканиса (Jonathan Turkanis), Джонатана Генника (Jonathan Gennick) и Райана Стивенса (Ryan Stephens) за их полезные предложения и критику, которые помогли мне писать лучше, чем я мог. Отдельное большое спасибо моей жене Мелани Карбонно (Melanie Charbonneau) за то, что она сделала мою жизнь светлее.

Так как мои главы затрагивают так много различных коммерческих продуктов и проектов с открытыми кодами и по каждому из них у меня было так много вопросов, мой список благодарностей необычно велик.

Во-первых, позвольте мне поблагодарить Рона Лихти (Ron Liechty), Говарда Хиннанта (Howard Hinnant) и инженеров в Metrowerks за их ответы на все мои вопросы и предоставление мне нескольких версий CodeWarrior.

Также я хочу поблагодарить разработчиков Boost.Build, особенно Владимира Пруса (Vladimir Prus), Рене Ривера (Rene Rivera) и Девида Абрамса (David Abrahams) — не только за ответы на мои вопросы, но также и за сборку системы компиляции Boost, которая сама по себе стала наиболее важным источником информации в главе 1.

Кроме того, спасибо Вальтеру Брайту (Walter Bright) из Digital Mars; Грегу Комю (Greg Comeau) из Comeau Computing; Пи Джей Плагеру (Р. J. Plauger) из Dinkumware; Колину Лапласу (Colin Laplace) из Bloodshed Software; Эду Малрою (Ed Mulroy) и Павлу Возенилеку (Pavel Vozenilek) из группы новостей borland.public.*; Арноду Дебене (Arnaud Debaene) и Игорю Тандетнику (Igor Tandetnik) из microsoft.public.vc.languages; Эрни Бойду (Earnie Boyd), Грегу Чикаресу (Greg Chicares), Адибу Тарабену (Adib Taraben), Джону Ванденбергу (John Vandenberg) и Леннарту Боргману (Lennart Borgman) из списка рассылки MinGW/MSYS; Кристоферу Фейлору (Christopher Faylor), Ларри Холлу (Larry Hall), Игорю Петчански (Igor Pechtchanski), Джошуа Даниелю Франклину (Joshua Daniel Franklin) и Дэйву Корну (Dave Korn) из списка Cygwin; Майку Стампу (Mike Stump) и Джефри Китингу (Geoffrey Keating) из списка разработчиков GCC; Марку Гудхенду (Mark Goodhand) из DecisionSoft и Дэвиду Н. Бертони (David N. Bertoni) из apache.org.

Я также в долгу перед Робертом Мекленбургом (Robert Mecklenburg), чье третье издание книги Managing Projects with GNU make (O'Reilly) дало основу моему знакомству с GNU make.

Кроме того, Владимир Прус (Vladimir Prus), Мэтью Вилсон (Matthew Wilson), Райан Стивенc (Ryan Stephens) и Кристофер Диггинс (Christopher Diggins) выполнили подробный анализ ранних черновиков моих текстов.

Наконец, я должен поблагодарить моего редактора Джонатана Генника (Jonathan Gennick), мою жену Дженнифер (Jennifer) и моего деда Луиса С. Гудмэна (Louis S. Goodman), научившего меня писать.

Глава 1

Сборка приложений на C++

1.0. Введение в сборку

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

Если посмотреть на названия рецептов в этой главе, то можно получить впечатление, что я снова и снова решаю одни и те же проблемы. И это будет правильно. Это происходит потому, что имеется большое количество способов сборки приложений С++, и хотя я не могу описать их все, я пытаюсь описать несколько наиболее важных методов. В первой десятке рецептов я показываю, как различными методами выполнять три базовые задачи - собирать статические библиотеки, собирать динамические библиотеки и собирать исполняемые файлы. Рецепты сгруппированы по методам; сначала я рассматриваю сборку из командной строки, затем с помощью системы Boost (Boost.Build), затем с помощью интегрированной среды разработчика (Integrated Development Environment (IDE), и наконец, с помощью GNU make.

Прежде чем вы начнете читать рецепты, обязательно прочтите следующие вводные разделы. Я объясню некоторую базовую терминологию, дам обзор инструментов командной строки, систем сборки и IDE, описываемых в этой главе, и покажу примеры исходного кода.

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

Три базовых инструмента, используемых для сборки приложений С++, — это компилятор, компоновщик и архиватор (или библиотекарь). Набор этих программ и, возможно, других инструментов называется инструментарием.

Компилятор принимает на входе исходные файлы на C++ и создает объектные файлы, которые содержат смесь исполняемого машинного кода и символьных ссылок на функции и данные. Архиватор на входе принимает набор объектных файлов и создает статическую библиотеку, или архив, который просто является подборкой объектных файлов, собранных для удобства использования вместе. Компоновщик принимает на входе набор объектных файлов и библиотек и разрешает их символьные ссылки, создавая либо исполняемый файл, либо динамическую библиотеку. Грубо говоря, компоновщик выполняет работу по сопоставлению каждого использования символа с его определением. Когда создается исполняемый файл или динамическая библиотека, то говорят, что они компонуются (линкуются) используемые при их построении библиотеки называются прилинкованными.

Исполняемый файл, или приложение, — это просто любая программа, которая может выполняться операционной системой. Динамическая библиотека, также называемая совместно используемой библиотекой, похожа на исполняемый файл, за исключением того, что она не может исполняться самостоятельно. Она состоит из тела машинного кода, которое загружается в память после запуска приложения, и может использоваться одним или несколькими приложениями. В Windows динамические библиотеки также называются динамически подключаемыми библиотеками (dynamic link libraries (DLL)).

Объектные файлы и статические библиотеки, от которых зависит исполняемый файл, требуются только при сборке исполняемого файла. Однако динамические библиотеки, от которых зависит исполняемый файл, должны иметься в системе пользователя при запуске исполняемого файла.

Таблица 1.1 приводит расширения файлов, обычно связанные с этими четырьмя базовыми типами файлов в Microsoft Windows и Unix. Когда я упоминаю файл, имеющий в Windows и Unix различные расширения, я иногда опускаю расширение, если оно ясно из контекста.

Табл. 1.1. Расширения файлов в Windows и Unix

В этой главе, когда я говорю Unix, я также имею в виду и Linux.

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

Компилятор, компоновщик и архиватор — это инструменты командной строки, что означает, что они предназначены для запуска из оболочки, такой как bash в Unix или cmd.exe в Microsoft Windows. Имена входных и выходных файлов, а также вся остальная необходимая настроечная информация передаются в компилятор, компоновщик и архиватор как текст в командной строке. Однако вызов этих команд вручную довольно утомителен. Даже для небольших проектов может быть сложно запомнить параметры командной строки для каждого инструмента и порядок, в котором исходные и двоичный файлы проекта должны компилироваться и компоноваться. При изменении одного исходного файла вы должны определить, какие объектные файлы требуется перекомпилировать, какие статические библиотеки требуется обновить и какие исполняемые файлы или динамические библиотеки требуется перекомпоновать. Если вы пересоберете больше файлов, чем требуется, вы зря потратите время, а если пересоберете не все требуемые, то получите ошибки при сборке или неработоспособное приложение. В случае больших проектов на С++, которые могут включать тысячи отдельных файлов, включая исходные файлы, объектные файлы, библиотеки и исполняемые файлы, сборка из командной строки просто невозможна.