- 主题:用c++做了一个项目生不如死
00 后已经在用表情符当变量名了啊。
【 在 ziqin 的大作中提到: 】
: 如果要是这么说的话，你第一个应该考虑的是表情包到底算不算字符。
: 是不是应该简单的寄希望于string来处理这些根本就不能被定义为字符的东西
--
FROM 117.28.162.*
std::u32string 可以的。就是比较浪费空间。
话说，可以做个优化，自动根据内容，决定使用 u8string u16string 和 u32string.
【 在 easior 的大作中提到: 】
: 那 C++ 宽字符串类型 std::wstring=std::basic_string<wchar_t>
: 与 std::u16string、std::u32string 行不行呢 它们都是 Unicode 的
: 不过牵涉到多字节编码的字符，字符串处理器来比较麻烦
: ...................
--
FROM 117.28.162.*
icu 需要带个庞大的 dll. 也不见得好用吧。
最好是能根据系统像 windows 和 macos 都自带字符编码处理。
【 在 siyuetian 的大作中提到: 】
: std::string把他看成个字符串类，那他真的不好用，但问题是这玩意设计上只是个容器。
: 对于你的需求，如果用到qt的话qstring挺好用，没用qt的话，icu::UnicodeString试试，icu库挺通用的
--
修改:hgoldfish FROM 117.28.162.*
FROM 117.28.162.*
如果多用中文的话，应该是 u16string 最省空间。基本上一个汉字对应两个字节。
而且 utf-8 的话，一个汉字基本上对应三个字节。
python 和 Qt 都会做我刚才说的优化，自动根据 unicode 编码范围，选择适合的存储类型来使用。一来可以节省空间，二来提升处理效率。比如 u8string 里面，想要迭代处理一个个 unicode 字符，一会是一个字节，一会儿是三个字节。效率很差。
unicode_string[i]
就这个简单的取下标，都是大麻烦。
【 在 easior 的大作中提到: 】
: 从内存消耗来说，u8string 最省空间
: 可惜 u8string=basic_string<char8_t> 也只是字节串，并不是真正的字符串
--
修改:hgoldfish FROM 117.28.162.*
FROM 117.28.162.*
问题就是想要补全它很难啊。
QtCore 好用。但是为了个 QtCore 依赖 Qt 一大堆东西又很麻烦。
有空研究一下好像有个改出了个类 QtCore 的模块。
【 在 easior 的大作中提到: 】
: 中文场合如你所说，确实如此
: 这么一说，std::basic_string<CHAR_T> 并不是一无是处
: 感觉只需要补强它的字符串功能，就能够等同于 QString 了
: ...................
--
修改:hgoldfish FROM 117.28.162.*
FROM 117.28.162.*
计算机单核性能已经来到物理极限。
这个性能看起来不起眼。但字符串操作是计算机程序里面最常用的操作。
C++ 的字符串没有普及 SIMD 优化也是巨大的坑点。
新的编程语言应该应该吸取这些教训。
【 在 seablue 的大作中提到: 】
: 不知道u16string是不是utf-16.
: utf-16对应unicode基本平面(cjk-extA)。超出基本平面的汉字就不是双字节编码了。
: 其实三字节的utf-8汉字编码和两字节的utf-16编码，对于今天的计算机存诸技术和网络带宽而言，不是一个值得纠结的点。对于变长的utf-8编码，直接取下标定位字符技术上也是可以做到的。
: ...................
--
FROM 120.41.147.*
也不算尴尬。
Java 的 u16string 在互联网时代存储汉字更高效。
【 在 seablue 的大作中提到: 】
: 我前面的贴子说了：原来的utf-16现在不够用了，于是扩成了变长变码。
: 那既然用了变长编码，为啥不用utf-8？毕竟utf-8自带同步信息，而且在ascii内空间效率更高。
: java的string是u16,这是历史遗留问题。所以现在很尴尬。
: ...................
--
FROM 120.41.147.*
但 utf-8 也很尴尬啊。印象中表情符需要 6 个 utf-8 字节才能存得下？
【 在 seablue 的大作中提到: 】
: 表情符号要么没法存，要么超出了两字节。所以utf-16是一个残次品。
--
FROM 120.41.147.*