Скотт Майерс - Эффективное использование C++. 55 верных способов улучшить структуру и код ваших программ

Реализация этой идеи в iterator_traits состоит из двух частей. Первая – вводится требование, чтобы все определяемые пользователем типы итераторов имели внутри себя вложенный typedef с именем iterator_category, который задает соответствующую структуру-тэг. Например, итераторы deque являются итераторами с произвольным доступом, поэтому класс итераторов deque должен выглядеть примерно так:

template <���…>

class deque {

public:

class iterator {

public:

typedef random_access_iterator_tag iterator_category;

...

};

...

};

Итераторы для контейнеров 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

struct iterator_traits {

typedef typename IterT::iterator_category iterator_category;

...

};

Это работает с пользовательскими типами, но не подходит для итераторов, которые являются указателями, потому что не существует указателей с вложенными typedef. Поэтому во второй части шаблона iterator_traits реализована поддержка итераторов, являющихся указателями.

С этой целью iterator_traits представляет частичную специализацию шаблонов для типов указателей. Указатели ведут себя как итераторы с произвольным доступом, поэтому в iterator_traits для них указана именно эта категория:

template // частичная специализация шаблона

struct iterator_traits // для встроенных типов указателей

{

typedef random_access_iterator_tar iterator_category;

...

};

Теперь вы должны понимать, как проектируется и реализуется класс-характеристика:

• Идентифицировать информацию о типе, которую вы хотели бы сделать доступной (например, для итераторов – это их категория).

• Выбрать имя для обозначения этой информации (например, iterator_category).

• Предоставить шаблон и набор его специализаций (например, iterator_traits), которые содержат информацию о типах, которые вы хотите поддерживать.

Имея шаблон iterator_traits, – на самом деле std::iterator_traits, потому что он является частью стандартной библиотеки C++, – мы можем уточнить наш псевдокод для advance:

template

void advance(IterT& iter, DistT d)

{

if (typeid(typename std::iterator_traits::iterator_category)==

typeid(std::random_access_iterator_tag))

...

}

Выглядит многообещающе, но это не совсем то, что нужно. Во-первых, возникнет проблема при компиляции, но ее мы рассмотрим в правиле 48; а пока остановимся на более фундаментальном обстоятельстве. Тип IterT известен на этапе компиляции, поэтому iterator_traits::iterator_category также может быть определен во время компиляции. Но предложение if вычисляется во время исполнения. Зачем делать во время исполнения нечто такое, что можно сделать во время компиляции? Это пустая трата времени и раздувание исполняемого кода.

Что нам нужно – так это условная конструкция (например, предложение if..else) для типов, которая вычислялась бы во время компиляции. К счастью, в C++ есть необходимые нам средства. Это не что иное, как перегрузка.

Когда вы перегружаете некоторую функцию f, вы указываете параметры разных типов для различных версий. Когда вызывается f, компилятор выбирает наиболее подходящую из перегруженных версий, основываясь на переданных аргументах. Компилятор, по сути, говорит: «Если эта версия лучше всего соответствует переданным параметрам, вызову ее; если лучше подходит другая версия – остановлюсь на ней, и так далее». Видите? Условная конструкция для типов во время компиляции. Чтобы заставить advance работать нужным нам образом, следует всего лишь создать две версии перегруженной функции, объявив в качестве параметра для каждой из них объекты iterator_category разных типов. Я назову эти функции doAdvance:

template // использовать эту

void doAdvance(IterT& iter, DistT d, // реализацию для

std::random_access_iterator_tag) // итераторов

{ // с произвольным доступом

iter += d;

}

template // использовать эту

void doAdvance(IterT& iter, DistT d, // реализацию для

std::bidirectional_iterator_tag) // двунаправленных

{ // итераторов

if(d >= 0) {while(d–) ++iter;}

else {while (d++) –iter;}

}

template // использовать

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 – не отрицательно, поэтому входят в очень длинный цикл, пытаясь отсчитать «вниз» до нуля, если им передается отрицательное значение. В коде, приведенном выше, я показал вариант, в котором вместо этого возбуждается исключение. Обе реализации корректны. Это проклятие неопределенного поведения: вы не можете предсказать, что произойдет.

Имея разные перегруженные версии doAdvance, функции advance остается только вызвать их, передав в качестве дополнительного параметра объект, соответствующий типу категории итератора, чтобы компилятор мог применить механизм разрешения перегрузки для вызова правильной реализации:

template