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

, в предположении, что имеет место именно такая реализация std::vector::reference.

Вызов features возвращает временный объект std::vector. Этот объект не имеет имени, но для упрощения нашего рассмотрения я буду называть его temp. Для temp вызывается operator[], в результате чего возвращается объект std::vector::reference, содержащий указатель на слово в структуре данных, хранящей интересующий нас бит (эта структура находится под управлением temp), плюс смещение в слове, соответствующее пятому биту. Переменная highPriority представляет собой копию этого объекта std::vector::reference, так что highPriority тоже содержит указатель на слово в temp плюс смещение, соответствующее пятому биту. В конце инструкции объект temp уничтожается, так как это объект временный. В результате переменная highPriority содержит висячий указатель, что и дает неопределенное поведение при вызове processWidget:

processWidget(w, highPriority); // Неопределенное поведение!
                                // highPriority содержит
                                // висячий указатель!

Класс std::vector::reference является примером прокси-класса (proxy class), т.e. класса, цель которого — эмуляция и дополнение поведения некоторого другого типа. Прокси-классы применяются для множества разных целей. Например, std::vector::reference нужен для того, чтобы создать иллюзию, что operator[] класса std::vector возвращает ссылку на бит, а интеллектуальные указатели стандартной библиотеки (см. главу 4, “Интеллектуальные указатели”) являются прокси-классами, которые добавляют к обычным указателям управление ресурсами. Полезность прокси-классов — давно установленный и не вызывающий сомнения факт. Фактически шаблон проектирования “Прокси” — один из наиболее давних членов пантеона шаблонов проектирования программного обеспечения.

Одни прокси-классы спроектированы так, чтобы быть очевидными для клиентов. Это, например, такие классы, как std::shared_ptr и std::unique_ptr. Другие прокси-классы спроектированы для более-менее невидимой работы. Примером такого “невидимого” прокси-класса является std::vector::reference, как и его собрат std::bitset::reference из класса std::bitset.

В этом же лагере находятся и некоторые классы библиотек С++, применяющих технологию, известную как шаблоны выражений (expression templates). Такие библиотеки изначально разрабатывались для повышения эффективности кода для числовых вычислений. Например, для заданного класса Matrix и объектов m1, m2, m3 и m4 класса Matrix, выражение

Matrix sum = m1 + m2 + m3 + m4;

может быть вычислено более эффективно, если operator+ для объектов Matrix возвращает не сам результат, а его прокси-класс. Иначе говоря, operator+ для двух объектов Matrix должен возвращать объект прокси-класса, такого как Sum, а не объект Matrix. Как и в случае с std::vector::reference и bool, должно иметься неявное преобразование из прокси-класса в Matrix, которое позволит инициализировать sum прокси-объектом, полученным из выражения справа от знака “=”. (Тип этого объекта будет традиционно кодировать все выражение инициализации, т.e. быть чем-то наподобие Sum, Matrix>, Matrix>. Определенно, это тип, от которого следует защитить клиентов.)

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

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

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

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

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

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

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

template