c++ - 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 树模型
• 嵌套 map
• 尝试

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

Qt 树模型、嵌套映射或其他一些方法是否更适合存储字典？我意识到“更好”可能是主观的，但我想知道权衡。

我已经在构建一个 Qt 树模型来在 QTreeView 中显示一些其他数据，这样代码就已经存在并且可以很容易地使用。树模型是否允许更灵活地加载具有不同结构的词典？有一个更好的方法吗？还是标准设计模式？

Answer 1

在我看来，命令树中每个级别的项目数量太少，不适合使用 trie。特里树(参见 http://en.wikipedia.org/wiki/Trie)由于其较大的分支因子，最适合大量项目——例如自然语言词典，正如 volodymyr 所指出的。

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

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