晏阳初乡村建设网站秦皇岛解封最新消息今天

晏阳初乡村建设网站,秦皇岛解封最新消息今天,煎蛋网 wordpress,2核4g做网站std::string_view 全攻略 笔者最近常常跟字符串打交道#xff0c;这篇博客也是跟先前的C工程实践一起联动的——也就是解决IniParser的问题 传送门 CSDN#xff1a;现代C工程实践#xff1a;简单的IniParser2#xff1a;分解需求与编写split-CSDN博客知乎#xff1a;现代…std::string_view 全攻略笔者最近常常跟字符串打交道这篇博客也是跟先前的C工程实践一起联动的——也就是解决IniParser的问题传送门CSDN现代C工程实践简单的IniParser2分解需求与编写split-CSDN博客知乎现代C工程实践简单的IniParser2分解需求与编写split - 老老老陈醋的文章 - 知乎Github: Awesome-Embedded-Learning-Studio/Tutorial_cpp_SimpleIniParser: 这是我们C工程化开始的旅程手搓一个最简单的Ini分析器This is the beginning of our journey in C engineering! Handcrafting the simplest INI parser!先别急先问是什么std::string_view是什么为什么要它std::string_viewC17是一个轻量、不可变的“字符串视图”类型它不拥有字符缓冲区只保存指向字符序列起始处的指针和长度sizePS所以你看是不是很“视图”用于以 O(1) 的代价表示子串、字面量或其他字符序列的只读窗口。它的设计是为了解决频繁读操作时不必要的内存拷贝问题从而提高性能与通用性。Sir This way: C参考文献std::string_view 的实现原理PS不感兴趣就直接跳但是知道比不知道好:)虽然标准没有规定具体的内部结构但所有主流实现libstdc / libc / MSVC STL都使用两字段或三字段的简单结构templateclassCharT,classTraitsstd::char_traitsCharTclassbasic_string_view{constCharT*_ptr;// 指向底层字符序列不拥有size_t _len;// 长度不含 \0};特点不拥有内存non-owning view只保存两份轻量信息指针 长度复制便宜仅复制两个字8 字节指针 8 字节 size任何“子串操作”substr、remove_prefix都只改_ptr/_lenO(1) 无分配相比之下std::string除了指针外还管理容量、分配器、部分还包含小字符串优化SSO同时有析构逻辑成本完全不同。所以这样看std::string显然很重对吧。string_view 内部函数如何处理数据例substrstring_viewsubstr(size_t pos,size_t count)const{returnstring_view(_ptrpos,min(count,_len-pos));}完全没有开辟新内存仅调整指针和长度。remove_prefixvoidremove_prefix(size_t n){_ptrn;_len-n;}compare / find 等操作全部是对_ptr指向的内存直接遍历通常依赖Traits::compare不涉及新内存创建。一句话总结其实现哲学**string_view是一个 lightweight façade轻量外壳把任意字符序列变成 “可操作的只读字符串对象”但永远不负责内存。**这种我相信大伙就会拉高警惕了。肯定处理不好就要跟生命周期炸了。所以这既是优势也是最大的风险来源生命周期问题。与 const char* 的本质对比逐项分析笔者记得之前有在知乎上看到大佬们的讨论设计上跟const char*的区别在哪里实际上回顾设计笔者认为如果说std::string封装了char[]那么string_view封装了const char*。表达能力string_view 是“带长度的字符串”char* 是“指针”感谢GPT我写了一会让他拉了一个表格可以看看特性std::string_viewconst char*是否包含长度✔ 有size()❌ 没有需要strlen表示子串是否安全✔ 完整支持有长度❌ 只能通过临时修改\0或传递额外长度是否可以为任意字节序列服务含零字符✔ 可以长度独立❌ 需要 NUL 终止是否支持遍历、查找、比较等高级接口✔ 丰富的成员函数❌ 几乎没有用 C 函数字面量转换是否简洁✔abcsvC17 UDL✔ 可直接使用abc核心区别是【string_view (指针, 长度)】【const char* 指针 隐含以 ‘\0’ 终止】所以string_view的显式长度是一个巨大的优势。因为有的时候这种\0不是我们的意图。2安全性string_view 对比 const char*string_view 在访问越界方面更安全sv[i]// 有边界检查debugrelease 通常不检查但基于 _len 计算而p[i]// 完全没有任何边界概念string_view 在生命周期方面更危险容易悬空string_view不拥有内存所以很容易这样写出 bugstd::string_view svstd::string(abc);// 指向临时 - 悬空但const char*同样会悬空例如constchar*pstd::string(abc).c_str();// 同样悬空两者都会悬空区别只是string_view更喜欢被隐式构造所以更容易犯错。3性能差异操作string_viewconst char*复制O(1) 两个字O(1) 一个字比较长度可用性能更好必须扫描并比对直到\0子串操作O(1)必须手工构造新的指针/终止符与 std::string 互操作 直接构造 view无拷贝❌ 常需 strlen可能 O(n)典型性能差扫描长度strlen(constchar*)// O(n)sv.size()// O(1)所以如果你的函数这样写voidfoo(constchar*p);然后内部多次strlen(p)会变成 O(n²) 模式。改成voidfoo(std::string_view sv);就没有这种性能坑。用法层面的巨大差异string_view 是 “只读字符串”的语义类型它明确告诉读者我不修改我不复制我不拥有数据而 const char* 无法表达所有这些语义constchar*p;你根本不知道p 是不是只读也许来自 char 数组p 是否指向 NUL 终止的空间p 是否有固定长度p 是否能包含 ‘\0’p 是否有效string_view 解决了这些语义上的歧义。常用成员 / 操作速查选取关键 APIsize(), length(), empty()长度/空判断如basic_string。data()返回指向当前视图起始字符的指针 ——注意不保证以\0结尾如果你从完整 C 字符串构造且未做子视图操作可能是以\0终止但不能依赖。因此用data()传给要求 NUL 结尾的 C API 常常是错误的。substr(pos, count)返回一个新的string_viewO(1)表示子区间不分配内存。remove_prefix(n),remove_suffix(n)修改视图移动起点或缩短长度也都是 O(1)。比较函数compare()与重载了, , 等操作符按字典序 / 长度等比较规则operator支持流输出。字面量与便捷写法C17 提供了 UDLuser-defined-literalsv可以直接写hellosv得到一个std::string_view该字面量在std::literals::string_view_literals命名空间中。这是构造对字面量的常用快捷方式。性能语义与接口设计建议传参按值还是按const通常建议把std::string_view当成小的值类型来传递即按值。理由包括传值消除一次间接代码更可读也见 ISO C 社区与 Abseil 的建议不过在某些 ABI/平台历史上 MSVC x86-64 等下按值并不总是更快但整体实践建议“习惯性按值传递”。用作容器键unordered_map/unordered_set标准库为string_view提供了std::hash的特化可以直接作为键不过关键在于使用string_view作为键时必须保证被视图指向的数据的生命周期至少与哈希表中该键的生命周期一样长否则会发生悬空引用。std::hashstring_view与std::hashstring的行为在 cppreference 有说明hash 相等性的描述。还要再强调一下生命周期与悬空真正的“坑”核心警示std::string_view不拥有底层数据。它不会延长底层对象的生命周期。典型错误场景std::string_viewf(){std::string shello;returnstd::string_view{s};// 返回后 string s 被销毁视图悬空 —— 未定义行为}或autosvstd::string_view{some_function_returning_temp_string()};// temp 被析构sv 悬空这类“use-after-free / dangling view”是string_view最常见与最严重的 bug 根源。静态分析器和代码审查要重点关注这类模式。学术/工程社区也有研究工具检测这类问题。如何防御在 API 层级明确语义若函数需要持有字符串副本参数就用std::string或在内部做std::string的拷贝若只在调用期内使用则string_view很合适。不把string_view存入需要长期持有的容器除非你能保证底层缓冲区的所有权例如静态常量字面量或一直存活的池。在从std::string获取string_view并传递给异步/延迟执行的代码时尤其小心例如线程、异步任务、lambda 捕获后延迟执行。使用静态分析工具或编译器警告并保持 Code Review 关注来捕捉典型用法错误。data()与 NUL 终止问题实践警告string_view::data()返回的缓冲并不保证以 NUL (\0) 结尾例如对一个通过remove_suffix或substr生成的视图因此把sv.data()直接传给只接受 C 风格 NUL 终止字符串的 API如printf(%s)、一些老 C 库函数是容易出错的。若确实需要 NUL 终止必须显式拷贝到std::string并在末尾加\0或在 C20 可用std::string svstr(sv);。常见误用样例与正确写法代码示例笔者之前不太会用std::string_view就干出来过这种事情错误返回指向临时的 string_view悬空std::string_viewmake_view_bad(){returnstd::string(temp);// UB返回的 view 指向临时 string 的缓冲区}正确如果需要长期保存拷贝到 std::stringstd::stringmake_copy(){returnstd::string(temp);}autovmake_copy();// v 是 std::string拥有数据std::string_view svv;// sv 可安全使用前提是 v 不销毁好的 API 习惯接受任意只读字符串#includestring_viewvoidprocess(std::string_view sv){// 只在调用期间使用 svif(sv.size()10){/*...*/}}intmain(){std::string shello;process(s);// implicit conversionprocess(literal);// ok, string literal 的 storage 是静态的会被放置到data段所以无所谓}通常推荐把std::string_view作为“只读输入参数”的首选类型按值。与 std::string / char* 的转换与互操作string_view可隐式从std::string或const char*构造注意悬空风险。std::string可以从string_view构造会进行拷贝。若需 C 风格 NUL 结尾的缓冲区构造后可用c_str()或data()C11 后data()返回 NUL 终止的 char* 在部分版本的标准里有细微差别但从 C17std::string::data()保证可用于 read-only NUL-terminated C string。对于string_view::data()仍不保证末尾 NUL。Reference下面是本文中用到的重要参考资料点击即可阅读权威描述cppreference —std::basic_string_view总览、成员、注意事项。(C参考文献)cppreference —basic_string_view构造函数细节页面。(C参考文献)cppreference —data()的说明不保证 NUL。(C参考文献)cppreference — 用户字面量operatorsv...sv。(C参考文献)cppreference —std::hash对string_view的特化说明。(C参考文献)cppreference — 比较/运算符文档compare / operator 等。(C参考文献)cppreference —operator流输出支持。(C参考文献)学术/工程关于string_view生命周期错误检测的研究示例论文。(arXiv)讨论/示例StackOverflow 上关于string_view悬空与实际示例的讨论入门级错误示例。(Stack Overflow)ISO WG21 提案 / 未来工作zstring_view提案示例。(开放标准)结束语std::string_view是 C17 带来的非常实用且高效的工具在适合的地方它能显著减少复制提高解析/处理字符串的性能。但同时它也把“谁负责数据所有权”这个问题显式地交还给了程序员。把string_view当作“轻量的只读窗口”来用并在接口设计与生命周期边界处格外小心你就能既享受性能又保证安全。