Скотт Мейерс - Эффективный и современный С++. 42 рекомендации по использованию С++11 и С++14

В качестве общего правила “невидимые” прокси-классы не умеют хорошо работать вместе с auto. Для объектов таких классов зачастую не предусматривается существование более длительное, чем одна инструкция, так что создание переменных таких типов, как правило, нарушает фундаментальные предположения проекта библиотеки. Это справедливо для std::vector::reference, и мы видели, как нарушение предположений ведет к неопределенному поведению.

Следовательно, надо избегать кода следующего вида:

auto someVar = выражение с типом "невидимого" прокси-класса ;

Но как распознать, когда используется прокси-объект? Программное обеспечение, использующее невидимый прокси, вряд ли станет его рекламировать. Ведь эти прокси-объекты должны быть невидимыми , по крайней мере концептуально! И если вы обнаружите их, то действительно ли следует отказываться от autoи массы преимуществ, продемонстрированных для него в разделе 2.1?

Давайте сначала зададимся вопросом, как найти прокси. Хотя “невидимые” прокси-классы спроектированы таким образом, чтобы при повседневном применении “летать вне досягаемости радара программиста”, использующие их библиотеки часто документируют такое применение. Чем лучше вы знакомы с основными проектными решениями используемых вами библиотек, тем менее вероятно, что вы пропустите такой прокси незамеченным.

Там, где документация слишком краткая, на помощь могут прийти заголовочные файлы. Возможность сокрытия прокси-объектов в исходном коде достаточно редка. Обычно прокси-объекты возвращаются из функций, которые вызываются клиентами, так что сигнатуры этих функций отражают существование прокси-объектов. Например, вот как выглядит std::vector::operator[]:

namespace std { // Из стандарта С++

template

class vector {

public:

…

class reference{ … };

referenceoperator[](size_type n);

};

}

В предположении, что вы знаете, что operator[]у std::vectorобычно возвращает T&, необычный возвращаемый тип у operator[]в данном случае должен навести вас на мысль о применении здесь прокси-класса. Уделяя повышенное внимание используемым интерфейсам, часто можно выявить наличие прокси-классов.

На практике многие разработчики обнаруживают применение прокси-классов только тогда, когда пытаются отследить источник таинственных проблем при компиляции или отладить никак не проходящий тесты модуль. Независимо от того, как вы его обнаружили, после того как выясняется, что autoопределен как выведенный тип прокси-класса вместо “проксифицируемого” типа, решение не требует отказа от auto. Само по себе ключевое слово autoпроблемой не является. Проблема в том, что auto выводит не тот тип, который вам нужен. Решение заключается в том, чтобы обеспечить вывод другого типа. Способ достижения этого заключается в том, что я называю идиомой явной типизации инициализатора .

Идиома явной типизации инициализатора включает объявление переменной с использованием auto, но с приведением инициализирующего выражения к тому типу, который должен вывести auto. Например, вот как можно использовать эту идиому, чтобы заставить highPriorityстать переменной типа bool:

autohighPriority = static_cast(features(w)[5] );

Здесь features(w)[5]продолжает, как и ранее, возвращать объект типа std::vector::reference, но приведение изменяет тип выражения на bool, который autoзатем выводит в качестве типа переменной highPriority. Во время выполнения программы объект std::vector::reference, который возвращается вызовом std::vector::operator[], преобразуется в значение boolи в качестве части преобразования выполняется разыменование все еще корректного указателя на std::vector, возвращенного вызовом features. Это позволяет избежать неопределенного поведения, с которым мы сталкивались ранее. Затем к битам, на которые указывает указатель, применяется индексация с индексом 5 и полученное значение типа boolиспользуется для инициализации переменной highPriority.

В примере с Matrixидиома явно типизированного инициализатора выглядит следующим образом:

autosum = static_cast(m1 + m2 + m3 + m4 );

Применение идиомы не ограничивается инициализаторами, производимыми прокси-классами. Она может быть полезной для того, чтобы подчеркнуть, что вы сознательно создаете переменную типа, отличного от типа, генерируемого инициализирующим выражением. Предположим, например, что у вас есть функция для вычисления некоторого значения отклонения: