Семантика ссылки константы C++?

Я предлагаю несколько иное решение, которое имеет ряд преимуществ (особенно в постоянно растущем многопоточном мире). Идея проста и заключается в том, чтобы "фиксировать" свои изменения последними.

Чтобы объяснить на вашем примере, вы просто измените класс 'A' на:

struct A
{
 const B& GetB() const { return m_B; }

 void Foo(const B &b)
 {
  // copy out what we are going to change;
  int itm_value = m_b.m_value;

  // perform operations on the copy, not our internal value
  itm_value += b.m_value;
  itm_value += b.m_value;

  // copy over final results
  m_B.m_value = itm_value ;
 }

protected:
 B m_B;
};

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

Более того, в многопоточной ситуации вы можете выполнить всю операцию, а затем просто проверить в конце, не изменилось ли что-нибудь перед "фиксацией" (оптимистичный подход, который обычно проходит и обычно дает гораздо лучшие результаты, чем блокировка структуры на всю операцию), если изменилось, вы просто отбрасываете значения и пробуете снова (или возвращаете значение о неудаче, если есть что-то, что можно сделать вместо этого).

Кроме того, компилятор обычно может лучше оптимизировать эту операцию, поскольку больше не требуется записывать изменяемые переменные в память (мы заставляем только одно чтение изменяемого значения и одну запись). Таким образом, у компилятора есть возможность просто хранить соответствующие данные в регистре, экономя доступ к кэшу L1, если не промахи кэша. В противном случае компилятор, вероятно, заставит его записывать в память, так как он не знает, какое алиасинг может иметь место (поэтому он не может гарантировать, что эти значения остаются неизменными, если они все локальные, он знает, что это не может быть алиасинг, потому что текущая функция - единственная, которая знает об этом).

Есть много разных вещей, которые могут произойти с исходным кодом. Я не удивлюсь, если некоторые компиляторы (с включенными оптимизациями) действительно произведут код, который даст "ожидаемый" результат, в то время как другие - нет. Все это просто потому, что момент, когда переменные, которые не являются "летучими", действительно записываются/читаются из памяти, не очень хорошо определен в стандартах c++.

Настоящей проблемой здесь является атомарность. Условием функции Foo является то, что ее аргумент не меняется во время использования.

Если бы, например, Foo была указана с аргументом value-argument, т.е. со ссылочным аргументом, проблемы бы не возникло.

Честно говоря, A::Foo() меня смущает больше, чем ваша исходная проблема. Как бы я на это ни смотрел, это должно быть B::Foo(). И внутри B::Foo() проверка на this не была бы такой уж необычной.

Иначе я не вижу, как можно указать общее правило для этого случая. И сохранить здравомыслие членов команды.

Исходя из прошлого опыта, я бы рассматривал это как обычную ошибку и различал бы два случая: (1) B - маленький и (2) B - большой. Если B маленький, то просто сделайте A::getB(), чтобы вернуть копию. Если B большой, то у вас нет выбора, кроме как обработать случай, когда объекты B могут быть и rvalue и lvalue в одном и том же выражении.

Если у вас постоянно возникают такие проблемы, я бы сказал, что более простым правилом будет всегда возвращать копию объекта вместо ссылки. Потому что довольно часто, если объект большой, то вам все равно придется обрабатывать его иначе, чем остальные.

Мой глупый ответ, я оставляю его здесь на всякий случай, если кто-то другой придет к такой же плохой идее:

Проблема в том, что я думаю, что упомянутый объект не является const ( B const & vs const B & ), только ссылка в вашем коде является const.