Using mutable to allow modification of object in unordered_set - c++

Question

Please consider the following code:
#include <iostream>
#include <unordered_set>
struct MyStruct
{
int x, y;
double mutable z;
MyStruct(int x, int y)
: x{ x }, y{ y }, z{ 0.0 }
{
}
};
struct MyStructHash
{
inline size_t operator()(MyStruct const &s) const
{
size_t ret = s.x;
ret *= 2654435761U;
return ret ^ s.y;
}
};
struct MyStructEqual
{
inline bool operator()(MyStruct const &s1, MyStruct const &s2) const
{
return s1.x == s2.x && s1.y == s2.y;
}
};
int main()
{
std::unordered_set<MyStruct, MyStructHash, MyStructEqual> set;
auto pair = set.emplace(100, 200);
if (pair.second)
pair.first->z = 300.0;
std::cout << set.begin()->z;
}
I am using mutable to allow modification of the member z of MyStruct. I would like to know if this is ok and legal, since the set is a) unordered and b) I am not using z for hashing or equality?

Answer 1

I would say this is a perfect use of the "Mutable" keyword.
The mutable keyword is there to mark members that are not part of the "state" of the class (ie they are some form of cached or intermediate value that does not represent the logical state of the object).
Your equality operator (as well as other comparators (or any function that serializes the data) (or function that generates a hash)) define the state of the object. Your equality comparitor does not use the member 'z' when it checks the logical state of the object so the member 'z' is not part of the state of the class and is therefore illegable to use the "mutable" accessor.
Now saying that. I do think the code is very brittle to write this way. There is nothing in the class that stops a future maintainer accidentally making z part of the state of the class (ie adding it to the hash function) and thus breaking the pre-conditions of using it in std::unordered_set<>. So you should be very judicious in using this and spend a lot of time writing comments and unit tests to make sure the preconditions are maintained.
I would also look into "#Andriy Tylychko" comment about breaking the class into a const part and a value part so that you could potentially use it as part of a std::unordered_map.

Answer 2

The problem is that z is not part of the state of the object only in the context of that particular kind of unordered_set.
If one continues this route one will end up making everything mutable just in case.
In general, what you are asking is not possible because the element hash would need to be recomputed automatically on the modification of the element.
The most general thing you can do is to have a protocol for element modification, similar to the modify function in Boost.MultiIndex https://www.boost.org/doc/libs/1_68_0/libs/multi_index/doc/reference/ord_indices.html#modify.
The code is ugly, but thanks to the existence of extract it can be made fairly efficient when it matters (well, still your particular struct will not benefit from move).
template<class UnorderedSet, class It, class F>
void modify(UnorderedSet& s, It it, F f){
It h = it; ++h;
auto val = std::move(s.extract(it).value());
f(val);
s.emplace_hint(h, std::move(val) );
}
int main(){
std::unordered_set<MyStruct, MyStructHash, MyStructEqual> set;
auto pair = set.emplace(100, 200);
if (pair.second) modify(set, pair.first, [](auto&& e){e.z = 300;});
std::cout << set.begin()->z;
}
(code not tested)
#JoaquinMLopezMuños (author of Boost.MultiIndex) suggested reinserting the whole node. I think that would work like this:
template<class UnorderedSet, class It, class F>
void modify(UnorderedSet& s, It it, F f){
It h = it; ++h;
auto node = s.extract(it);
f(node.value());
s.insert(h, std::move(node));
}
EDIT2: Final tested code, needs C++17 (for extract)
#include <iostream>
#include <unordered_set>
struct MyStruct
{
int x, y;
double z;
MyStruct(int x, int y)
: x{ x }, y{ y }, z{ 0.0 }
{
}
};
struct MyStructHash
{
inline size_t operator()(MyStruct const &s) const
{
size_t ret = s.x;
ret *= 2654435761U;
return ret ^ s.y;
}
};
struct MyStructEqual
{
inline bool operator()(MyStruct const &s1, MyStruct const &s2) const
{
return s1.x == s2.x && s1.y == s2.y;
}
};
template<class UnorderedSet, class It, class F>
void modify(UnorderedSet& s, It it, F f){
auto node = s.extract(it++);
f(node.value());
s.insert(it, std::move(node));
}
int main(){
std::unordered_set<MyStruct, MyStructHash, MyStructEqual> set;
auto pair = set.emplace(100, 200);
if(pair.second) modify(set, pair.first, [](auto&& e){e.z = 300;});
std::cout << set.begin()->z;
}

Answer 3

The typical used mutable is to allow a const method to change a data member that does not form part of an object’s fundamental state e.g. a lazily evaluated value derived from the object’s non-mutable data.
Declaring public data members mutable is not good a practice, you are allowing the objects state to be changed externally even when that object is marked const.
In your example code, you have used mutable because (based on your comment), your code would not compile without it. Your code would not compile because the iterator returned from emplace is const.
There are two incorrect ways to solve this problem, one is the use of the mutable keyword, another, almost as bad, is to cast the const reference into a non-const reference.
The emplace method is intended to construct an object directly into the collection and avoid a copy constructor call. This is a useful optimization but you shouldn’t use it if it will compromise the maintainability of your code. You should either initialize z in your constructor or you should not use emplace to add the object to the set, instead set the value of z and then insert the object into your set.
If your object never needs to change after construction, you should make your class/struct immutable by either declaring them const or declaring the data members private and adding non-mutating accessor methods (these should be declared const).