std::string 可以重载“substr”吗?对于 rvalue *this 并窃取资源?
我突然想到,当 std::string
的 substr
操作可以从 *this 窃取分配的内存时,它对于右值来说会更有效
。
N3225 的标准库包含以下 std::string
成员函数声明
basic_string substr(size_type pos = 0, size_type n = npos) const;
可以为右值重载实现优化的 substr
实现,并提供两个版本,其中之一是哪个可以重用右值字符串的缓冲区?
basic_string substr(size_type pos = 0) &&;
basic_string substr(size_type pos, size_type n) const;
我想右值版本可以按如下方式实现,重用 *this 的内存,并将 *this
设置为移出状态。
basic_string substr(size_type pos = 0) && {
basic_string __r;
__r.__internal_share_buf(pos, __start + pos, __size - pos);
__start = 0; // or whatever the 'empty' state is
return __r;
}
这是否可以在常见字符串实现上以有效的方式工作,或者是否需要太多的内务处理?
It just occurred to me I noticed that std::string
's substr
operation could be much more efficient for rvalues when it could steal the allocated memory from *this
.
The Standard library of N3225 contains the following member function declaration of std::string
basic_string substr(size_type pos = 0, size_type n = npos) const;
Can an implementation that could implement an optimized substr
for rvalues overload that and provide two versions, one of which could reuse the buffer for rvalue strings?
basic_string substr(size_type pos = 0) &&;
basic_string substr(size_type pos, size_type n) const;
I imagine the rvalue version could be implemented as follows, reusing the memory of *this
an setting *this
to a moved-from state.
basic_string substr(size_type pos = 0) && {
basic_string __r;
__r.__internal_share_buf(pos, __start + pos, __size - pos);
__start = 0; // or whatever the 'empty' state is
return __r;
}
Does this work in an efficient fashion on common string implementations or would this take too much housekeeping?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
首先,实现不能添加窃取源的重载,因为这是可以检测到的:
如果实现从
s
窃取数据,第一个断言将会失败,并且 C++0x 措辞本质上禁止复制写时。其次,这不一定是一种优化:您必须在 std::string 中添加额外的内务处理来处理它是较大字符串的子字符串的情况,这意味着保留当不再有任何字符串引用大字符串时,只有它的一些子字符串时,就会出现大块。
Firstly, an implementation cannot add an overload that steals the source, since that would be detectable:
The first assert would fail if the implementation stole the data from
s
, and the C++0x wording essentially outlaws copy on write.Secondly, this wouldn't necessarily be an optimization anyway: you'd have to add additional housekeeping in
std::string
to handle the case that it's a substring of a larger string, and it would mean keeping large blocks around when there was no longer any strings referencing the large string, just some substring of it.是的,也许应该向标准委员会提出建议,或者在图书馆中实施。我真的不知道优化会有多大价值。这本身就是一项有趣的研究。
当 gcc 增加对右值
this
的支持时,应该有人尝试一下并报告它的有用性。Yes, and maybe it should be proposed to the standards committee, or maybe implemented in a library. I don't really know how valuable the optimization would be. And that would be an interesting study all on its own.
When gcc grows support for r-value
this
, someone ought to try it and report how useful it is.有一些字符串类实现了写时复制。但我不建议在您的项目中添加另一种字符串类型,除非确实合理。
查看 内存高效 C++ 字符串(interning 、绳索、写时复制等)
There are a few string classes out there implementing copy-on-write. But I wouldn't recommend adding yet another string type to your project unless really justified.
Check out the discussion in Memory-efficient C++ strings (interning, ropes, copy-on-write, etc)