Задача 10. Ограничения экспорта. Часть 2: взаимосвязи, практичность

и советы по использованию Сложность: 9

Как export взаимодействует с другими возможностями языка С++ и как эффективно и безопасно его использовать?

Вопрос для новичка

1. Когда возможность экспорта появилась в стандарте С++ в с с современном виде? Когда она была впервые реализована?

Вопрос для профессионала

2. Поясните, каким образом экспорт изменяет смысл других конструкций С++?

3. Чем именно export мешает профаммисту?

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

Решение

Перед вами вторая часть мини-серии. В предыдущей задаче мы рассмотрели следующие вопросы.

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

• В чем заключаются основные проблемы экспортирования и почему экспортирование работает не так, как ожидают от него профаммисты?

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

Накопленный на сегодняшний день опыт работы с экспортом шаблонов говорит нам, что поставляться исходный текст (или его эквивалент) должен полностью, и что не известно, будет ли время построения приложения при использовании экспорта больше, меньше или останется таким же, как и без него. Почему? Главная причина в зависимостях, которые несмотря на всю маскировку никуда не удаляются, так что компилятор в общем случае должен выполнить как минимум то же количество работы, что и при использовании модели включения шаблонов. Коротко говоря, это ошибка (хотя и вполне естественная) - думать, что экспорт приводит к истинной раздельной компиляции шаблонов в том же смысле, что автор может поставлять только заголовочные файлы с объявлениями шаблонов и объектный код. Экспорт шаблонов скорее похож на библиотеки Java и .NET, в которых байт-код или 1L может быть преобразован в нечто, напоминающее исходный текст. Код этих библиотек не является традиционным объектным кодом.

Здесь я хочу рассмотреть следующие вопросы.

• Текущее состояние экспорта шаблонов.

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

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

Но сначала -- краткий курс истории. Начало: 1988-1996 гг.

1. Когда возможность экспорта появилась в стандарте С++ в ее современном виде? Когда она была впервые реализована?

Ответ на поставленный вопрос - 1996 и 2002 годы соответственно. (Если вам кажется, что дата первой реализации той или иной возможности по-хорошему должна предшествовать дате включения ее в стандарт, вы не одиноки, но экспорт шаблонов - не единственный пример, когда стандарт предвосхитил реализацию.)

Исходя из вышесказанного и вполне обоснованной критики export, можно начинать кампанию по побиванию камнями людей, которые окопались в комитете по стандарту С++ и принимают такие глупые решения. Но вряд ли стоит впадать в крайности и спешить с выводами. Давайте прислушаемся ко всем "за" и "против", прежде чем принимать решения.

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

Вспомним также, что в 1995-1996 годах шаблоны были достаточно новой возможностью С++.

• Впервые шаблоны для С++ были предложены Бьярном Страуструпом в октябре 1988 года [Stroustmp88].

• В 1990 году Маргарет Эллис и Бьярн Страуструп опубликовали The Annotated С++ Reference Manual (ARM) [Ellis90]. В том же году приступил к работе комитет по стандартизации ISO/ANSI С++, выбрав ARM в качестве "отправной точки". Эта книга была первым справочником по С++, включавшим описание шаблонов. Это были не тс шаблоны, которые известны нам сегодня. Полное описание этих простейших шаблонов занимало всего 10 страниц текста.

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

• В 1990-1996 годах разработчики компиляторов С++ работали над реализацией поддержки шаблонов в своих компиляторах и ее развитием, и в то же время комитет по стандарту С++ сушественно расширил (и усложнил) семантику шаблонов. Достаточно упомянуть, что полное описание шаблонов в стандарте С++ занимает 133 страницы в 552-страничной книге [Vandevoorde03], посвященной шаблонам и их эффективному использованию (и которую я крайне рекомендую вам прочесть).

• в начале и средине 1990-х годов комитет по стандарту С++ пытался сделать шаблоны более интеллектуальными и практичными. Члены комитета оказались сами несколько удивлены чрезвычайной гибкостью и определенной "монстрообразностью" того, что получилось. Как известно, шаблоны представляют собой полный в смысле Тьюринга метаязык, который позволяет написать профамму любой сложности, которая будет полностью выполнена на этапе компиляции. Современные технологии .мстапрогра.ммирования с использованием шаблонов и дизайн современных библиотек оказались неожиданными для людей, которые дали программистам эти самые шаблоны. Упо.мянутые технологии были практически неизвестны в 1990-1996 годах. Они не использовались до 1994 года, когда Степанов впервые представил свою первую версию STL комитету. В 1995 году эта библиотека была воспринята как большое достижение - это сегодня STL "всего лишь" библиотека контейнеров и алгоритмов.

Вот почему я утверждаю, что в 1995-1996 годах шаблоны были достаточно новой возможностью С++. Современные шаблоны уже существовали почти в том же виде, что и сегодня, но даже их первооткрыватели не могли полностью представить, на что они способны. Сообщество С++ было в те годы существенно меньше сегодняшнего, только немногие компиляторы поддерживали шаблоны в объеме большем, чем было описано в ARM, а сама поддержка была слабой и по сути бесполезной. В качестве примера - в то время с первой версией STL смог справиться только одии-единственный коммерческий компилятор.

Итак, все программистское сообщество в целом и комитет в частности имели только сравнительно небольшой опыт работы с шаблонами, причем в основном с более простыми шаблонами ARM. Шаблоны в 1996 году уже не были в зачаточном состоянии, но они все еще находились в стадии роста и формирования.

Как видим, комитет по стандарту С++ принял решение о включении экспорта шаблонов в стандарт еще на первых этапах развития, при ограниченном опыте работы с шаблонами.

1996 г.

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

В 1996 году в комитете наблюдалась скоординированная поддержка удаления понятия "раздельной" ко.мпиляции шаблонов из стандарта. В частности, утверждалось, что модель раздельной компиляции шаблонов никогда не была реализована в действительности, так что было не понятно, будет ли она работать так, как предполагается. Некоторые разработчики компиляторов С++ реализовали различные виды организации исходных кодов шаблонов, но среди них не было поддержки export; это была совершенно новая экспериментальная модель, за которой не было никакого реального опыта. Более того, в то время вниманию общественности было представлено несколько статей (которые ретроспективно можно назвать провидческими), в которых детально расписывались некоторые из потенциальных недостатков модели экспортирования, описанной в черновом варианте стандарта.

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