Д. Вандевурд, Н.М. Джосаттис - Шаблоны C++. Справочник разработчика (2003) (1160769), страница 34
Текст из файла (страница 34)
Теоретически жадное инстанцирование обладает некоторыми серьезными недостат. ками, перечисленными ниже. ° Компилятор может потратить время на генерирование и оптимизацию множест~~ инстанцирований, нз которых будет использоваться только одно. ° Обычно компоновщики не проверяют идентичность двух инстанцнрований, та" как код, сгенерированный для разных экземпляров одной и той же специализации шаблона, может незначительно варьироваться, что вполне допустимо. Нельзя до [0.4. Схемы реализации пустить, чтобы из-за этих небольших различий в работе компоновщика произошел сбой.
(Причиной этих различий могут быть несущественные расхождения в состоянии компилятора в моменты инстанцировання.) Однако часто это приводит к тому, что компоновщик не замечает более существенных различий, например когда одно из инстанцирований скомпилировано с максимальной оптимизацией, а другое — с максимальной отладочной информацией. ° Потенциально объем всех объектных файлов может существенно превысить их объем при использовании иного подхода, поскольку один и тот же фрагмент кода дублируется несколько раз. На практике оказывается, что зти недостатки не создают особых проблем. Возможно, так получается благодаря тому, что жадное инстанцирование очень выгодно отличается от альтернативных подходов: оно сохраняет традиционную зависимость от исходного кода. В частности, из одной единицы трансляции генерируется только один объектный файл, и каждый объектный файл содержит скомпилированный код всех подлежащих компоновке определений из соответствующего исходного файла (включая инстанцированные определения).
Наконец, стоит заметить, что механизм компоновки, позволяющий дублировать определения компонуемых элементов, обычно используется для обработки дублируемых встраиваемых функций и таблиц диспетчеризации виртуальных функций . Если этот 9 .ю механизм недоступен, в качестве альтернативы эти элементы обычно генерируются с внутренним связыванием, но это приводит к увеличению объема генерируемого кода. 10.4.2. Инстанцнрованне по запросу В этой категории наиболее популярна реализация, представленная компанией Бил М!- сгояуягеии, начиная с версии 4.0 компилятора С++ этой компании. Концептуально инстанцирование по запросу отличается удивительной простотой и элегантностью, являясь цри этом наиболее современной схемой инстанцирования классов из всех рассмотренных нами..В этой схеме создается и поддерживается специальная база данных, совместно используемая при компиляции всех единиц трансляции, имеющих отношение к программе.
В нее заносатся сведения об инстанцированных специализациях шаблонов, а также о том, от какого элемента исходного кода они зависят. Сами сгенерированные специализации также обычно сохраняются в этой базе данных. При достижении точки ннстанцирования подлежащего компоновке элемента происходит одно из трех перечисленных ниже событий. 9 Если компилятор не в состоянии "встраивать" все вызовы какой-то функции, обозначенной ключевым словом ьп11по, в состав объектного файла вводится отдельная копия этой функции. ю Обычно вызовы виртуальной функции реализуются как косвенные, причем это осуществляется с помощью таблиц указателей на функции. Фундаментальное исследование подобных аспектов Реализации С++ можно найти в [2[]. 182 Глава 10.
Инстанцирование 1. Соответствующая специализация отсутствует. В этом случае происходит инстанцирование, а полученная в результате специализация заносится в базу данных. 2. Специализация имеется в наличии, однако она устарела, поскольку с момента ее создания произошли изменения в исходном коде. В этой ситуации также происходит инстанцирование, а полученная в результате специализация заносится в базу данных вместо предыдущей. 3. В базе данных содержится подходящая специализация.
Делать ничего не нужно. Несмотря на концептуальную простоту описанной схемы, ее реализация связана с необходимостью решения некоторых практических задач. В частности, далеко не просто поддерживать правильную взаимосвязь между структурными элементами базы данных, поскольку состояние исходного кода может меняться.
Несмотря на то что не будет ошибкой принять третий случай за второй, это увеличит количество работы, которую необходимо выполнить компилятору (а значит, и время компиляции). Кроме того, про'- мышленные компиляторы зачастую выполняют параллельную компиляцию нескольких единиц трансляции, что также усложняет поддержку базы данных. Несмотря на указанные трудности, схема может быть довольно эффективно реализована. Кроме того, в отличие, например, от жадного инстанцирования, которое может привести к большому количеству напрасно затраченной работы, при описанном решении практически отсутствуют патологические случаи, которые могли бы привести к излишней работе компилятора. К сожалению, использование базы данных также может создать некоторые проблемы программисту. Причина большинства этих проблем заключается в том, что традиционная модель трансляции, унаследованная от большинства компиляторов С, больше не применима: в результате компиляции одной единицы трансляции теперь не создается отдельный объектный файл.
Предположим, например, что нужно скомпоновать конечную программу. Для этого понадобится не только содержимое каждого объектного файла, связанного с различными единицами трансляции, но и тех объектных файлов, которые хранятся в базе данных. Аналогично, в процессе создания бинарной библиотеки нужно убедиться в том, что инструмент, с помощью которого эта библиотека создается (обычно ' зто компоновщик или архиватор), располагает сведениями из базы данных.
По сути, лю-' бой инструмент, оперирующий с объектными файлами, должен иметь информацию о содержимом базы данных. Многие из этих проблем можно смягчить, не занося инстанци. рования в базу данных, а размещая вместо этого их объектный код в объектный файл, вызвавший данное инстанцирование. С библиотеками связана другая проблема.
В одну и ту же библиотеку может быть упаковано несколько сгенерированных специализаций. При добавлении этой библиотеки в другов проект может понадобиться занести в базу данных нового проекта сведения об уже доступны" инстанцированиях. Если этого не сделать и если в проекте создакпся свои точки инстанциро нация лля специализаций, которые содержатся в библиотеке, инстанцировання могут дубли роватъся. Стратегия, которой следует придерживаться в такой ситуации, может состоять в применении той же технологии компоновки, что и при жадном инстанцировании: передать 10.4. Схемы реализации 183 компоновщику сведения об имеющихся инсганцированиях, а затем избавиться от дубликатов (которые, однако, встречаются намного реже, чем в случае жадного инстанцирования).
Другие варианты размещений исходных файлов, обьектных файлов и библиотек могут вызвать новые проблемы, в частности отсутствие инстанцироваиий нз-за того, что объектный код, содержащий нужное инстанцирование, не скомпонован с конечной исполняемой программой. 3ти проблемы объясняются не недостатками подхода, основанного на инстанцировании по запросу; скорее их следует воспринимать как аргумент против создания излишне сложных сред разработки программного обеспечения. 10.4.3. Итеративное инстанцирование Первым компилятором, поддерживающим шаблоны С++, был С!гоп! 3.0 — прямой потомок компилятора, разработанного Бьерном Страуструпом в процессе создания языка программирования С++ . Одна из особенностей компилятора Сайгон!, ограничивающая !1 его гибкость, заключалась в том, что он должен был обладать переносимостью на другие платформы.
Зто означает, что, во-первых, в качестве представления на всех целевых платформах используется язык С и, во-вторых, применяется локальный целевой компоновщик. В частности, при этом подразумевается, что компоновщик не способен обрабатывать шаблоны. Фактически компилятор Сайгон! генерировал инстанцирования шаблонов как обычные функции С, поэтому он должен был избегать повторных инстанцировалий. Хотя исходная модель, на которой основан компилятор С!гоп!, отличалась от стандартных моделей включения и разделения, можно добиться того, что используемая в этом компиляторе стратегия инстанцирования будет соответствовать модели включения. Таким образом, это первый компилятора, в котором было воплощено итеративное инстанцирование.
Итерации компилятора Сайгон! описаны ниже. 1. Исходный код компилируется без инстанцирования каких бы то ни было специализаций. 2. Объектные файлы связываются с помощью предварительного компоновщика (ргейп1сег). 3. Предварительный компоновщик вызывает компоновщик и анализирует сгенерированные сообщения об ошибках, чтобы определить, не вызваны ли они отсутствием инстанцирований; если причина ошибки именно в этом, предварительный компоновщик вызывает компилятор для обработки исходных файлов, содержащих необходимые определения шаблонов; при этом параметры компилятора настроены для генерирования отсутствующих инстанцирований. 4. Если сгенерированы какие-либо определения, повторяется шаг 3: !! Не поймите э!у фразу лревршно, придя к заключению, по компилятор Сйол! был абстрактным лрототяпом.
Напротив, ол лслольэояялся в промышленных целях и послужил основой лля многих комиерческих компилятоРов С++. Версия 3.0 лояяилесь е 1991 году, ио стршшла ляллчлем ошибок. Вскоре эя этим последовала лере"я 3.0 1, благодаря которой стало возможным применение шаблонов. 184 Глава 10. Инстанцирование Повторение шага 3 обусловлено тем, что на практике инстанцирование одного из подлежащих компоновке элементов может привести к необходимости инстанцировать шаблон в другом элементе, который еше не был обработан. Такой итеративный процесс в конечном счете сходится, и компоновщику удается создать завершенную программу.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
