Objects of types defined in the C++ standard library may be moved from (12.8). Move operations may be explicitly specified or implicitly generated. Unless otherwise specified, such moved-from objects shall be placed in a valid but unspecified state.

Objects of types defined in the C++ standard library may be moved from (12.8). Move operations may be explicitly specified or implicitly generated. Unless otherwise specified, such moved-from objects shall be placed in a valid but unspecified state.

R>Здесь проблема скорее в выбранной аналогии, чем собственно в move семантике. Замени "Коробка и медведь" на "медведь и опилки" и степень удивленности резко снизится

The implementation of the underlying type for an original type T is
straightforward and could be automated. U = UnderlyingType(T) always has the same layout as
the header of T. The copy constructor and assignment for U just copy the bits; they
do not construct a copy of the remote parts of T.

template<typename T> 
requires(Regular(T)) 
void swap(T& x, T& y) 
{ 
    UnderlyingType(T) tmp = underlying_ref (x) ; 
    underlying_ref (x) = underlying_ref (y) ; 
    underlying_ref (y) = tmp; 
}

void test(bool condition)
{
    A a,b;
    if(condition)
    {
        b = std::move(a);    
    }    
    //а пусто или полно? В статике не узнать.
    //сейчас деструктор будет вызван вне зависимости от.
}

E>Раз очень много чего, то, наверное, не трудно привести три-пять примеров? А то я не уверен, что мы одинаково понимаем слово "упростилось"...

template <typename T>
class Tree : public std::vector<Tree<T>>
{
public:

  template <typename...U>
  explicit Tree(U&&...u) : m(std::forward<U>(u)...) {}
  
  // Movable but non-copyable
  Tree(Tree&&) = default;
  Tree& operator = (Tree&&) = default;

  T& operator* () { return m; }
  const T& operator* () const { return m; }

private:
  T m;
};

E>Если мы RAII объект мувим, то на старом месте остаётся существующий объект, которому не соответствует никакой ресурс.

E>Речь идёт о возврате из функций? Чаще всего с этим справлялось RVO…

class PhysicalWorld
{
public:

  PhysicalWorld();
  PhysicalWorld(PhysicalWorld&&) = default;
  PhysicalWorld& operator = (PhysicalWorld&&) = default;

  // Задолбишься пыль глотать.
  // Да и нафиг не нужно никому.
  // Поэтому non-copyable
  PhysicalWorld(const PhysicalWorld&) = delete;
  PhysicalWorld& operator = (const PhysicalWorld&) = delete;

private:
  class Impl;
  std::inique_ptr<Impl> m {};
};

template<typename T>
void move_vector_item( void* dst, T* src )
{
    assert( src != 0 && dst != 0 && dst != src );
    ::new( dst ) T( *src );
    src->~T()
}


template<typename T>

void move_vector_buffer( void* dst, T* begin, T* end )
{
    //  Тут выбираем правильное направление обхода и в цикле зовём move_vector_item
}

E>>Если мы RAII объект мувим, то на старом месте остаётся существующий объект, которому не соответствует никакой ресурс.

E>Грубо говоря в этом-то и состоит главная проблема

std::string  str1 = fun1();
std::string  str2 = fun2();
std::string  str3 = fun3();

std::string  strResult = str1 + str2 + str3 + fun4();  // какая здесь проблема?

VT>Я согласен с таким подходом и тоже стараюсь его придерживаться. Собственно, исходя из конечного эффекта, который функция move производит в выражении, в котором она употребляется, я и считаю её название подходящим (тоже ИМХО) .

move(x) means 'give me an rvalue reference to x.' That is, std::move(x) does not move anything; instead, it allows a user to move x. It would have been better if move() had been called rval(), but the name move() has been used for this operation for years

std::vector<T> dst;
src.move_to( dst )

std::vector<T> dst = std::move( src );

move(x) means 'give me an rvalue reference to x.' That is, std::move(x) does not move anything; instead, it allows a user to move x. It would have been better if move() had been called rval(), but the name move() has been used for this operation for years

SomeClass b = ....
//...
SomeClass a = b + SomeClass(...); // такое?

SomeClass a = ....
func(std::move(a)); // такое?

#include <memory>
#include <iostream>
using namespace std;

class A
{
public:
  A(){}
  A(A&&)=delete;
  A&& move_me(){return std::move(*this); }
};

int main() {
    
  A a;
    
  A&& rrA = a.move_me();
    
  std::cout << "ok\n";
  return 0;
}

std::vector<T> dst;
E>src.move_to( dst )

std::vector<T> dst = std::move( src );

void test(bool condition)
{
    A a,b;
    if(condition)
    {
        b = std::move(a);    
    }    
    a.doSomething();
}

void register(shared_ptr<R> smth);

void init() {
  shared_ptr<R> r(new R);
  shared_ptr<R> shadow = r;
  somehow_setup(*r);
  register(r);  // move подразумевается, но синтаксически не оформлено
  change_something(*r); // а регистратор-то готов к тому, что мы что-то на ходу поменяли?
  // а даже если бы и было настоящее move c обнулением источника, то что?
  change_something(*shadow);
  // а даже если и на чтение: регистратор же может отдать содержимое в распоряжение другого потока...
  read_something(*shadow);
}

void f( void* to_fill )
{
    // тут код, вычисляющий какие-то params
    ::new( to_fill ) ResType( params ) 
}

V>Ну С++ не требует от вас использовать move, куда уж прозрачнее . Move нужен тех случаев, где он нужен и приносит выгоду, а также для явного выражения семантики объектов, которые принципиально не копируемые. Теперь, если нужно, это можно выразить явно и компилятор все будет проверять за вас.

  std::cout << "&  a" <<   &a << " -- ok\n";
  std::cout << "&rrA" << &rrA << " -- ok\n";

&  a0x7fff2679d2ff -- ok
&rrA0x7fff2679d2ff -- ok

std::vector<T> dst;
E>>src.move_to( dst )

std::vector<T> dst = std::move( src );

E>И в этом случае, кстати, можно было бы не требовать наличие открытого конструктора копии

struct NonCopyableNonMovable
{
    NonCopyableNonMovable(int, double){}

    NonCopyableNonMovable(NonCopyableNonMovable &&) = delete;
    NonCopyableNonMovable(const NonCopyableNonMovable &) = delete;

    NonCopyableNonMovable &operator=(NonCopyableNonMovable &&) = delete;
    NonCopyableNonMovable &operator=(const NonCopyableNonMovable &) = delete;
};

NonCopyableNonMovable foo()
{
    return {1, .5};
}

int main()
{
    auto &&x = foo();
}

struct NonCopyableNonMovable
{
    NonCopyableNonMovable(int, double){}

    NonCopyableNonMovable(NonCopyableNonMovable &&) = delete;
    NonCopyableNonMovable(const NonCopyableNonMovable &) = delete;

    NonCopyableNonMovable &operator=(NonCopyableNonMovable &&) = delete;
    NonCopyableNonMovable &operator=(const NonCopyableNonMovable &) = delete;
};

NonCopyableNonMovable foo()
{
    return NonCopyableNonMovable{1, .5};
}

int main()
{
    auto x = foo();
}

EP>NonCopyableNonMovable foo()
EP>{
EP>    return NonCopyableNonMovable{1, .5};
EP>}

EP>int main()
EP>{
EP>    auto x = foo();
EP>}
EP>

int main()
{
    NonCopyableNonMovable t{1, .5};
    auto x = std::move(t);
}

R>int main()
R>{
R>    NonCopyableNonMovable t{1, .5};
R>    auto x = std::move(t);
R>}
R>

struct NonCopyableNonMovable
{
    NonCopyableNonMovable(int, double){}

    NonCopyableNonMovable(NonCopyableNonMovable &&) = delete;
    NonCopyableNonMovable(const NonCopyableNonMovable &) = delete;

    NonCopyableNonMovable &operator=(NonCopyableNonMovable &&) = delete;
    NonCopyableNonMovable &operator=(const NonCopyableNonMovable &) = delete;
};

NonCopyableNonMovable foo();

NonCopyableNonMovable &&bar();

int main()
{
    auto   x = foo(); // C++11: fails to compile | C++17: compiles OK
    auto &&y = foo(); // C++11: compiles OK      | C++17: compiles OK
    auto   z = bar(); // C++11: fails to compile | C++17: fails to compile
    auto &&t = bar(); // C++11: compiles OK      | C++17: compiles OK
}

NonCopyableNonMovable g(); // не важно как она там внутри устроена, но

NonCopyableNonMovable f()
{
    return g(); // что тут пишем?
}