Прокси объект / эталонные геттеры против сеттеров?

Когда я разрабатываю общий класс, я часто сталкиваюсь со следующими вариантами проектирования:

template<class T>
class ClassWithSetter {
public:
T x() const; // getter/accessor for x
void set_x(const T& x);
...
};
// vs
template<class T>
class ClassWithProxy {
struct Proxy {
Proxy(ClassWithProxy& c /*, (more args) */);
Proxy& operator=(const T& x);  // allow conversion from T
operator T() const;  // allow conversion to T
// we disallow taking the address of the reference/proxy (see reasons below)
T* operator&() = delete;
T* operator&() const = delete;
// more operators to delegate to T?
private:
ClassWithProxy& c_;
};
public:
T x() const; // getter
Proxy x();  // this is a generalization of: T& x();
// no setter, since x() returns a reference through which x can be changed
...
};

Заметки:

• причина, по которой я возвращаюсь T вместо const T& в x() а также operator T() потому что ссылка на x может быть недоступен из класса, если x хранится только косвенным образом (например, предположим, T = std::set<int> но x_ типа T хранится как std::vector<int>)
• Предположим, что кэширование объектов прокси и / или x является не позволил

Мне интересно, каковы были бы некоторые сценарии, в которых один предпочел бы один подход по сравнению с другим, особенно? с точки зрения:

• расширяемость / общность
• эффективность
• усилия разработчика
• усилие пользователя

?

Вы можете предположить, что компилятор достаточно умен, чтобы применять NRVO и полностью встроить все методы.

Текущие личные наблюдения:

(Эта часть не имеет отношения к ответу на вопрос; она просто служит мотивацией и иллюстрирует, что иногда один подход лучше другого.)

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

• MyContainer<T>& (изменяемый, чтение-запись) — позволяет изменять как контейнер, так и его данные
  реализация
• MyContainer<const T>& (изменяемый, только для чтения) — позволяет изменять контейнер, но не его данные
• const MyContainer<T> (неизменяемый, чтение-запись) — позволяет изменять данные, но не контейнер
• const MyContainer<const T> (неизменяемый, только для чтения) — без изменений в контейнере / данных

где под «модификацией контейнера» я подразумеваю такие операции, как добавление / удаление элементов. Если я реализую это наивно с подходом сеттера:

template<class T>
class MyContainer {
public:
void set(const T& value, size_t index) const {  // allow on const MyContainer&
v_[index] = value;  // ooops,
// what if the container is read-only (i.e., MyContainer<const T>)?
}
void add(const T& value);  // disallow on const MyContainer&
...
private:
mutable std::vector<T> v_;
};

Проблема может быть смягчена путем введения большого количества стандартного кода, который опирается на SFINAE (например, путем получения из специализированного помощника по шаблонам, который реализует обе версии set()). Тем не менее, большая проблема заключается в том, что это тормозит общий интерфейс, как нам нужно либо:

• убедитесь, что вызов set () для контейнера только для чтения является ошибкой компиляции
• предоставить другую семантику для метода set () для контейнеров только для чтения

С другой стороны, в то время как подход на основе прокси работает аккуратно:

template<class T>
class MyContainer {
typedef T& Proxy;
public:
Proxy get(const T& value, size_t index) const {  // allow on const MyContainer&
return v_[index];  // here we don't even need a const_cast, thanks to overloading
}
...
};

и общий интерфейс и семантика не нарушены.

Одна проблема, которую я вижу с прокси-подходом, заключается в поддержке Proxy::operator&()
потому что не может быть никакого объекта типа T сохранено / ссылка доступна (см. примечания выше). Например, рассмотрим:

T* ptr = &x();

который не может быть поддержан, если x_ фактически где-то хранится (либо в самом классе, либо доступно через (цепочку) методов, вызываемых для переменных-членов), например:

template<class T>
T& ClassWithProxy::Proxy::operator&() {
return &c_.get_ref_to_x();
}

Означает ли это, что ссылки на прокси-объекты действительно лучше, когда T& доступно (т.е. x_ хранится в явном виде), поскольку позволяет:

• пакетное / отложенное обновление (например, представьте, что изменения распространяются из деструктора прокси-класса)
• лучший контроль над кэшированием
  ?

(В этом случае дилемма между void set_x(const T& value) а также T& x().)

Изменить: я изменил опечатки в констант сеттеров / аксессоров

T& x();
const T& x() const;

T load() const;
void save(const T&);