用于编辑文本的最小cpu和内存开销数据结构?

时间:2011-10-26 12:19:58

标签: c++ text structure editing overhead

我正在创建思维导图应用程序,我想知道“笔记”编辑器的最佳数据结构是什么。 Notes可能只是几个符号,可能是页面长,并且正在更新,编辑,随机播放等等。该应用程序旨在在移动平台上运行,因此处理和内存开销应该是最小的。

我的基本想法是实现一个在编辑过程中对注释进行分段的绳索/链接列表类型结构,以避免在容器已满时重新分配注释的开销,并避免分配不必要的空间,例如使用动态增长的向量。

然而,过分碎片将不可避免地引入其自身的开销,因此我的实现的第二部分计划将笔记结构中使用的绳索结构转换为顺序数据结构以便存储和快速读取。

基本上,对象是从顺序数据结构中存储和读取的,但是在编辑时,它们会被复制到碎片数据结构中,完成编辑后,对象将被转换回来。

这是一个好主意吗?如果没有,那么欢迎提出建议。无论哪种方式,任何人都知道我可以从中学到一些类似的开源实现?

2 个答案:

答案 0 :(得分:3)

关于开源,总有emacs :-)。但我怀疑 你正在寻找一些更简单的东西。

这里没有一个正确答案。传统的实施方式 我见过使用一个非常大的缓冲区(今天std::vector<char>), 分为三个逻辑块:光标前的文本,自由空间, 和光标后的文字。使用此解决方案,移动光标 需要移动光标移动的文本,但插入和 删除光标处的文字不涉及任何轮班。

我不确定传统方法今天是否合理(尽管如此) 也许在嵌入式机器上)。我开始只是使用 std::vector<char>以一种非常天真的方式,只有我改变一次 从典型的编辑会话中分析数据。我会把它包起来 但是,在Buffer类中,只提供我需要的接口 为了简化未来向不同战略的迁移。

答案 1 :(得分:0)

这取决于您实际计划编辑的文字数量。之前的回答建议std::vector<char>达到极限。

您提出了一些建议:在实施Wiki编辑器时,我从Scintilla特别是related section学到了很多东西。