Зачем возвращать прокси-класс даже для функции-члена const для «копирования при записи»?

Question

В More Effective C ++ предоставляются следующие коды

const String::CharProxy String::operator[] (int index) const
{
    return CharProxy(const_cast<String&>(*this), index);
}
String::CharProxy::operator char() const
{
    return theString.value->data[charIndex];
}

Почему бы просто не вернуть char вместо использования const_cast и преобразования CharProxy в char позже?

Answer 1

Вы делаете это так, чтобы String::const_reference (то есть const String::CharProxy), привязанный к возвращаемому значению [], не становилось неожиданно зависшим, когда где-то еще изменяет этот конкретный String.

Вы можете определить, что мутации лишают законной силы все ссылки, но это будет означать, что ваш класс String будет непригодным для использования с широким диапазоном универсального кода и будет называться «Призрачное действие на расстоянии».Например, у вас есть код A, который сначала получает изменяемую ссылку из String, затем код B принимает ссылку на const, а затем A мутирует по своей ссылке.Теперь ссылка на код B стала недействительной, и она не могла заранее проверить, что это произойдет.

Обратите внимание, что прокси-сервер возвращает значение char на , поэтому никакие ссылки не могут выйти.

Answer 2

Если я не ошибаюсь, в вашем случае есть также версия non const , которая может одновременно считывать и записывать символ, а также, как Real Fresh говорит взять указатель / ссылку на символ.

Тогда естественно предложить то же самое для версии const , позволяющей читать символ (не записывая, конечно), а также брать указатель / ref (const) символа.

У вас такое поведение с std :: vector std :: string etc