- 主题:cpp一个神奇的地方是很多库实现了自己的string, 自己的buffer
不限制上限,需要抠效率的地方有用
比如string可以实现为短串存在栈上,长串存在堆上。
各种buffer、allocator更不用说了
--
FROM 61.48.130.*
字符串涉及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.*
C++自己哪里有带啥buffer,只有std::vector<>
各种有gc的语言不需要去搞这个细节,所以显得C++好像在搞各种buffer一样
你要是搞windows kernel,就会发现buffer也有各种,paged pool/non-paged pool,lookaside list等等
linux kernel里一样
到了那个粒度和层次,它就必须抠那些细节
【 在 spadger 的大作中提到: 】
: 说明C++自带的string和buffer不好用,不得已才自己撸
:
--
修改:z16166 FROM 61.48.130.*
FROM 61.48.130.*
客户端也有用C++的,比较底层点的,各种安全类的软件,外加IM的底层库。现在的趋势是一部分用Rust来写。
【 在 hgoldfish 的大作中提到: 】
: cpp 当然是用在后端了啊。和种互联网公司一般都有 cpp 的项目组,做一些核心层的工作。本版大家可以出来说说,你们拿 cpp 是做后端还是前端。
:
--
FROM 61.48.130.*