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

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

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

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

Мораль

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вопросы и приемы безопасности исключений

Обработка исключений представляет собой фундаментальный механизм сообщения об ошибках в совремсиных языках программирования, включая С++. В [SutterOO] и [Suttcrt)2] мы детально рассмотрели множество вопросов, связанных с определением того, что такое безопасность исключений, как следует писать безопасный с точки зрения исключений код и многие другие.

В этом разделе мы продолжим изложение материала, посвященного обработке исключений, сконцентрировав свое внимание на некоторых специфических возможностях языка, связанных с исключениями. Начнем же мы с ответов на неизменные вопросы - достаточно ли для безопасности исключений написать в нужном месте try и catch? Если нет, то что для этого требуется? И о чем ие следует забывать при разработке стратегии безопасности исключений в ваших программах?

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