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

Пример 2. Компилятору сложнее генерировать высококачественную диагностику, помогающую программисту. Сообщения об ошибках, связанные с шаблонами, и без того пользуются дурной славой слишком громоздких и трудно понимаемых из-за длинных имен. Каскадные инстанцирования при экспортировании шаблонов вряд ли добавят ясности в эти сообщения. Кроме того, экспортирование добавляет как бы новое измерение в пространстве сообщений об ошибках. Сообщения типа ошибка в строке X, вызванная инстанцированием функции Y, вызванным инстанцированием Z, вызванным иистанцированием... теперь должны указывать еще и единицы трансляции, в которых это произошло. В результате каждая строка такой поэмы об ошибках будет содержать разные единицы трансляции. Выявление нарушений правила одного определения - уже достаточно сложная проблема, но в такой ситуации она становится во много раз сложнее. Столкнувшись с такими проблемами, многие программисты сочтут сообщения об ошибках в обычных шаблонах легко читаемыми и понятными.

Пример 3. Экспорт накладывает новые ограничения на среду разработки. Среда разработки - это не только .срр и .h-файлы, и многие современные инструменты разработки не в состоянии работать с выглядящими циклическими зависимостями при изменении объектных файлов в процессе компоновки (в предыдущей задаче отмечалось, что экспорт только скрывает зависимости, так что при изменении файла с экс-портируемым шаблоном надо перекомпилировать не только его, но и вес его инстанцирования).

Как заметил один из специалистов мирового класса по шаблонам, Джон Спай-сер (John Spicer) из EDG, экспорт сложен по самой своей природе и требует огромной работы для того, чтобы осознать все его последствия. Трудно дать простые советы по его использованию, которые уберегут программистов от неприятностей [выделено мной].

Потенциальные преимущества экспорта

4. В чем заключаются реальные и потенциальные преимущества export?

Теперь, когда программистам доступна реализация экспорта, самое время разобраться, как же следует использовать новые возможности. Вот основные преимущества, которые можно надеяться получить от использования экспорта шаблонов.

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

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

2 Ограничение распространения макросов. Это - реальное преимущество использования экспорта. В традиционной модели включения макросы находятся в заголовочных файлах, и в результате оказываются включенными во множество единиц трансляции. Таким образом, макросы, попавшие извне в единицу трансляции до определения шаблона, могут воздействовать на это определение. В случае использования экспорта шаблонов этого не происходит, и профаммист получает более полный контроль над определением своего шаблона, которое находится в отдельном файле. Внешние макросы при этом не в состоянии легко юздействовать на внутренние детали определения шаблона.

Это - реальное преимущество модели экспорта шаблонов, но это преимущество обеспечивается не только экспортом. В комитете по стандартизации С++ уже рас-сматриваются более общие решения проблемы макросов во всех контекстах; примером такого решения могут служить предложенные Страуструпом новые директивы препроцессора #scope и #endscope. Если такое решение будет принято, оно полностью устранит описанное преимущество модели экспорта шаблонов.

Словом, нам остается только ожидать, какие преимущества экспорта шаблонов над моделью включения проявятся в ближайшие годы. Я со своей стороны хочу только порекомендовать при выявлении какого-либо преимущества экспорта шаблонов тщательно проверять, не проявляется ли это преимущество и в модели включения.

Мораль

Так следует ли использовать экспорт шаблонов, и если да, то как именно следует это делать с точки зрения безопасности? В настоящее время этот вопрос реально касается только очень небольшого количества профаммистов, которые работают с единственным компилятором, поддерживающим эту возможность языка; для большинства же этот вопрос имеет не более чем теоретическое значение. Там, где не можешь, - не должен и хотеть...

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

> Рекомендация

Если вам нужен переносимый код - не используйте export.

Эта рекомендация банальна, если учесть, что экспорт шаблонов поддерживает только о д и и - е д и и с т ве и и ы й компилятор. Код с использованием export не переносим сегодня и вряд ли будет переносим в ближайшем будущем.

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

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

> Рекомендация

(Пока что) избегайте использования export.

Но если вы все же решили выступить в роли подопытного кролика, то вот несколько советов на основании того, что нам уже известно об экспорте шаблонов, которые, возможно, облегчат вашу участь.

> Рекомендация

Если вы решили выборочно использовать export для некоторых из ваших шаблонов, то помните о следующем.

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

Не следует ожидать, что при использовании export произойдет существенное ускорение построения ваших программ. Более того, скорость построения может даже упасть.

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

Если ваши экспортируемые шаблоны используют функции или объекты из безымянных пространств имен (или объявленные как static), то:

вы должны понимать, что эти функции и объекты будут вести себя так, как если бы они были объявлены в качестве extern и что функции будут принимать участие в разрешении перегрузки вместе с произвольным количеством функций из других безымянных пространств имен из неизвестного заранее числа исходных файлов;

вы должны обезображивать до неузнаваемости имена таких функций, чтобы предохраниться от непреднамеренного изменения семантики. (Обидно, ведь предназначение безымянных пространств имен и статических функций и объектов именно в том, чтобы вам не надо было прибегать к такого рода действиям по изменению имен; однако экспорт шаблонов лишает вас этой возможности С++);

Вы должны понимать, что это далеко не полный список неприятностей и что вы можете в любой момент столкнуться с новыми проблемами. Еще раз напомню слова Джона Спайсера о том, что трудно дать простые советы, которые уберегут профаммистов от неприятностей. Возможно, в будущем ситуация изменится, а пока что экспорт шаблонов - terra incognita, где на каждом шагу вас могут подстерегать неизвестные пока что неприятности и проблемы. Будем надеяться, что со временем ситуация изменится.

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