或多或少的标题暗示.虽然我还没有使用C++ 0x,但是我想在它发生时做好准备,而且我还想减少我必须重写的代码量才能使用它的一些功能.这样我就可以一次性地向前和向后兼容.
我发现的最有趣的一个是nullptr,我最近经常使用它.
在检查了"官方解决方法"和Meyer的建议之后,我决定在我的C++和未来的C++ 0x程序中使用它.第二部分很简单 - 作为关键字,nullptr只需支持.但第一部分让我感到有些不适.
Meyers提案的功能如下:
class nullptr_t { // ? this is my issue
// definition of nullptr_t
} nullptr = { };
该提议的问题在于它声明了要声明为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 …在C++中看到许多元编程的例子,它们可以找出类的属性(例如知道类型是否是模板的特化),或者知道类是否包含给定的嵌套类型; 但我想知道是否有可能编写一个测试或特征来确定最后一个的倒数 - 检查一个给定Type是否嵌套在一个class或struct.
换句话说,我正在寻找以下伪代码的等价物:
template <typename Type> struct is_nested {
enum { value = {__some magic__} };
};
typedef int type1;
struct Something { typedef int internal_type; };
typedef Something::internal_type type2;
//...later, likely at a different scope
is_nested< int >::value; // yields false
is_nested< std::vector<int>::iterator >::value; // yields true
is_nested< type1 >::value; // yields false
is_nested< type2 >::value; // yields true
我知道我可以sizeof用来实现是/否测试,我认为Type是那些测试的一部分,但我无法弄清楚如何在测试中插入某种"任何可行的类型",这样我就可以形成一个表达式喜欢Anytype::Type.
template struct is_nested …
我正在开发一个需要与 C++03 向后兼容的遗留库，但也向前兼容以利用 C++11 功能，如移动语义和显式转换。
那么，是否可以在 C++03 中模拟显式转换？我显然知道显式 bool（或“安全”bool）习惯用法 - 但这仅用于转换为布尔类型。是否可以在 C++03 中模拟通用的显式转换运算符？
我查了一下，在一本名为“不完美的 C++：现实生活编程的实用解决方案”的书中找到了关于这个的讨论。
在这本书中，他们讨论了在 C++03（这本书是在 C++11 之前编写的）中模拟显式强制转换的一些想法。最终，他们建议创建一个explicit_cast<T>模板。但是，我不喜欢该解决方案，因为我希望用户能够简单地使用static_cast<T>，这在 C++11 中运行良好。
因此，另一种解决方案是强制编译器进行两次转换，这将禁止隐式转换。一个例子是这样的：
class int_cast
{
public:
int_cast(const int& v) : m_value(v)
{ }
operator int() const
{
return m_value;
}
private:
int m_value;
};
struct Foo
{
Foo()
{
x = 10;
}
operator int_cast() const
{
return int_cast(x);
}
int x;
};
在这里， aFoo应该显式转换为int，但不能隐式 …
我一直在阅读链接作为这个问题，当然这个问题是关于char8_t在 C++20 中为即将到来的“utf8”字符类型及其相应的字符串类型做准备的问题，并且可以说，在某种程度上，是时候了。还有就是一团糟。
请随时纠正我的错误：
# encoding:...元数据），也无法将其编译成什么标准（如 say #!/bin/env g++ -std=c++14）。u16"text"和u32"text"相关的 char 类型来生成 UTF16 和 UTF32 编码的文本，但没有提供字符串或流工具来处理它们，所以它们基本上没用。u8"text"用于生成 UTF8 编码的字符串......但它甚至没有引入正确的 UTF8 字符类型或字符串类型（这char8_t就是 C++20 中的意图？），所以它甚至比以上。char8_t是终于出台，它杀死很多原打算是有效的，到目前为止，一些调控措施的要求包括代码完全禁用char8_t行为。<random>）来检查、转换（在同一字符串内）或转换（跨字符串类型复制）C++ 中的文本编码。甚至 codecvt 似乎也已被删除。鉴于上述所有情况，我有一些关于为什么我们处于这种奇怪状态以及它是否会变得更好的问题。从历史上看，Unicode 支持一直是 C++ 的最低点之一。
同样，我想知道整个概念的穷人模拟有多大用处（免责声明：我是cxxomfort …