Sim*_*ton 3 c++ stl string-view
这些方法的实现对我来说似乎很简单,它们可以使用std::string并且std::string_view更易于互换.毕竟,std::string_view具有使对象处于与这些方法相同状态的构造函数.可以解决丢失的方法,如下所示:
std::string s {"abcd"};
std::string_view v {s.c_str()};
std::cout << "ctor: " << v << std::endl; // "abcd"
v = {s.c_str() + 1, 2};
std::cout << "assign: " << v << std::endl; // "bc"
v = {nullptr}; // or even v = {};
std::cout << "clear: " << v << std::endl; // ""
Run Code Online (Sandbox Code Playgroud)
那么,在标准中不包括这两种明显方法的原因是什么?
更新:你的评论中的一个普遍问题似乎是"有什么意义?",所以我会给你一些背景信息.我正在解析一个大字符串,结果是一个子串结构.结果结构是字符串视图的自然候选者,因此我不必复制所有那些甚至重叠的字符串.部分结果是映射到字符串视图,因此我可能需要在获取密钥时将它们构造为空,并在获取值时稍后填充它们.在解析时,我需要跟踪中间字符串,这涉及更新和重置它们.现在它们也可以被字符串视图替换,这就是我在那些缺少的函数上发生的事情.当然我可以继续使用字符串或用普通的旧ptr-ptr或ptr-size对替换它们,但这正是std::string_view为了什么,对吧?
std::string由于其丰富的API,该界面的声誉不佳,这就是为什么std::string_view不太可能获得尽可能多的方法,std::string因为它方便或使这两种类型更易于互换.
但更重要的是,这些类型并不是可以互换的.查看要清除的字符容器是什么意思?正如clear()所有STL容器上都存在的那样并且做了一些有意义的事情,因为它std::string_view::clear()会让人很困惑.
此外,某些数据的视图用于临时消费,例如只读函数参数.你为什么要分配给它呢?这是一个示例函数签名,它使用std::string_view:
// Called e.g. with "x86_64-Darwin-16.7.0"
std::string_view extractOSName(std::string_view configStr)
{
// Parse input, return a new view. Lifetime/ownership managed by caller.
// No need to re-assign anything, let alone "clearing" them.
}
Run Code Online (Sandbox Code Playgroud)
这实际上只是猜测,但普遍的共识似乎是这些操作相当不清楚。
就我个人而言,我认为“清除视图”是完全有道理的(我们也不要忘记这一点remove_prefix并remove_suffix存在!虽然见下文......),但我也同意还有其他解释,这些解释可能很常见,但意义不大。回想一下,它的string_view目的是补充const std::string&,而不是std::string,并且您命名的两个函数都不是 的std::string常量接口的一部分。
老实说,我们需要这种对话这一事实本身可能就是我们一开始就不具备该功能的一个很好的理由。
从最终提案来看string_view,以下段落不是关于assign或具体的,而是作为委员会对此主题的clear相关观点[笑] :
s/remove_prefix/pop_front/, etc.在 Kona 2012 中,我提出了一个包含 等成员
range<>的类pop_front来调整范围的边界。那里的讨论表明,委员会成员对轻量级作业与集装箱作业使用相同的名称感到不舒服。现有实践并未就该操作的名称达成一致,因此我保留了 Google 的StringPiece.
该提案实际上确实包括了一项,但在后来的一项孤立的、缺乏理由的提案中,clear()该提案被毫不客气地从登记簿中剔除。
现在,有人可能会争辩说,这些函数可以以不同的名称提供,但这从未被提议过,而且很难想象什么替代名称可以解决这个问题,而不仅仅是操作的坏名称。
因为我们可以分配一个新的string_view,包括一个空的,所以整个问题只要不去解决它就可以解决。
| 归档时间: |
|
| 查看次数: |
468 次 |
| 最近记录: |