Question

在2013年的GoingNative演讲中，Scott Meyers指出std::move并不保证生成的代码实际上会执行一次移动。

示例：

void foo(std::string x, const std::string y) {
  std::string x2 = std::move(x); // OK, will be moved
  std::string y2 = std::move(y); // compiles, but will be copied
}

这里，不能应用移动构造函数，但由于重载分辨率，将使用普通的复制构造函数。这种后备选项对于向后兼容C ++ 98代码可能至关重要，但在上面的示例中，它很可能不是程序员想要的。

有没有办法强制调用移动构造函数？

例如，假设您要移动一个巨大的矩阵。如果您的应用程序确实依赖于要移动的Matrix，那么如果无法移动则立即获得编译错误会很棒。（否则，您的性能问题可能会在单元测试中轻易滑落，您只能在进行一些分析后才能发现。）

让我们称之为保证移动strict_move。我希望能够编写这样的代码：

void bar(Matrix x, const Matrix y) {
  Matrix x2 = strict_move(x); // OK
  Matrix y2 = strict_move(y); // compile error
}

有可能吗？

修改

感谢您的答案！有一些合理的要求澄清我的问题：

如果输入为常量，strict_move会失败吗？
如果结果不会导致实际的移动操作，strict_move会失败吗（即使副本可能与移动一样快，例如const complex<double>）？
两个

我最初的想法非常模糊：我认为Scott Meyers的例子非常惊人，所以我想知道是否有可能让编译器阻止这些意外的副本。

Scott Meyers在他的演讲中提到，一般的编译器警告不是一种选择，因为它会导致大量误报。相反，我希望与编译器进行通信，例如“我100％确定这必须始终导致移动操作，并且副本对于此特定类型而言过于昂贵”。

因此，我会毫不客气地说strict_move在两种情况下都会失败。与此同时，我不确定什么是最好的。我没有考虑的另一个方面是noexcept。

在我看来，strict_move的确切语义是开放的。在编译时有助于防止某些愚蠢错误而没有严重缺陷的一切都很好。

Answer 1

我建议不要编写检测strict_move的一般const。我认为这不是你真正想要的。你想要这个标记const complex<double>或const pair<int, int>吗？这些类型将在移动时快速复制。标记它们只会是一种刺激。

如果您想这样做，我建议您检查类型是否为noexcept MoveConstructible。这对std::string完全有效。如果意外调用string的复制构造函数，则它不是noexcept，因此将被标记。但如果pair<int, int>的副本构造函数被意外调用，你真的关心吗？

以下是草图：

#include <utility>
#include <type_traits>

template <class T>
typename std::remove_reference<T>::type&&
noexcept_move(T&& t)
{
    typedef typename std::remove_reference<T>::type Tr;
    static_assert(std::is_nothrow_move_constructible<Tr>::value,
                  "noexcept_move requires T to be noexcept move constructible");
    static_assert(std::is_nothrow_move_assignable<Tr>::value,
                  "noexcept_move requires T to be noexcept move assignable");
    return std::move(t);
}

我决定检查is_nothrow_move_assignable，因为你不知道客户是在构建还是分配lh。

我选择了内部static_assert而不是外部enable_if，因为我不希望noexcept_move重载，static_assert会产生更清晰的错误消息触发。

Answer 2

您可以制作不允许常量返回类型的move版本。例如：

#include <utility>
#include <string>
#include <type_traits>


template <typename T>
struct enforce_nonconst
{
    static_assert(!std::is_const<T>::value, "Trying an impossible move");
    typedef typename std::enable_if<!std::is_const<T>::value, T>::type type;
};

template <typename T>
constexpr typename enforce_nonconst<typename std::remove_reference<T>::type>::type &&
mymove(T && t) noexcept
{
    return static_cast<typename std::remove_reference<T>::type &&>(t);
}

void foo(std::string a, std::string const b)
{
    std::string x = std::move(a);
    std::string y = std::move(b);
}

void bar(std::string a, std::string const b)
{
    std::string x = mymove(a);
    // std::string y = mymove(b);  // Error
}

int main() { }

Answer 3

首先，我想说明你以前的答案不会完全解决你的问题。

以前的解决方案（@Kerrerk和@ 0x499602D2）失败的反例：假设您使用抛出异常的移动构造函数编写了矩阵类。现在假设您要移动std::vector<matrix>。 This article表明，如果std::vector<matrix>保存的矩阵类元素实际被移动（如果第j个元素移动构造函数抛出异常会发生什么情况，那么您将无法获得“强异常保证”？您会丢失数据，因为无法恢复已经移动的元素！）。

这就是为什么stl容器使用.push_back()实现.reserve()，std::move_if_noexcept及其移动构造函数来移动它们所持有的元素的原因。以下是从open-std获取的reserve（）的示例实现：

void reserve(size_type n)
{
    if (n > this->capacity())
    {
        pointer new_begin = this->allocate( n );
        size_type s = this->size(), i = 0;
        try
        {
            for (;i < s; ++i)
                 new ((void*)(new_begin + i)) value_type( std::move_if_noexcept( (*this)[i]) ) );
        }
        catch(...)
        {
            while (i > 0)                 // clean up new elements
               (new_begin + --i)->~value_type();

            this->deallocate( new_begin );    // release storage
            throw;
        }
        // -------- irreversible mutation starts here -----------
        this->deallocate( this->begin_ );
        this->begin_ = new_begin;
        this->end_ = new_begin + s;
        this->cap_ = new_begin + n;
    }
}

因此，如果你没有强制你的move和默认构造函数是noexcept，你不能保证像std :: vector.resize（）或std :: move（对于stl容器）这样的函数永远不会复制矩阵类，这是正确的行为（否则你可能会丢失数据）

如果std :: move将导致意外的副本，则强制编译时错误？

3 个答案: