"向后移植" nullptr to C ++ - pre-C ++ 0x program

时间:2012-01-05 17:37:42

标签: c++ c++03 nullptr backport forward-compatibility

或多或少的标题暗示。虽然我not yet using C++0x我想在它发生时做好准备,而且我也希望减少我必须重写以使用它的一些设施的代码量。这样我就可以一次性地向前和向后兼容。

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

在检查了“官方解决方法”和Meyer's suggestion之后,我决定在我的C ++和未来的C ++ 0x程序中使用它。第二部分很简单 - 作为关键字,我们只会支持nullptr。但第一部分让我有些不适。

迈耶斯提案的功能如下:

class nullptr_t { // ← this is my issue
    // definition of nullptr_t
} nullptr = { };

该提议的问题在于它根据C ++ 0x的要求声明了要声明为std::nullptr_t的类型。这意味着对于“感觉原生”的变通方法,必须通过重新打开std::命名空间来添加类型。 我理解在C ++程序中是非法的(与添加 specializations 不同,这显然是皱眉和放开警告)。

我希望在C ++程序中以舒适的 AND 合法方式使用nullptr。我想到的一个选项是在另一个命名空间中声明类型,然后使用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?

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


作为一个附录,试图将一些漂亮的C ++ 0x事物向C ++反向移植以获得更好的兼容性和编码,这是一个受欢迎或不受欢迎的事情吗?与此同时,我已将此解决方案与我正在研究的其他解决方案in a piece of software to be released集成在一起。

2 个答案:

答案 0 :(得分:3)

除非你能想出一个理由,你需要声明另一个nullptr_t类型的对象(我不能),否则我会隐藏类型并放置nullptr在全局命名空间中尽可能地模仿关键字:

namespace mylibrary
{
    class nullptr_t
    {
        ....
    };
}

mylibrary::nullptr_t nullptr = { };

答案 1 :(得分:1)

您不允许向namespace std添加内容的主要原因是您不会弄乱已经存在的内容。否则可以轻松完成。我在过去发现的东西是对使用内置类型std::vector<int>实例化的容器的输出操作符的多个定义。但是,nullptr_t未在此命名空间中定义,添加typedef应该是非常无害的。也就是说,我会在nullptr_t之外的不同名称空间中定义namespace std,然后为typedef添加nullptr_tnamespace std。变量nullptr无论如何都需要在全局范围内声明,因为它在C ++ 2011中使用不合格。

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