Всегда объявлять std :: mutex как изменчивый в C ++ 11?

Нет. Однако большую часть времени они будут.

Хотя полезно думать о const как «потокобезопасный» и mutable как «(уже) поточно-безопасный», const все еще фундаментально связано с понятием обещания «я не буду изменять это значение». Так будет всегда.

У меня долгий ход мыслей, так что терпите меня.

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

Например:

bool is_even(const unsigned x)
{
return (x % 2) == 0;
}

bool is_prime(const unsigned x)
{
return /* left as an exercise for the reader */;
}

template <typename Iterator>
void print_special_numbers(const Iterator first, const Iterator last)
{
for (auto iter = first; iter != last; ++iter)
{
const auto& x = *iter;
const bool isEven = is_even(x);
const bool isPrime = is_prime(x);

if (isEven && isPrime)
std::cout << "Special number! " << x << std::endl;
}
}

Почему типы параметров для is_even а также is_prime отмеченный const? Потому что с точки зрения реализации изменение числа, которое я тестирую, было бы ошибкой! Зачем const auto& x? Потому что я не собираюсь менять это значение, и я хочу, чтобы компилятор кричал на меня, если я это сделаю. То же самое с isEven а также isPrime: результат этого теста не должен меняться, поэтому применяйте его.

Конечно const функции-члены просто способ дать this тип формы const T*, Там написано «было бы ошибкой в ​​реализации, если бы я сменил некоторых своих членов».

mutable говорит «кроме меня». Отсюда и «старое» понятие «логически постоянное». Рассмотрим общий вариант использования, который он дал: член мьютекса. Вы необходимость заблокировать этот мьютекс, чтобы убедиться, что ваша программа корректна, поэтому вам нужно ее изменить. Вы не хотите, чтобы функция была неконстантной, потому что было бы ошибкой изменять любой другой элемент. Итак, вы делаете это const и пометить мьютекс как mutable,

Ничто из этого не имеет отношения к безопасности потока.

Я думаю, что это слишком далеко, чтобы сказать, что новые определения заменяют старые идеи, данные выше; они просто дополняют его с другой точки зрения безопасности потоков.

Теперь Трава дает точку зрения, что если у вас есть const функции, они должны быть поточно-ориентированными для безопасного использования стандартной библиотекой. Как следствие этого, единственные участники, которых вы действительно должны пометить как mutable те, которые уже потокобезопасны, потому что они могут быть изменены с const функция:

struct foo
{
void act() const
{
mNotThreadSafe = "oh crap! const meant I would be thread-safe!";
}

mutable std::string mNotThreadSafe;
};

Итак, мы знаем, что потокобезопасные вещи Можно быть отмеченным как mutableВы спросите: они должны быть?

Я думаю, что мы должны рассмотреть оба взгляда одновременно. С новой точки зрения Херб, да. Они потокобезопасны, поэтому их не нужно связывать с постоянством функции. Но только потому, что они Можно безопасно быть освобожденным от ограничений const не значит, что они должны быть. Мне все еще нужно подумать: будет ли ошибка в реализации, если я изменю этот элемент? Если так, то это не должно быть mutable!

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

В этом случае вы должны ошибиться на стороне mutable,

Херб говорил слишком слабо, когда он дал const_cast Пример объявил это безопасным. Рассматривать:

struct foo
{
void act() const
{
const_cast<unsigned&>(counter)++;
}

unsigned counter;
};

Это безопасно в большинстве случаев, кроме случаев, когда foo сам объект const:

foo x;
x.act(); // okay

const foo y;
y.act(); // UB!

Это рассматривается в другом месте на SO, но const foo, подразумевает counter член также constи модифицирование const объект неопределенного поведения.

Вот почему вы должны ошибиться на стороне mutable: const_cast не совсем дает вам такие же гарантии. Имел counter был отмечен mutable, это не было бы const объект.

Хорошо, так что если нам это нужно mutable в одном месте нам это нужно везде, и нам просто нужно быть осторожным в тех случаях, когда мы этого не делаем. Конечно, это означает, что все потокобезопасные элементы должны быть помечены mutable затем?

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

struct threadsafe_container_wrapper
{
void missing_function_I_really_want()
{
container.do_this();
container.do_that();
}

const_container_view other_missing_function_I_really_want() const
{
return container.const_view();
}

threadsafe_container container;
};

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

Я думаю, что Херб спорит в большинстве случаев, когда мы будем использовать mutable мы также используем какой-то внутренний (потокобезопасный) объект синхронизации, и я согласен. Поэтому его точка зрения работает большую часть времени. Но существуют случаи, когда я просто случаться иметь потокобезопасный объект и просто рассматривать его как еще один элемент; в этом случае мы возвращаемся к старому и фундаментальному использованию const,