1

我的问题是，不可复制的对象是否应该具有隐式/显式用户转换？至少从我下面的示例来看，转换看起来非常像副本。

PS：我知道这里推荐“避免隐式转换运算符” https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#c164-avoid-implicit-conversion-operators

为了解释我的基本原理，假设我有一个使用 RAII 管理 OS 对象的类。没有什么花哨。

struct unique_handle
{
    unique_handle(HANDLE h) : handle(h) {}

    //NON COPYABLE
    unique_handle(const unique_handle&) = delete;
    unique_handle& operator=(const unique_handle&) = delete;

    //MOVEABLE
    unique_handle(unique_handle&& other) : handle(other.handle)
    {
        other.handle = INVALID_HANDLE_VALUE;
    }   
    unique_handle& operator=(unique_handle&& other)
    {
        if (this != &other) {
            handle = other.handle;
            other.handle = INVALID_HANDLE_VALUE;
        }
        return *this;
    }

    ~unique_handle()
    {
        if(handle != INVALID_HANDLE_VALUE)
            ::CloseHandle(handle);
    }
private:
    HANDLE handle;
}

这没关系。它允许我做类似的事情：

namespace w32
{
    unique_handle CreateFile(...)       
    {
        HANDLE handle = ::CreateFileA(...);
        return { handle };
    }
}

问题是其他操作系统功能不会接受我的对象。所以我尝试了总是危险的隐式/显式用户转换路径。

struct unique_handle
{
...
    operator HANDLE() const noexcept { return handle; }
...
}

这使我可以正常使用我的对象。

...
auto dirHandle = w32::CreateFile(...); // my function returning my object
::ReadDirectoryChangesW(dirHandle, // my object on a native OS call
        ...);
...

这太棒了！但是现在的问题是我允许泄漏关闭的句柄的可能性。假设我直接将我的对象分配给一个 HANDLE 对象，而不是左值，这不仅泄漏了非托管 HANDLE，甚至泄漏了一个封闭的 HANDLE。例如：

Problem 1
...
HANDLE h = w32::CreateFile(...);
...

我了解问题 1 发生了以下情况：

1 - 我从操作系统获得了 HANDLE 并将它传递给我的对象来管理它；
2 - 我使用隐式用户转换运算符返回了 HANDLE；
3 - 编译器调用我的对象析构函数来关闭句柄；
4 - 一个封闭的 HANDLE 以不明显的方式泄漏。可能的运行时错误。因为 HANDLE 不是 INVALID_HANDLE_VALUE，所以即使是错误检查也无法捕捉到这一点。

当然，我也启用了这个案例。但为了争论，让我们说我接受这个案子。

Problem 2
HANDLE h1 = ...;
{
    auto h2 = w32::CreateFile(...); // my method and my object
    h1 = h2;                        // implicit cast to the OS HANDLE
}                                   // our favorite feature closing the HANDLE
::ReadDirectoryChangesW(h1, ...);
...

因为如果不是选择隐式/显式用户转换，而是选择一元运算符，我可以避免临时对象的转换，例如：

HANDLE operator !(unique_handle& v2)
{
    return v2.handle;
}

这给了我一个编译错误，例如：

...
HANDLE h = !w32::CreateFile(...);
...

这是理想的，但据我所知，我们不能对转换做同样的事情。

我想象的其他解决方案是以下功能：

struct unique_handle
{
    ...
    // just return - In my opinion also a copy, but what can we make?
    [[nodiscard]] HANDLE get() const noexcept { return handle; } 

    // Stop managing this HANDLE
    [[nodiscard]] HANDLE release() noexcept
    {
        auto h = handle;
        handle = INVALID_HANDLE_VALUE;
        return h;
    }
    ...
}

所以回到我的问题，这种情况可以避免吗？或者不可复制的对象不应该有用户转换？老实说，它们与返回一些托管私有对象的简单 get() 有何不同？也许是一种避免用户从临时对象转换的方法？我们可以强制一个对象在任何其他用途之前被左值化，无论是方法调用还是转换？

4

1 回答 1

1

这种情况可以避免吗？

不，您正在使用的库函数不会、不能也永远不会支持您的智能资源管理。这是一种耻辱，特别是因为他们自己没有提供任何东西，但这是现实情况。

或者不可复制的对象不应该有用户转换？老实说，它们与返回一些托管私有对象的简单 get() 有何不同？

.get()对读者来说是一个更大的警告标志，必须注意以“原始”方式提取的资源的生命周期。您的隐式转换编写起来更快更短，但不表示这一点并且更有可能导致错误。

也许是一种避免用户从临时对象转换的方法？我们可以强制一个对象在任何其他用途之前被左值化，无论是方法调用还是转换？

是的，成员函数可以有ref-qualifiers。尽管如上所述，我认为这并不能真正解决您的首要问题，即每次使用这些库函数都需要读者仔细观察，无论您想出什么设计。

看std::unique_ptr。它有一个功能（支持需要a 的get()第三方功能）并且没有对任何东西的隐式转换（以防止这种情况意外发生）。T*

我的一般建议是避免隐式转换，你可以帮助它。

于 2019-03-02T22:45:02.557 回答