The idea of movable is that a value can be relocated to a new position without requiring additional resources (and hence without throwing an exception) with complexity proportional to the
sizeof() the object as opposed to copy which has complexity proportional to the area of the object. Iterators to remote parts remain valid after a move. Move can be used in place of copying when the value of the item being copied from will not be used again. Because of this move can be used in place of copying when the item being copied from is an r-value (an unnamed temporary).
Ideally, the concept Movable would be part of Regular. However, because of current language restrictions and history, the best we can do at this time is approximate this concept. We document it as a refinement of Regular and use it as an optimization of copy.
- Refinement Of:
- Valid Expressions:
- Given a type
Twhich models concept_movable:
T b; T a(adobe::move_from<T>(b));
- Required Signatures:
- Expression Semantics:
Given a type
Twhich models Movable, a function (which may be partial)
remote_identity(T) -> Iwhich return the identity of a non-local part of T and a function
f(I& id) -> Twhich sets /c id to the remote_identity of it's result.
I id = remote_identity(b); T a(adobe::move_from<T>(b)); assert(id == remote_identity(a));// explicit move-ctor
I id; T a = f(id); assert(id == remote_identity(a));// move-ctor with r-value (RVO)
I id; T a; a = f(id); assert(id == remote_identity(a));// move-assign with r-value
- Type(s) Modeling this Concept:
Because movable currently relies on the return value optimization being implemented by the compiler and being applied as needed we cannot rely on the axioms holding in practice although they often do. We can only rely on move as a potential optimization of copy. If moving a type is required then swap should be used instead. See Assignable.
The move-ctor is rarely invoked directly but rather is called by
adobe::move(a). The required signature are tested for with
- See Also: