Concept Checking Implementation

Boost , ,

Warning

Эта документация устарела; в настоящее время используются аналогичные, но более новые методы реализации. Эта документация также относится к компонентам и протоколам в старом интерфейсе библиотеки, таким как функции<BOOST_CLASS_REQUIRES>и<constraints()>.

Implementation

В идеале мы хотели бы уловить и указать на нарушение концепции в момент ее возникновения. Как упоминалось в D&E[2], ошибка может быть поймана путем выполнения всех требований, необходимых шаблону функции. То, как выполняются требования (в частности, допустимые выражения), является сложной задачей, поскольку мы хотим, чтобы код был составлен, но не выполнен. Наш подход заключается в выполнении требований в отдельной функции, которая назначается указателю функции. В этом случае компилятор инстанцирует функцию, но фактически не вызовет ее. Кроме того, оптимизированный компилятор удалит назначение указателя как «мертвый код» (хотя затраты на время выполнения, добавленные назначением, в любом случае будут тривиальными). Возможно, компилятор пропустит семантический анализ и компиляцию функции ограничений, что сделает наш метод указателя функций неэффективным. Однако это маловероятно, поскольку удаление ненужного кода и функций обычно выполняется на более поздних стадиях компилятора. Мы успешно использовали метод указателя функций с GNU C++, Microsoft Visual C++ и несколькими компиляторами на основе EDG (KAI C++, SGI MIPSpro). Следующий код показывает, как этот метод может быть применен кstd::stable_sort()Функция:

  template <class RandomAccessIterator>
  void stable_sort_constraints(RandomAccessIterator i)
  {
    typename std::iterator_traits<RandomAccessIterator>
      ::difference_type n;
    i += n;  // exercise the requirements for RandomAccessIterator
    ...
  }
  template <class RandomAccessIterator>
  void stable_sort(RandomAccessIterator first, RandomAccessIterator last)
  {
    typedef void (*fptr_type)(RandomAccessIterator);
    fptr_type x = &stable_sort_constraints;
    ...
  }

Часто существует большой набор требований, которые необходимо проверить, и для реализатора библиотеки было бы громоздко писать функции ограничения, такие какstable_sort_constraints().Для всех общественных целей. Вместо этого мы группируем наборы действительных выражений вместе в соответствии с определениями соответствующих понятий. Для каждой концепции мы определяем шаблон проверочного класса, где параметр шаблона предназначен для проверяемого типа. Класс содержитпротивопоказаний().Функция члена, которая выполняет все действительные выражения понятия. Объекты, используемые в функции ограничений, такие какnиi, объявлены в качестве членов данных класса проверки концепции.

  template <class Iter>
  struct RandomAccessIteratorConcept
  {
    void constraints()
    {
      i += n;
      ...
    }
    typename std::iterator_traits<RandomAccessIterator>
      ::difference_type n;
    Iter i;
    ...
  };

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

  template <class Iter>
  void stable_sort(Iter first, Iter last)
  {
    function_requires< RandomAccessIteratorConcept<Iter> >();
    ...
  }

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

  template <class Concept>
  void function_requires()
  {
    void (Concept::*x)() = BOOST_FPTR Concept::constraints;
    ignore_unused_variable_warning(x);
  }

Для проверки типовых параметров шаблонов классов мы предоставляем макросBOOST_CLASS_REQUIRE, который может использоваться внутри тела определения класса (в то время какfunction_requires() [35) может использоваться только внутри тела функции). Этот макрос объявляет шаблон вложенного класса, где параметр шаблона является указателем функции. Затем мы используем тип вложенного класса в typedef с типом указателя функции функции ограничения в качестве аргумента шаблона. Мы используем именаtype_varиconceptв вложенном классе и имена типаdef, чтобы помочь предотвратить столкновения имен.

#define BOOST_CLASS_REQUIRE(type_var, ns, concept) \
  typedef void (ns::concept <type_var>::* func##type_var##concept)(); \
  template <func##type_var##concept _Tp1> \
  struct concept_checking_##type_var##concept { }; \
  typedef concept_checking_##type_var##concept< \
    BOOST_FPTR ns::concept<type_var>::constraints> \
    concept_checking_typedef_##type_var##concept