--
FROM 61.48.14.*

这些用c 怎么写？
【 在 z16166 的大作中提到: 】
: 不限制上限，需要抠效率的地方有用
: 比如string可以实现为短串存在栈上，长串存在堆上。
: 各种buffer、allocator更不用说了
: ...................
--
FROM 223.198.83.*

没办法，相比java和python，标准库的string基本也就当个高级数组用
--
FROM 221.224.15.*

字符串涉及encoding问题，搞到最后可能得把libiconv或者ICU整套都引入到C++里，
要不就得用每个OS提供的API来实现。linux用的UTF8，windows用的UTF16，还有一大堆unix和其它OS，要整出一个统一的在各个平台上都效率高的恐怕没那么容易。不然的话，各位试着想一个提案试试。

而且在std::string制定的那个年代libiconv或者ICU估计还没现在这么成熟

std::codecvt这套搞了又被废弃了一部分

现阶段的使用，主要是以std::string、std::wstring作为容器（array），再配合CRT函数或者OS API来处理，所以会出现各种封装。如果不跨平台，只支持windows，那我宁愿用CString。

【 在 hgoldfish 的大作中提到: 】
: stl 的问题啊。
: 很多人说 string 可以用不同的方式实现，追求更高的效率。但这件事情没道理啊，一般的 cpp 程序根本用不上这些优化。纯粹是因为标准库太难用了，所以大家只好自己实现一套了。
: 所以推荐大家在做 pc 端开发和后端开发的时候都用上 QtCore 或者 poco，别浪费时间在开发那些基础的轮子上面。
: ...................
--
修改:z16166 FROM 61.48.130.*
FROM 61.48.130.*

cpp 现在被大规模用在后端，而不是用于 PC GUI 开发，所以还是简单点，直接上 QtCore 吧哈哈。一个 QtCore 只要 6MB，不需要链接 ICU。我甚至可以把 QtCore 裁到 4MB 大小。真不值得再自己重新发明一套轮子。

【 在 z16166 的大作中提到: 】
: 字符串涉及encoding问题，搞到最后可能得把libiconv或者ICU整套都引入到C++里，
: 要不就得用每个OS提供的API来实现。linux用的UTF8，windows用的UTF16，还有一大堆unix和其它OS，要整出一个统一的在各个平台上都效率高的恐怕没那么容易。不然的话，各位试着想一个提案试试。
: 而且在std::string制定的那个年代libiconv或者ICU估计还没现在这么成熟
: ...................
--
修改:hgoldfish FROM 110.81.0.*
FROM 110.81.0.*