RAII: инициализация элемента данных в методе const

Это не RAII. В RAII вы должны инициализировать его в конструкторе, который решит ваши проблемы.

Итак, вы используете Lazy. Будь то ленивая инициализация или ленивые вычисления.

Если вы не используете mutable, вас ждет мир боли.

Конечно, вы можете использовать const_cast, но что, если кто-то это сделает:

static const MyClass Examplar;

И компилятор решает, что это хороший кандидат на постоянную память? Что ж, в этом случае эффекты const_cast не определены. В лучшем случае ничего не происходит.

Если вы все еще хотите следовать по пути const_cast, сделайте это так же, как R Samuel Klatchko.

Если вы подумали и думаете, что, вероятно, есть лучшая альтернатива, вы можете решить обернуть свою переменную. Если бы он был в своем собственном классе, имея всего 3 метода: get, set и load_from_database, вы бы не беспокоились о том, что это mutable.

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

Как уже отмечал Матье, то, что вы здесь пытаетесь сделать, имеет мало общего (если вообще есть) с RAII. Точно так же я сомневаюсь, что любая комбинация const и mutable действительно поможет. const и mutable изменяют тип и одинаково применяются ко всему доступу к объекту этого типа.

Кажется, вам нужно, чтобы небольшой объем кода имел доступ на запись, а все остальное - только на чтение значения. Учитывая базовый дизайн C ++ (и большинства подобных языков), правильный способ сделать это - переместить переменную в отдельный класс с небольшим количеством кода, которому требуется доступ для записи как часть (или, возможно, друг друга). ) этого класса. Остальному миру предоставляется доступ только для чтения через интерфейс класса (то есть функция-член, которая извлекает значение).

Опубликованный вами (предположительно урезанный) MyClass довольно близок к правому - вам просто нужно использовать его отдельно, а не как часть более крупного класса с множеством других членов. Главное, что нужно изменить: 1) имя с MyClass на что-то вроде lazy_int и 2) (по крайней мере, по моим предпочтениям) get_value(), вероятно, следует переименовать в operator int(). Да, m_value, вероятно, должен быть изменяемым, но это не позволяет другому коду записывать значение просто потому, что другой код вообще не имеет доступа к самому значению.

Затем вы встраиваете объект этого типа в свой более крупный класс. Код в этом внешнем классе может рассматривать его как int (только для чтения) благодаря своему operator int(), но не может его записать просто потому, что класс не позволяет это сделать.

[ПОСМОТРЕТЬ МА! БЕЗ КАСТОВ! :))]

struct DBValue 
{
  int get_value();

private:
  void load_from_database();
  int value;
};

struct MyClass 
{
  MyClass(): db_value(new DBValue()) {}
  ~MyClass() { delete db_value; } 

  int get_value() const;

private:
  DBValue * const db_value;
};

int MyClass::get_value() const
{
  return db_value->get_value(); // calls void load_from_database() if needed
}

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

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

Если ваш метод изменяет состояние объекта (например, изменяя состояние базовой базы данных), тогда метод не должен быть константным. В этом случае у вас должен быть отдельный, неконстантный load-метод, который должен быть вызван перед вызовом const геттера.

Этот метод не потребует ни const_cast, ни mutable и сделает потенциально дорогостоящую операцию явной.