I was surprised this didn't show up in my search results, I thought someone would've asked this before, given the usefulness of move semantics in C++11:
(Reasons other than compatibility issues with existing code, that is.)
Herb's answer (before it was edited) actually gave a good example of a type which shouldn't be movable: std::mutex.
The OS's native mutex type (e.g. pthread_mutex_t on POSIX platforms) might not be "location invariant" meaning the object's address is part of its value. For example, the OS might keep a list of pointers to all initialized mutex objects. If std::mutex contained a native OS mutex type as a data member and the native type's address must stay fixed (because the OS maintains a list of pointers to its mutexes) then either std::mutex would have to store the native mutex type on the heap so it would stay at the same location when moved between std::mutex objects or the std::mutex must not move. Storing it on the heap isn't possible, because a std::mutex has a constexpr constructor and must be eligible for constant initialization (i.e. static initialization) so that a global std::mutex is guaranteed to be constructed before the program's execution starts, so its constructor cannot use new. So the only option left is for std::mutex to be immovable.
The same reasoning applies to other types that contain something that requires a fixed address. If the address of the resource must stay fixed, don't move it!
There is another argument for not moving std::mutex which is that it would be very hard to do it safely, because you'd need to know that noone is trying to lock the mutex at the moment it's being moved. Since mutexes are one of the building blocks you can use to prevent data races, it would be unfortunate if they weren't safe against races themselves! With an immovable std::mutex you know the only things anyone can do to it once it has been constructed and before it has been destroyed is to lock it and unlock it, and those operations are explicitly guaranteed to be thread safe and not introduce data races. This same argument applies to std::atomic<T> objects: unless they could be moved atomically it wouldn't be possible to safely move them, another thread might be trying to call compare_exchange_strongon the object right at the moment it's being moved. So another case where types should not be movable is where they are low-level building blocks of safe concurrent code and must ensure atomicity of all operations on them. If the object value might be moved to a new object at any time you'd need to use an atomic variable to protect every atomic variable so you know if it's safe to use it or it's been moved ... and an atomic variable to protect that atomic variable, and so on...
I think I would generalize to say that when an object is just a pure piece of memory, not a type which acts as a holder for a value or abstraction of a value, it doesn't make sense to move it. Fundamental types such as int can't move: moving them is just a copy. You can't rip the guts out of an int, you can copy its value and then set it to zero, but it's still an int with a value, it's just bytes of memory. But an int is still movable in the language terms because a copy is a valid move operation. For non-copyable types however, if you don't want to or can't move the piece of memory and you also can't copy its value, then it's non-movable. A mutex or an atomic variable is a specific location of memory (treated with special properties) so doesn't make sense to move, and is also not copyable, so it's non-movable.
std::mutex while another thread is locking it any more that it has to protect against destroying a std::mutex which another thread is trying to lock it. Both represent severe programming errors on the part of the user. A mutex allows you to create synchronized access to other data; it doesn't lift the requirement of proper lifetime management for the mutex object itself. –
Prance std::mutex was that it be eligible for static initialization, so a global std::mutex is guaranteed to be usable before dynamic initialization begins, precisely to simplify "proper lifetime management". Knowing it's non-movable also simplifies things. –
Uncleanly unique_ptr. Or you can forbid moving and not have to answer the question :-) –
Facetious MutexForMovableTypes class, that wraps a mutex and is movable and whose move constructor does nothing to the source. That avoids writing error-prone boilerplate in the move ctor of the class that has one as a data member. –
Facetious unique_ptr that you hold it by, your class could allow you to fine-tune your locking granularity if it's a shared_ptr :-) –
Facetious MutexForMovableTypes, which wraps an object but does nothing when copied/assigned. It allows a class that contains it as a data member to have implicitly-defined copy/move operations but not update that member. Useful when e.g. a class has a GUID or other identity which should be fixed and not transferred (like its address). –
Uncleanly std::lock(this->mx, that.mx) which is deadlock-free, of course :) –
Uncleanly mutex object to begin with. Yes, if you have a unique_ptr then the situation changes entirely, but I wasn't talking about that. –
Tillio int that is movable. How about an int that stores its overflow state (as signed overflow is undefined behavior, we have lots of latitude). When copied, both have the overflow flag -- when moved-from, the overflow flag travels to the new int. Assigning to the int while it has an overflow flag causes a trap to be set (exception, etc) as you lost track of the overflow. has_overflow and clear_overflow let you read/remove said overflow. As everything happens after UB, I think this is legal? Second question: is it a moveable int? –
People mutex(mutex&&) isn't = delete, it's : mutex() {}. That is to say, a mutex should be movable, but it's effectively an empty type for moving purposes. –
Tillio Short answer: If a type is copyable, it should also be moveable. However, the reverse is not true: some types like std::unique_ptr are moveable yet it doesn't make sense to copy them; these are naturally move-only types.
Slightly longer answer follows...
There are two major kinds of types (among other more special-purpose ones such as traits):
Value-like types, such as int or vector<widget>. These represent values, and should naturally be copyable. In C++11, generally you should think of move as an optimization of copy, and so all copyable types should naturally be moveable... moving is just an efficient way of doing a copy in the often-common case that you don't need the original object any more and are just going to destroy it anyway.
Reference-like types that exist in inheritance hierarchies, such as base classes and classes with virtual or protected member functions. These are normally held by pointer or reference, often a base* or base&, and so do not provide copy construction to avoid slicing; if you do want to get another object just like an existing one, you usually call a virtual function like clone. These do not need move construction or assignment for two reasons: They're not copyable, and they already have an even more efficient natural "move" operation -- you just copy/move the pointer to the object and the object itself doesn't have to move to a new memory location at all.
Most types fall into one of those two categories, but there are other kinds of types too that are also useful, just rarer. In particular here, types that express unique ownership of a resource, such as std::unique_ptr, are naturally move-only types, because they are not value-like (it doesn't make sense to copy them) but you do use them directly (not always by pointer or reference) and so want to move objects of this type around from one place to another.
swap as a no-op (because that's the correct implementation -- it measures the lifetime of the storage location, which is unaffected by the object's data/movement/etc.). Obviously if you wouldn't want to implement move then you wouldn't want to implement swap either, but they do it and it's the correct thing to do. –
Tillio std::mutex was immovable, as POSIX mutexes are used by address. –
Playpen std::mutex is certainly the wrong example. std::mutex cannot be moved nor copied. std::unique_lock is the movable lockable type. –
Mannuela std::mutex isn't movable, it doesn't own a resource, it is a resource. The native OS mutex type can/should be embedded right in the std::mutex object to allow it to be statically initialized via its constexpr constructor. No resource allocation involved. std::thread would be a better example. –
Uncleanly std::mutex the good example would be std::unique_lock. –
Malapert Actually when I search around, I found quite some types in C++11 are not movable:
mutex types(recursive_mutex , timed_mutex, recursive_timed_mutex, condition_variabletype_info error_categorylocale::facet random_deviceseed_seqios_basebasic_istream<charT,traits>::sentrybasic_ostream<charT,traits>::sentryatomic typesonce_flagApparently there is a discussion on Clang: https://groups.google.com/forum/?fromgroups=#!topic/comp.std.c++/pCO1Qqb3Xa4
iterators / iterator adaptors should be edited away as C++11 has move_iterator? –
Vexillum std::move_iterator (which has a totally different purpose, anyway). Likewise are std::time_points and std::durations (and maybe others I didn't check/think about more thoroughly). –
Allopath std::reference_wrapper. Ok, the others indeed seem to be non-movable. –
Allopath iterator/iterator adaptors away from answer. Also I've posted another question, regarding iterator movable: #14314910 –
Vexillum cppreference correctly mirrors the standard there (not that it would make much sense for those types to be non-copyable by simple reasoning). –
Allopath ios_base, type_info, facet), 3. assorted weird stuff (sentry). Probably the only unmovable classes an average programmer will write are in the second category. –
Gayl Another reason I've found - performance. Say you have a class 'a' which holds a value. You want to output an interface which allows a user to change the value for a limited time (for a scope).
A way to achieve this is by returning a 'scope guard' object from 'a' which sets the value back in its destructor, like so:
class a
{
int value = 0;
public:
struct change_value_guard
{
friend a;
private:
change_value_guard(a& owner, int value)
: owner{ owner }
{
owner.value = value;
}
change_value_guard(change_value_guard&&) = delete;
change_value_guard(const change_value_guard&) = delete;
public:
~change_value_guard()
{
owner.value = 0;
}
private:
a& owner;
};
change_value_guard changeValue(int newValue)
{
return{ *this, newValue };
}
};
int main()
{
a a;
{
auto guard = a.changeValue(2);
}
}
If I made change_value_guard movable, I'd have to add an 'if' to its destructor that would check if the guard has been moved from - that's an extra if, and a performance impact.
Yeah, sure, it can probably be optimized away by any sane optimizer, but still it's nice that the language (this requires C++17 though, to be able to return a non-movable type requires guaranteed copy elision) does not require us to pay that if if we're not going to move the guard anyway other than returning it from the creating function (the dont-pay-for-what-you-dont-use principle).
© 2022 - 2024 — McMap. All rights reserved.
+1from me) with a very thorough answer from Herb (or his twin, as it seems), so I made it an FAQ entry. If someone objects just ping me at the lounge, so this can be discussed there. – OdomT x = std::move(anotherT);being legal" are not equivalent. The latter is a move-request which might fall back on the copy ctor in case T has no move ctor. So, what does "movable" mean exactly? – Rapallo