我正在构建一个 API,它允许我获取各种编码的字符串,包括 utf8、utf16、utf32 和 wchar_t(根据操作系统,可能是 utf32 或 utf16)。
-
新的 C++ 标准引入了新类型char16_t
and char32_t
没有这么大的歧义,应该在将来使用,所以我也想支持他们,但问题是,他们会干涉吗与正常的uint16_t
, uint32_t
, wchar_t
类型不允许重载,因为它们可能引用相同的类型?
class some_class {
public:
void set(std::string); // utf8 string
void set(std::wstring); // wchar string utf16 or utf32 according
// to sizeof(wchar_t)
void set(std::basic_string<uint16_t>)
// wchar independent utf16 string
void set(std::basic_string<uint32_t>);
// wchar independent utf32 string
#ifdef HAVE_NEW_UNICODE_CHARRECTERS
void set(std::basic_string<char16_t>)
// new standard utf16 string
void set(std::basic_string<char32_t>);
// new standard utf32 string
#endif
};
所以我可以写:
foo.set(U"Some utf32 String");
foo.set(u"Some utf16 string");
-
typedef 是什么std::basic_string<char16_t>
and std::basic_string<char32_t>
就像今天一样:
typedef basic_string<wchar_t> wstring.
我找不到任何参考。
编辑:根据 gcc-4.4 的标题,引入了这些新类型:
typedef basic_string<char16_t> u16string;
typedef basic_string<char32_t> u32string;
我只是想确保这是实际的标准要求,而不是海湾合作委员会主义。
1) char16_t
and char32_t
将是不同的新类型,因此可以对它们进行重载。
引用自ISO/IEC JTC1 SC22 WG21 N2018 http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2018.html:
Define char16_t
成为 a 的 typedef
独特的新类型,名称为_Char16_t
具有相同的大小和表示uint_least16_t
。
同样,定义char32_t
成为一个
typedef 为一个独特的新类型,其中
名字_Char32_t
具有相同的
大小和表示为uint_least32_t
.
进一步解释(来自 devx.com 文章“为 Unicode 革命做好准备 http://www.devx.com/cplus/10MinuteSolution/34328/1954"):
您可能想知道为什么_Char16_t
and _Char32_t
首先需要类型和关键字
当类型定义uint_least16_t
and
uint_least32_t
已经可用。
新类型的主要问题
解决超载。下雪了
可以重载函数
拿_Char16_t
and _Char32_t
参数,并创建专业化
例如std::basic_string<_Char16_t>
不同于std::basic_string <wchar_t>
.
2) u16string
and u32string
确实是 C++0x 的一部分,而不仅仅是 GCC'isms,正如它们在各种标准草稿 http://www.google.com/search?q=u16string+site%3Aopen-std.org。他们将被纳入新的<string>
标头。引用同一篇文章:
标准库还将提供_Char16_t
and _Char32_t
typedef,类似于 typedefwstring
,
wcout
等,适用于以下标准类别:
filebuf, streambuf, streampos, streamoff, ios, istream, ostream, fstream,
ifstream, ofstream, stringstream, istringstream, ostringstream,
string
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系:hwhale#tublm.com(使用前将#替换为@)