...
};
Итераторы для контейнеров list являются двунаправленными, поэтому для них объявление выглядит так:
template <…>
class list {
public:
class iterator {
public:
typedef bidirectional_iterator_tag iterator_category;
};
...
};
В шаблоне iterator_traits просто повторен находящийся внутри класса итератора typedef:
// iterator_category для типа IterT – это то, что сообщает о нем сам IterT
// см. в правиле 42 информацию об использовании “typedef typename”
template <typename IterT>
struct iterator_traits {
typedef typename IterT::iterator_category iterator_category;
...
};
Это работает с пользовательскими типами, но не подходит для итераторов, которые являются указателями, потому что не существует указателей с вложенными typedef. Поэтому во второй части шаблона iterator_traits реализована поддержка итераторов, являющихся указателями.
С этой целью iterator_traits представляет
template <typename IterT> // частичная специализация шаблона
struct iterator_traits<IterT*> // для встроенных типов указателей
{
typedef random_access_iterator_tar iterator_category;
...
};
Теперь вы должны понимать, как проектируется и реализуется класс-характеристика:
• Идентифицировать информацию о типе, которую вы хотели бы сделать доступной (например, для итераторов – это их категория).
• Выбрать имя для обозначения этой информации (например, iterator_category).
• Предоставить шаблон и набор его специализаций (например, iterator_traits), которые содержат информацию о типах, которые вы хотите поддерживать.
Имея шаблон iterator_traits, – на самом деле std::iterator_traits, потому что он является частью стандартной библиотеки C++, – мы можем уточнить наш псевдокод для advance:
template<typename IterT, typename DistT>
void advance(IterT& iter, DistT d)
{
if (typeid(typename std::iterator_traits<IterT>::iterator_category)==
typeid(std::random_access_iterator_tag))
...
}
Выглядит многообещающе, но это не совсем то, что нужно. Во-первых, возникнет проблема при компиляции, но ее мы рассмотрим в правиле 48; а пока остановимся на более фундаментальном обстоятельстве. Тип IterT известен на этапе компиляции, поэтому iterator_traits<IterT>::iterator_category также может быть определен во время компиляции. Но предложение if вычисляется во время исполнения. Зачем делать во время исполнения нечто такое, что можно сделать во время компиляции? Это пустая трата времени и раздувание исполняемого кода.
Что нам нужно – так это условная конструкция (например, предложение if..else) для типов, которая вычислялась бы во время компиляции. К счастью, в C++ есть необходимые нам средства. Это не что иное, как перегрузка.
Когда вы перегружаете некоторую функцию f, вы указываете параметры разных типов для различных версий. Когда вызывается f, компилятор выбирает наиболее подходящую из перегруженных версий, основываясь на переданных аргументах. Компилятор, по сути, говорит: «Если эта версия лучше всего соответствует переданным параметрам, вызову ее; если лучше подходит другая версия – остановлюсь на ней, и так далее». Видите? Условная конструкция для типов во время компиляции. Чтобы заставить advance работать нужным нам образом, следует всего лишь создать две версии перегруженной функции, объявив в качестве параметра для каждой из них объекты iterator_category разных типов. Я назову эти функции doAdvance:
template<typename IterT, typename DistT> // использовать эту
void doAdvance(IterT& iter, DistT d, // реализацию для
std::random_access_iterator_tag) // итераторов
{ // с произвольным доступом
iter += d;
}
template<typename IterT, typename DistT> // использовать эту
void doAdvance(IterT& iter, DistT d, // реализацию для
std::bidirectional_iterator_tag) // двунаправленных
{ // итераторов
if(d >= 0) {while(d–) ++iter;}
else {while (d++) –iter;}
}
template<typename IterT, typename DistT> // использовать
void doAdvance(IterT& iter, DistT d, // эту реализацию
std::input_iterator_tag) // для итераторов
{ // ввода
if(d < 0) {
throw std::out_of_range(“Отрицательное направление”); // см. ниже
}
while (d–) ++iter;
}
Поскольку forward_iterator_tag наследует input_iterator_tag, то версия do-Advance для input_iterator_tag будет работать и с однонаправленными итераторами. Это дополнительный аргумент в пользу наследования между разными структурами iterator_tag. Фактически это аргумент в пользу
Спецификация advance допускает как положительные, так и отрицательные значения сдвига для итераторов с произвольным доступом и двунаправленных итераторов, но поведение не определено, если вы попытаетесь сдвинуть на отрицательное расстояние итератор ввода или однонаправленный итератор. Реализации, которые я проверял, просто предполагают, что d – не отрицательно, поэтому входят в