Qt树模型与用于存储翻译字典的嵌套地图

Question

我正在使用Qt编写一个类,需要导入一个字典,用于查找命令并构建命令句.命令以分层方式排列,并具有相应的十六进制键和值定义.为了便于说明,它可能如下所示:

01 : Volume
        | - 01 : Step : 00=Down, 01=Up
        | - 02 : Set : ceil(255/100 * x)
02 : Power
        | - 01 : Power : 00=Off, 01=On
        | - 02 : Sleep : ...etc

我想加载这个词典,然后能够搜索"Volume/Set/50"并返回命令句"01 02 80"或查找"01 02 80"并返回"Volume/Set/50".

实际的实现稍微复杂一些,并且在树结构中具有不同级别的命令,并且可以包括来自单个句子中的不同级别的任何数量和命令组合.

编辑:

下面由volodymyr提供的评论介绍了一个我不熟悉的概念(Trie).它可能是这个特定场景的最佳实现,但我还需要进一步研究它.我仍然对我原来的问题的答案感兴趣(增加了Trie):

使用这些方法中的每一种方法有哪些优点和缺点？

• Qt树模型
• 嵌套地图
• 特里

原始问题:(对于上下文)

Qt树模型,嵌套地图或其他方法更适合存储字典吗？我意识到"更好"可能是主观的,但我想知道权衡.

我已经在构建Qt树模型以在QTreeView中显示一些其他数据,因此代码已经存在并且可以轻松使用.树模型是否允许更加灵活地加载具有不同结构的字典？有一个更好的方法吗？或者可能是标准的设计模式？

Answer 1

在我看来，命令树中每个级别的项目数量太小，无法证明使用 trie 是合理的。特里树（参见http://en.wikipedia.org/wiki/Trie）由于其分支因子较大，最适合处理大量项目——例如自然语言词典，正如 volodymyr 所指出的那样。

事实上，这个数字可能太小，甚至无法证明 std::map 的合理性。如果树中给定点的命令或代码不超过几十个，则线性搜索可能与地图中的搜索一样快，甚至更快。作为向量或列表的内存表示也会更加紧凑。也就是说， std::map 的界面似乎非常适合您想要做的事情，因此，在实践中，它可能仍然是总体上的最佳选择。

我看不出 QTreeModel 从任何角度（速度、内存、易用性）如何比 std::map 更好，除了它可以更好地与代码的其余部分配合，因为它是基于 Qt 的。然而，如果您甚至隐约怀疑这部分可能在没有 Qt 的情况下也有用途，我会毫不犹豫地选择标准库的东西（std::map）。选择 QTreeModel 而不是 std::map 的唯一真正令人信服的理由是，如果您实际上在 QTreeView 中使用了它。