Каково различие между C++ 0x понятия и Библиотекой проверки понятия повышения (BCCL)?

Концептуальная функция C ++ 0x будет функцией основного языка , весь процесс которой будет выполняться компилятором.

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

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

Отказ от ответственности: мне не удалось успешно использовать BCCL в течение последних 30 минут, хотя у меня уже был установлен Boost. Пример, который вы видите ниже, выглядит нормально в соответствии с документацией BCCL для Boost 1.37, но не работает. Я думаю, это считается недостатком.

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

Что касается разрешения перегрузки, вот пример:

template<typename Iter>
void foo(Iter,Iter) {
   BOOST_CONCEPT_ASSERT((RandomAccessIterator<Iter>));
}

void foo(long, int);

int main() {
   foo(2,3); // compile-time error
}

Шаблон подходит лучше, потому что не шаблон требуется преобразование из int в long. Но создание экземпляра не удается, потому что int не является итератором. Вы получаете красивое сообщение об ошибке, объясняющее это, но это не очень приятно, не так ли? С собственными концепциями вы могли бы написать

template<typename Iter>
  requires RandomAccessIterator<Iter>
void foo(Iter,Iter) {}

void foo(long, int);

int main() {
   foo(2,3); // OK, picks non-template foo
}

Здесь шаблон функции не будет участвовать в разрешении перегрузки, потому что требование для T = int не выполняется. Отлично!

Мы все еще можем ограничивать шаблоны функций с помощью трюка SFINAE. C ++ 0x расширяет SFINAE на выражения, и вместе с аргументами decltype и шаблона по умолчанию для шаблонов функций мы можем написать

template<typename T> T&& make();

template<typename Iter, class = decltype( *make<Iter>() )>
void foo(Iter,Iter) {}

void foo(long, int);

int main() {
   foo(2,3); // OK, picks non-template foo
}

В этом случае вывод аргумента шаблона завершится неудачно без предупреждения , потому что компилятор не знает, каким должен быть тип выражения ∗ make () (мы не можем разыменовать int). С помощью небольшого метапрограммирования шаблона и некоторых макросов мы можем довольно близко подойти к наложению произвольных структурных ограничений на параметры шаблона в удобочитаемой форме . Вот как это может выглядеть, если принять соответствующие определения для REQUIRES и RandomAccessIterator:

template <typename Iter
  REQUIRES( RandomAccessIterator<Iter> )
>
void foo(Iter,Iter) {}

HTH, С помощью небольшого метапрограммирования шаблона и некоторых макросов мы можем довольно близко подойти к наложению произвольных структурных ограничений на параметры шаблона в удобочитаемой форме . Вот как это может выглядеть, если принять соответствующие определения для REQUIRES и RandomAccessIterator:

template <typename Iter
  REQUIRES( RandomAccessIterator<Iter> )
>
void foo(Iter,Iter) {}

HTH, С помощью небольшого метапрограммирования шаблонов и некоторых макросов мы можем довольно близко подойти к наложению произвольных структурных ограничений на параметры шаблона в удобочитаемой форме . Вот как это может выглядеть, если принять соответствующие определения для REQUIRES и RandomAccessIterator:

template <typename Iter
  REQUIRES( RandomAccessIterator<Iter> )
>
void foo(Iter,Iter) {}

HTH, S