- 主题:用c++做了一个项目生不如死
那估计你用Rust、Haskell、C做这种也会生不如死，哈哈
当官比较简单，就一句自然语言就完事了：“xx月xx号之前必须交货，不然滚蛋”。
不过也会被更大的官这样说
--
修改:z16166 FROM 114.245.255.*
FROM 114.245.255.*
这种就是水木的气氛组，水木的帖子数和流量要靠这种，哈哈
【 在 lvsoft 的大作中提到: 】
: 你在rust版喷rust，
: 在c++版喷c++
: 在ai版喷ai
: ...................
--
FROM 114.245.255.*
std::string、std::wstring我现在大量在用
不过，char *、std::string这种，需要明确注释里面存的是ansi、binary还是utf8的内容，还是C的搞法。
std::u8string感觉很少人用
【 在 hgoldfish 的大作中提到: 】
: 放心，std::string 确实是垃圾。
: 几乎没人在正经项目里面用这个。
:
--
FROM 114.245.255.*
leveldb也全是std::string做K、V，不过可以塞进去binary
【 在 ziqin 的大作中提到: 】
: 我也不知道你在说什么，好像absl的接口不是给std::string设计的一样。
: protobuf呢？
:
: ...................
--
FROM 114.245.255.*
主要还是因为继承了C的遗产：char *
char * 这玩意儿里面可以塞进去好几种东西（不算类型随便cast的那些）
【 在 hgoldfish 的大作中提到: 】
: 这个 std::string 真是名不符实，应该叫 std::bytes.
:
--
FROM 114.245.255.*
windows平台的软件用utf16是因为：
1、所有的OS API、CRT函数都有utf16版本，使用方便，起因当然是Windows NT kernel从一开始就是这个设计，上了这个船，船上的后来者也只能先接受现状。
2、在只需要处理英文字母的大小写，而不需要处理utf16的surrogate pair里的大小写时，或者完全不需要考虑surrogate pair时（这种情况下可能主要就支持英文和CJK之类的，不支持那些有surrogate pair的自然语言。只在BMP内），很方便。
所以这个是有前提的。
【 在 yuanmo 的大作中提到: 】
: 同感。
: N年前做过把GB2312编码的项目改成国际版的工作，有几百万行代码要改。最开始尝试了一下utf-16，很快发现完全不可行，因为原来的字符串都是char*和string，要改几万行相关代码变成wchar_t和wstring基本是不可能的，不但工作量大，而且原来的strcpy, strcat，strlen等操作完全失效，都得改成类似wstrcpy, wstrcat之类。就算折腾完了，utf16还是一个变长编码，我这么折腾究竟图啥。
: 然后UTF8有个最大的好处，就是兼容char*。相对来说，下标访问的需求不算强烈，而且也可以通过函数封装。综合看起来UTF8就是最顺眼的。
: ...................
--
修改:z16166 FROM 114.245.255.*
FROM 114.245.255.*