Существуют ли оптимизированные компиляторы C++ для шаблонного использования?

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

Является там проектами разработать новое поколение компиляторов C++, которые оптимизировали бы это?

Да, существует Лязг , который является языком C Frontend для инфраструктуры Компилятора LLVM. Оба Лязга и LLVM кодируются с помощью C++. Среди разработчиков Лязга Douglas Gregor, автор нескольких C++ 1x Предложения по Языку как шаблоны variadic и Понятия. Для ссылки посмотрите, что этот тест Douglas Gregor лязга против GCC

Вот является некоторыми quick-n-dirty результатами проверки производительности для шаблонного инстанцирования в Лязге и GCC 4.2. Тест очень прост: измерьте время компиляции (-fsyntax-только) для единицы перевода, которая вычисляет Энное Число Фибоначчи с помощью шаблонной метапрограммы. Лязг, кажется, масштабируется линейно (или близко к нему) с количеством инстанцирований. И, хотя Вы не видите его в диаграмме, Лязг немногим более, чем 2x быстрее, чем GCC вначале (Fibonacci<100>).

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

Это действительно не ответ на Ваш вопрос. Это - больше наблюдения стороны.

я не адвокат языка C++ также, и таким образом, я мог быть путем от основы с некоторыми деталями.

, Но, общее представление должно быть корректным.

главная причина, что компиляторы C++ занимают такое долгое время для компиляции шаблонных метапрограмм, из-за способа, которым определяются шаблонные метапрограммы.

Они не определяются непосредственно как код, который Вы хотите, чтобы компилятор выполнил во время компиляции. Возьмите пример вычислений длины списка типов.

, Если Вы могли бы написать код как это:

compile_time size_t GetLength(TypeList * pTypeList)
{
    return DoGetLength(pTypeList, 0);
}

compile_time size_t DoGetLength(TypeList * pTypeList, size_t currentLength)
{
    if (pTypeList)
    {
        return DoGetLength(pTypeList->Next, ++currentLength);
    }
    else
    {
         return currentLength;
    }
}

, Который был некоторыми, как скомпилированный отдельно от кода, где он использовался, и был представлен языку через некоторый синтаксис, тогда компилятор будет в состоянии выполнить его очень быстро.

Это просто был бы простой вызов рекурсивной функции.

Это возможно на язык проектирования, который позволяет те виды вещей. Большинство из тех, которые делают это (как шепелявость) с динамическим контролем типов, но возможно сделать со статическим контролем типов. Однако это вряд ли когда-либо будет что-то, что Вы видели бы реализованный в C++.

проблема в C++, однако, состоит в том, что код написан как:

template <typename First,  typename Second>
struct TypeList
{
    typedef First Head;
    typedef Second Tail;
};

template <>
struct ListSize<NullType>
{
    enum {  size = 0  };
};

template <typename Head, typename Tail>
struct ListSize<TypeList<Head, Tail> >
{
    enum {  size = 1 + ListSize<Tail>::size  };
};

Для компилятора для "выполнения" метапрограммы это имеет к:

1. Конструкция граф зависимостей для начальных значений перечисления значений "размера"
2. Конструкция шаблонный тип для каждого края в графике
3. Связывает все символы, на которые ссылается каждый созданный шаблонный тип
4. , Топологически сортируют граф зависимостей
5. Пересечение график и оценивают константы

, Это намного более дорого, чем просто выполнение O (N) рекурсивный алгоритм.

худший случай был бы чем-то как O (N * M * L), с N, равным длине списка, M быть уровнем вложения объема и L быть количеством символов в каждом объеме.

Мой совет состоял бы в том, чтобы минимизировать сумму шаблонного метапрограммирования C++, которое Вы используете.

основная проблема с шаблонами следующая:

Вы не можете (обычно) разделять определение своего шаблонного класса от его объявления и помещать его в .cpp файле.

последствие: Everyting находится в заголовочных файлах. Каждый раз, когда Вы включаете заголовок, Вы включаете много кода, который был бы при нормальных обстоятельствах быть приятно разделенным на .cpp файлы и скомпилированным отдельно. Каждая единица компиляции включает несколько заголовков, и таким образом, с шаблонами каждая единица компиляции содержит много из кода или почти весь Ваш проект, через включенные заголовки.

, Если это - Ваша проблема, то посмотрите здесь в связанном вопросе:

• Шаблоны: Использовать предописания для сокращения времени компиляции?

Это добралось очень хороший ответ , который делает , решают ту проблему .

В основном, это включает инстанцирование шаблонов, в которых Вы нуждаетесь однажды и компилируете их в объектный файл. Позже можно связаться против него, и Вы не должны включать тот код везде. Это разделено на скомпилированный объектный файл.Примечание: Это имеет смысл, только если Вы используете только что несколько инстанцированных типов своих шаблонов (скажите, Вам только нужно MyType<int> и MyType<double> в Вашей программе).

Это использует g++ флаг -fno-implicit-templates.

, Что техника так полезна, что я думаю, что она должна быть включена в часто задаваемые вопросы C++: [35.12], Почему я не могу разделить определение своего шаблонного класса от, он - объявление и поместил его в .cpp файле?

Это не будет ответом, который Вы хотите, но Walter Bright был основным разработчиком первого собственного компилятора C++ и оптимизированного компилятора C++. В конце концов то, что он записал свой собственный язык программирования по имени D. Это - в основном улучшение на C++ и справляется с шаблонами лучше.

я не знаю никакого компилятора C++, что он оптимизировал для шаблонного использования.

Попробуйте Incredibuild. Это существенно сокращает компиляцию/время изготовления.

Этот продукт в основном позволяет Visual C++ создать через несколько машин в Вашей организации путем использования в своих интересах неактивных циклов. Я использовал Incredibuild на огромных проектах (500 kloc) с большим количеством шаблона кода и получил хорошее ускорение во время изготовления.

Я думаю, что сами шаблоны не так сложны в себе. Мы будем видеть, когда понятия будут представлены в C++ 0x, и т.д., но в данный момент, шаблоны просто (почти) как макросы, таким образом, настоящая проблема не это при оптимизации компиляторов C++ для шаблонов. Проблема состоит в том, что шаблоны действительно генерируют такой огромный объем кода при компиляции, которые делают компиляцию медленнее.

Компоновщик gold может помочь сократить время компоновки примерно в 5 раз, что может сократить общее время компиляции. Это особенно полезно, так как компоновка не может быть распараллелена так же, как компиляция.

(Не прямой ответ, но, надеюсь, это полезно).