Прежде всего, Херб не сказал, что сами концепции замедляют компиляцию.Он сказал, что при разработке стандартной библиотеки C ++ любой код, использующий стандартную библиотеку C ++, компилируется медленнее.
Причина этого кроется в нескольких вещах.
1: ограничение шаблонов требует компиляциивремя.
Когда вы объявляете такой класс:
template<typename T> class Foo {...};
Компилятор просто анализирует Foo и делает очень мало.Даже при двухфазном поиске компилятор просто мало что делает при компиляции класса Foo.Разумеется, он сохраняет его на потом, но начальный этап выполняется относительно быстро.
Когда вы ограничиваете шаблон следующим понятием:
template<ConceptName C> class Foo {...};
Компилятор должен сделать некоторые вещи.Необходимо заранее проверить, что каждое использование типа C соответствует концепции ConceptName.Это дополнительная работа, которую компилятор отложил бы до времени создания экземпляра.
Чем больше у вас проверок концептов, тем больше времени уходит на компиляцию, чтобы убедиться, что типы соответствуют концепциям.
2: Стандартная библиотека C ++ использует много понятий.
Посмотрите на число понятий итератора: ввод, вывод, пересылка, двунаправленный, последовательный, непрерывный.И комитет рассматривал возможность разбить их на гораздо большее.Многие алгоритмы имеют несколько версий для различных концепций итераторов.
И это не включает в себя концепции диапазонов (из которых есть один для каждого вида итераторов, кроме выходных), символьные концепции для std :: string иразличные другие вещи.Все они должны быть скомпилированы и проверены.
Какие концепции действительно нужны для быстрой работы, это modules .Возможность для компилятора генерировать файл модуля, который содержит последовательность предварительно проверенных символов, а затем загружать этот файл напрямую, без необходимости проходить стандартный процесс компиляции.Прямо от разбора до создания символа.
Помните: для каждого файла .cpp, который вы #include, компилятор должен прочитать этот файл и скомпилировать его.Несмотря на то, что файл одинаков каждый раз, когда он делает это , он все равно должен послушно прочитать файл и обработать его.Если мы говорим о концептуальном std::vector, он должен выполнить всю концептуальную проверку шаблона.Он по-прежнему должен выполнять весь стандартный поиск символов, который вы делаете при компиляции.И т. Д.
Представьте себе, если компилятору не нужно было это делать.Представьте себе, можно ли просто загрузить набор символов и определений прямо с диска.Нет компиляции вообще;просто добавление символов и определений для использования другим кодом.
Это было бы лучше, чем скомпилированные заголовки.Предварительно скомпилированные заголовки могут иметь только один файл на каждый .cpp, тогда как вы можете использовать столько модулей, сколько захотите.
К сожалению, модули были выдернуты довольно рано в процессе из C ++ 0x.А без модулей ограничение стандартной библиотеки концепциями всегда будет компилироваться медленнее, чем неограниченная версия.
Обратите внимание, что Херб неправильно понимает назначение модулей (не сложно, поскольку большинство первоначальных концепций этой функции былион говорил о: кроссплатформенные библиотеки DLL и тому подобное).Их основная фундаментальная цель - помочь компилировать время, а не заставить кросс-платформенные библиотеки DLL работать.Также не предполагается, что сами модули будут кроссплатформенными.