"backporting"nullptr到C++ - 前C++ 0x程序

Lui*_*uca 9 c++ backport nullptr forward-compatibility c++03

或多或少的标题暗示.虽然我还没有使用C++ 0x,但是我想在它发生时做好准备,而且我还想减少我必须重写的代码量才能使用它的一些功能.这样我就可以一次性地向前和向后兼容.

我发现的最有趣的一个是nullptr,我最近经常使用它.

在检查了"官方解决方法"和Meyer的建议之后,我决定在我的C++和未来的C++ 0x程序中使用它.第二部分很简单 - 作为关键字,nullptr只需支持.但第一部分让我感到有些不适.

Meyers提案的功能如下:

class nullptr_t { // ? this is my issue
    // definition of nullptr_t
} nullptr = { };
Run Code Online (Sandbox Code Playgroud)

该提议的问题在于它声明了要声明为std::nullptr_tC++ 0x所需的类型.这意味着对于"感觉原生"的解决方法,必须通过重新打开std::命名空间来添加类型.我理解在C++程序中这是非法的(不像添加特殊化,这显然是皱眉和放开警告).

我想用nullptr在舒适在C++程序合法的方式.我想到的一个选项是在另一个命名空间中声明类型然后使用它using:

namespace mylibrary {
class nullptr_t {
    ....
} nullptr = { };
// end namespace
}

// These would have to go in the header file.
using mylibrary::nullptr;
using mylibrary::nullptr_t; // apparently this is necessary as well?
Run Code Online (Sandbox Code Playgroud)

这是否是使其正常工作的正确方法?它会强制执行using指令,这也会强制指令的特定顺序#include.我是否正确期望没有预C++ 0x代码会请求nullptr_t具有命名空间的类型(例如,作为函数参数类型)?如果以这种方式完成,它真的会"感觉自然"吗?


作为一个附录,试图将一些漂亮的C++ 0x东西向C++反向移植以获得更好的兼容性和编码是一种受欢迎或不赞成的事情吗?与此同时,我已经将这个解决方案和我正在开发的其他软件集成在一个软件中.

Die*_*ühl 1

不允许你添加东西的主要原因namespace std是这样你就不会弄乱已经存在的东西。否则这可以很容易地完成。我过去发现的是使用内置类型实例化的容器的输出运算符的多个定义,例如std::vector<int>. 然而,nullptr_t没有在此命名空间中定义,添加 atypedef应该是无害的。也就是说,我会nullptr_t在不同的命名空间中定义namespace std,然后添加一个typedeffornullptr_tnamespace std。无论如何,该变量都nullptr需要在全局范围内声明,因为它在 C++2011 中不合格地使用。

是否需要该类型std::nullptr_t取决于您是否有兴趣使用该类型添加签名。例如,std::shared_ptr<T>可以与 进行比较nullptr。为此,有必要添加适当的重载来提及该类型std::nullptr_t(或为此类型使用其他名称)。