STL 绳索 - 何时何地使用

发布于 2024-09-01 22:12:57 字数 34 浏览 2 评论 0原文

我想知道在什么情况下你会在另一个STL容器上使用绳子?

I was wondering under what circumstances you would use a rope over another STL container?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(5

抱着落日 2024-09-08 22:12:57

绳子是一根可伸缩的绳子
实施:它们是为
高效运作涉及
字符串作为一个整体。操作如
赋值、串联和
子字符串花费的时间几乎是
与长度无关
细绳。与 C 弦不同,绳索是
非常合理的代表
长字符串,例如编辑缓冲区或
邮件消息。

优点

  1. 连接速度更快
    涉及长的子串操作
    字符串。在中插入一个字符
    10兆字节绳子的中间应该
    大约为 10 秒
    微秒,即使是副本
    原件被保留,例如作为
    编辑历史记录。相比之下,这将
    采取一秒钟的顺序
    传统的“扁平”字符串
    表示。所需时间为
    连接可以被视为
    对于大多数应用来说是常数。这是
    使用绳子作为完全合理的
    a 中文件的表示
    文本编辑器。

  2. 可能有更好的空间
    表现。稍作修改
    绳子可以与共享内存
    原来的。绳索被分配在小
    块,显着减少内存
    引入的碎片问题
    大块

  3. 赋值只是一个(可能是
    引用计数)指针赋值。
    与引用计数的写时复制不同
    实施,这在很大程度上仍然是
    即使其中一份副本为真
    随后稍作修改。这是
    老检查站非常便宜
    字符串的版本,例如在编辑中
    历史。

  4. 可以查看函数
    将角色制作成绳子。因此一个
    一根绳子可能有100MByte
    文件,只有在该情况下才是只读的
    检查字符串的一部分。
    将字符串连接到末尾
    这样的文件不涉及读取
    文件。 (目前
    该设施的实施是
    不完整。)

https:// wayback.archive.org/web/20130102093702/https://www.sgi.com/tech/stl/Rope.html

Ropes are a scalable string
implementation: they are designed for
efficient operation that involve the
string as a whole. Operations such as
assignment, concatenation, and
substring take time that is nearly
independent of the length of the
string. Unlike C strings, ropes are a
reasonable representation for very
long strings such as edit buffers or
mail messages.

Advantages:

  1. Much faster concatenation and
    substring operations involving long
    strings. Inserting a character in the
    middle of a 10 megabyte rope should
    take on the order of 10s of
    microseconds, even if a copy of the
    original is kept, e.g. as part of an
    edit history. In contrast, this would
    take on the order of a second for
    conventional "flat" string
    representation. The time required for
    concatenation can be viewed as
    constant for most applications. It is
    perfectly reasonable to use a rope as
    the representation of a file inside a
    text editor.

  2. Potentially much better space
    performance. Minor modifications of a
    rope can share memory with the
    original. Ropes are allocated in small
    chunks, significantly reducing memory
    fragmentation problems introduced by
    large blocks

  3. Assignment is simply a (possibly
    reference counted) pointer assignment.
    Unlike reference-counted copy-on-write
    implementations, this remains largely
    true even if one of the copies is
    subsequently slightly modified. It is
    very inexpensive to checkpoint old
    versions of a string, e.g. in an edit
    history.

  4. It is possible to view a function
    producing characters as a rope. Thus a
    piece of a rope may be a 100MByte
    file, which is read only when that
    section of the string is examined.
    Concatenating a string to the end of
    such a file does not involve reading
    the file. (Currently the
    implementation of this facility is
    incomplete.)

https://wayback.archive.org/web/20130102093702/https://www.sgi.com/tech/stl/Rope.html

在梵高的星空下 2024-09-08 22:12:57

它是处理大数据的string 的非标准替代方案。请参阅此处了解它是如何工作的。

It is a non-standard alternative to string that handles large data sizes. See here for how it works.

追星践月 2024-09-08 22:12:57

绳索唯一的缺点是螺纹和误用。

在 Linux(可能还有大多数其他操作系统)下,据说线程安全代码是导致 Rope 变慢的原因。因此,我只是将代码删除(为 threads-off 设置编译器定义),因为我在嵌入式平台中使用单个线程。

否则,绳索比字符串快得多,在大缓冲区上内存不足的可能性较小,并且对于大缓冲区的编辑要快得多;比如去掉圣经中间的一个坏人物。

这是由于绳索被解释为数据的方式所致。许多较小的“字符串”通过链表链接在一起以产生最终的字符串。

The only bad thing with ropes is threads and misuse.

Under Linux (and probably most other OSes) it is said that the thread-safety code is what makes ropes so much slower. So I just rip that code out (set a compiler def for threads-off), because I am using a single thread in an embedded platform.

Otherwise, ropes are much faster than strings, have less likelihood of getting out of memory on large buffers, and are much faster for edits of large buffers; Such as removing a bad character in the middle of the Bible.

This is due to the way in which a rope is interpreted as data. As a lot of little smaller 'strings' chained together via a linked-list to produce the final string.

〆凄凉。 2024-09-08 22:12:57

我根本不会使用它,但那是因为我有点“易于移植”的怪胎,并且倾向于只使用沼泽标准容器。绳索是 SGI 的 STL 实现的一部分,而不是 C++ 标准的一部分。

I wouldn't use it at all, but that's because I'm bit of an "easy portability" freak, and tend only to use bog-standard containers. The rope is part of SGI's STL implementation, and is not part of the C++ Standard.

牵你的手,一向走下去 2024-09-08 22:12:57

这里非常强调由字符组成的字符串,但绳索只是一个具有快速插入和删除(序列内任何位置)的一维序列。

似乎有点令人惊讶的是,任何东西(除了字符串)都很少需要这样的基本功能。我会在哪里使用整数绳?我不知道,因为操纵它需要来自某个地方的索引。

最好的现实世界示例是我正在制作一个 UI,让用户查看由数千张图像组成的数据集,并且用户需要能够删除其中一些图像并重新排列其他图像的顺序。

There is a lot of emphasis here on strings made up of characters, but rope is simply a 1D sequence with fast insertions and deletions (anywhere within the sequence).

It seems a bit surprising that such a basic capability is rarely required for anything (other than strings). Where would I use a rope of integers? I don't know, because manipulating it requires the indices to come from somewhere.

The best contrived real-world example would be where I'm making a UI to let the user view a dataset made up of thousands of images, and the user needs to be able to delete some of them and rearrange the order of the others.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文