Уважаемые коллеги, какие способы применения mutable вы знаете?

Порывшись по форумам, нашел следующее:
1) Кеширование результатов тяжелых операций (ленивая загрузка сюда тоже попадает)
2) Синхронизационные примитивы (включая счетчик ссылок)
3) Надругательство над архитектурой

Еще идеи? Как еще можно изменить микросостояние объекта не меняя его макросостояние?

Меня интересует, может ли mutable быть полностью заменен кешированием не уровне рантайма? Насколько это полноценная замена?

T.e. вместо

//C++
Data getData() const
{
    if(!hasData)
    {
        hasData = true;
        data = DoGetData();
    }
    return data;
}

Написать

// Hypotetic lang
Data getData() const caching
{
    return DoGetData();
}

http://alenacpp.blogspot.com/2005/10/mutable-constcast.html

Здравствуйте, Uzumaki Naruto, Вы писали:

UN>http://alenacpp.blogspot.com/2005/10/mutable-constcast.html

Там ничего нового — кеширование и синхронизация. Или я что-то пропустил?

Здравствуйте, kjam, Вы писали:

K>Здравствуйте, Uzumaki Naruto, Вы писали:

UN>>http://alenacpp.blogspot.com/2005/10/mutable-constcast.html

K>Там ничего нового — кеширование и синхронизация. Или я что-то пропустил?

А вы что-то еще ищите?

Здравствуйте, Uzumaki Naruto, Вы писали:

UN>А вы что-то еще ищите?

Ты вопрос-то прочитал, прежде чем бросаться отвечать?

Порывшись по форумам, нашел следующее:
1) Кеширование результатов тяжелых операций (ленивая загрузка сюда тоже попадает)
2) Синхронизационные примитивы (включая счетчик ссылок)
3) Надругательство над архитектурой

Еще идеи?

You will always get what you always got
  If you always do  what you always did

Здравствуйте, kjam, Вы писали:

K>Еще идеи? Как еще можно изменить микросостояние объекта не меняя его макросостояние?


Ну, например, может происходить оптимизация чего-то в фоне...

Здравствуйте, kjam, Вы писали:

K>Уважаемые коллеги, какие способы применения mutable вы знаете?

K>Порывшись по форумам, нашел следующее:
K>1) Кеширование результатов тяжелых операций (ленивая загрузка сюда тоже попадает)
K>2) Синхронизационные примитивы (включая счетчик ссылок)
K>3) Надругательство над архитектурой

K>Еще идеи?
Ну, в пункт 3 можно вообще все запихнуть

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

You will always get what you always got
  If you always do  what you always did

Здравствуйте, kjam, Вы писали:

K>Еще идеи? Как еще можно изменить микросостояние объекта не меняя его макросостояние?

Из безумного (3. надругательство...)
Пусть у нас есть связка объектов 1<--->1
Причём второй объект не полиморфный (либо его полиморфизм как-то совсем уж неявно реализуется)
В этом случае можно держать оба объекта в одном блоке памяти.
mutable разрывает константность между ними, подобно тому, как разрывается константность через указатель.

struct A
{
  .....
  mutable B b;
};
// вместо
struct A
{
  .....
  B* /*const*/ pb;
};

Только это не микросостояние уже, а просто архитектурный хак.

Здравствуйте, kjam, Вы писали:

K>Уважаемые коллеги, какие способы применения mutable вы знаете?

K>Порывшись по форумам, нашел следующее:
K>1) Кеширование результатов тяжелых операций (ленивая загрузка сюда тоже попадает)
K>2) Синхронизационные примитивы (включая счетчик ссылок)
K>3) Надругательство над архитектурой

K>Еще идеи? Как еще можно изменить микросостояние объекта не меняя его макросостояние?

тут Кодт про связку упомянул, и сразу linked_ptr вспомнился. Там мутабл к месту используется.

On 11/27/2011 02:48 PM, kjam wrote:

> Еще идеи? Как еще можно изменить микросостояние объекта не меняя его макросостояние?

Ещё есть случай вызова какого-нибудь старого или С-шного API, где
константности параметра не прописаны, но фактически параметры константные.

Здравствуйте, MasterZiv, Вы писали:

MZ>Ещё есть случай вызова какого-нибудь старого или С-шного API,

Не «или», а «и». В C есть const.

MZ>где константности параметра не прописаны, но фактически параметры константные.

На мой взгляд, в таком случае более уместен const_cast, хорошо изолированный в одной функции—обёртке над тем API, чем полное разрешение всем const-функциям объекта менять поле.