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 Tree Model
• 嵌套地图
• Trie树

原始问题:(针对具体情况）

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中使用它。

Answer 2

Qt TreeModels经过优化，可以与TreeViews一起使用，非常适合排序等。对于随机访问双向映射，它们并不是真正意义上的。

嵌套地图将针对单向翻译进行优化。要有效地前进和后退，您需要单独镜像地图以进行前向和后向翻译。

使用std :: maps构建它。如果需要，请对其进行分析并进行优化。