大橙子网站建设,新征程启航
为企业提供网站建设、域名注册、服务器等服务
整理了一些想法,抛砖引玉。
临海网站制作公司哪家好,找成都创新互联公司!从网页设计、网站建设、微信开发、APP开发、响应式网站开发等网站项目制作,到程序开发,运营维护。成都创新互联公司自2013年创立以来到现在10年的时间,我们拥有了丰富的建站经验和运维经验,来保证我们的工作的顺利进行。专注于网站建设就选成都创新互联公司。经验大多基于 C++17,工作中不需要对 C 暴露接口,偶尔会使用 C 库或者 C 风格的接口,在与 C 交互上是半吊子水平。
std::string_view
仅在 C++17 后才可用,对于没有条件的项目,可以考虑使用 Abseil 等三房库提供的string_view
实现,但要留意第三方的实现和std::string_view
可能并不保证完全可互换。
首先是避免使用 std::string
定义常量,在我的工作环境甚至会被扫描工具拦截。不使用原因包括:
std::string
会引发堆内存分配;std::string
析构函数非平凡,全局对象销毁顺序难以预测,存在生命周期结束后被访问的风险(例如该 std::string
被其他全局对象引用)等。近期搞的一些代码,大家习惯是使用 constexpr char[]
:
constexpr char kMyConstString[] = "hello world";
使用 constexpr char[]
本身没任何问题,只是很容易在调用中退化为 const char*
,导致取字符串长度的复杂度变为 O(n)。为了避免计算长度的开销,调用参数需要一路都额外带一个 int
或者 size_t
的长度。
也见过一些其他代码使用 std::string_view
:
constexpr std::string_view kMyConstString = "hello world";
constexpr auto kMyConstString = "hello world"sv; // using namespace std::literals
std::string_view
自带很多方法,自然比 constexpr char[]
好用很多,也有 O(1) 的方法获取长度。
通过字面量字符串创建的 std::string_view
其内部数据是 NUL 结尾的,但是 NUL 字符在其 size()
之外,略有点怪怪的。但是一般意义上的 std::string_view
不保证是 NUL 结尾的,导致用起来总需要多留个心眼。这种区别可能会导致开发时拿到一个 std::string_view
后不知道该不该信任它有个 NUL 字符而会脑裂,同时也会给 reviewer 带来负担。
遵循以下原则:
std::string_view
(const) char*
,通常都可以使用 std::string_view
替代自底向上扩散,是指使用最底层第一个不可变(e.g. 别人的库)的调用参数作为参数类型传递。如果调用链靠下的部分是 const std::string&
这样的参数类型,那么直接保持 const std::string&
到你负责的最外层即可。底层决定了参数必然需要转换成为 std::string
,假如调用链中间混进了 std::string_view
,就会导致需要从 std::string_view
转换 std::string
,产生不必要的拷贝。
一个常见例子是,如果我的一个函数是查询一个 std::map
,这就决定了其查询 key 必然是 std::string
类型,查询的 find()
函数接收 const std::string&
,遵循 “自底向上扩散“ 原则,一路都应该是 const std::string&
。也就不难发现,所有查 std::string
为 key 的关联容器的函数,其参数最好都是 const std::string&
。如果是调用别人的接口,接口使用了 const std::string&
,则也是同理。
有一个例外是,如果底层的 std::string
参数是值传递(而非引用、指针传递)的,例如:
void Foo(std::string s);
那么无论如何也都会拷贝一次,此时也可以用 std::string_view
做调用链传递。(但是,这种情况还是建议先看看是不是 Foo
的参数应该改成 const std::string&
才对的,我见过的九成是从其他语言转来的新手不知道引用,只有一成是函数内部计算过程中要修改输入作为临时状态,于是干脆用值参数来做零时变量的拷贝。)
在 std::string_view
和 const char*
之间,鉴于 :
const char*
数据 + int
/size_t
长度 】的组合可以和 std::string_view
低成本互转,不用担心发生数长度、拷贝;std::string_view
可以低成本转 const char*
;const char*
无法低成本转 std::string_view
,需要数一次长度 。考虑到 std::string_view
用起来方便很多,通常在调用链上使用 std::string_view
是更好的。
只有一种特殊情况,如果调用链底层的接口比较奇特,只接收单独的 const char*
(可能是写死了在内部数长度),并且调用参数来源也是个 const char*
不知为何也不带长度,那么遵循 “自底向上扩散” 原则效能最佳,调用链过程中避免多数一次长度。
std::string
与 std::string_view
的最本质区别是,前者持有字符串数据所在内存的所有权,并负责管理其生命周期,而后置只是对内存中已有数据的引用。因而,仅在被引用字符串能够保证生命周期足够,且生命周期内不会被修改时,可以通过使用 std::string_view
保存其引用或其片段的引用。
由于类(或者说对象)通常都是各自管理自己的成员,会发现,上述使用 std::string_view
的条件在类成员变量中很难满足,就算见到,与其烧脑子梳理生命周期担心以后会不会别人改崩,还是在遇到性能瓶颈之前先用 std::string
是更保险的做法,不要用正确性换取性能。相比其他场合,类成员变量使用 std::string_view
通常风险高出很多。如果是我,甚至宁愿会优先考虑共享语义,例如 std::shared_ptr
,并在可能并发读写场合再加个锁。
思路类似于(非静态)类成员变量,但类/对象通常承载了生命周期,而一个函数中的临时变量通常没有这种职责,因此相比之下,临时变量有更多的场合适合使用 std::string_view
。
具体来说,如果函数调用,要么是同步无并发的,要么有只读并发且能保证被引用数据生命周期的,就可以使用 std::string_view
来引用数据。我倾向于仅在同步无并发的环境使用——并发环境冷不丁某一天可能就不是只读并发,或者生命周期有变化了。
在一些需要对字符串做算法处理的场合,例如很多字符串算法题,需要对字符串的字串进行递归操作,若使用 std::string
作为参数进行递归,不可避免有大量拷贝。屏幕前的看官可以翻翻 LeetCode提交记录,如果有使用 std::string
的递归,可以试着改成 std::string_view
,对比一下运算时间和内存,通常优势是比较明显的。
你是否还在寻找稳定的海外服务器提供商?创新互联www.cdcxhl.cn海外机房具备T级流量清洗系统配攻击溯源,准确流量调度确保服务器高可用性,企业级服务器适合批量采购,新人活动首月15元起,快前往官网查看详情吧