或多或少如标题所暗示的那样。当我 not yet using C++0x我想为它的发生做好准备,我还想减少为使用它的某些功能而必须重写的代码量。这样我就可以一次性获得向后和向前的兼容性。
我发现的最有趣的一个是 nullptr
,我最近经常使用它。
检查“官方解决方法”和Meyer's suggestion后,我决定在我的 C++ 和 future 的 C++0x 程序中都使用它。第二部分很简单——作为关键字,nullptr
将得到简单支持。但是第一部分让我有些不舒服。
Meyers 提案的功能如下:
class nullptr_t { // ← this is my issue
// definition of nullptr_t
} nullptr = { };
该提案的问题在于它按照 C++0x 的要求将要声明的类型声明为 std::nullptr_t
。这意味着要使解决方法“感觉原生”,必须通过重新打开 std::
命名空间来添加类型来完成。 我知道在 C++ 程序中这样做是非法的(与添加特化 不同,这显然是皱着眉头并放手警告)。
我想在 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 .
最佳答案
除非你能想到你需要声明 另一个 nullptr_t
类型的对象的原因(我不能),否则我会隐藏类型并把 nullptr
在全局命名空间中尽可能模仿关键字:
namespace mylibrary
{
class nullptr_t
{
....
};
}
mylibrary::nullptr_t nullptr = { };
关于c++ - "Backporting"nullptr 到 C++-pre-C++0x 程序,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/8747005/