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

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

void advance(IterT& iter, DistT d)

{

doAdvance( // вызвать версию

iter, d, // doAdvance

typename // соответствующую

std::iterator_traits::iterator_category() // категории

); // итератора iter

}