2014-02-19 41 views
0

我不确定,如果这是发布此问题的正确位置。请让我知道,如果不是。比图更好的东西<string,map <string,vector>

我有一些'实体'。每个实体都有许多属性(所有实体具有相同数量的属性),这些属性本身存储为数组(长度相同)。我希望以这种方式存储'实体',以便我可以通过名称获取每个实体。

为此,我应该使用map<string, entity>来按名称存储每个实体。

现在的麻烦是,在这个需求(存储多个实体)出现之前,我曾经将一个实体存储为map<string, vector>,其中每个向量是一个属性,字符串表示属性名称。

考虑到这一点map<string, entity>现在变成: map<string, map<string, vector>

什么是以前一个简单而优雅的解决方案已经成为难以阅读和难以使用。

  • 封装map<string, vector>作为一个实体类似乎走得太远了漂亮的代码的缘故(因为我没有任何程序放在类)。

  • 我会更好地使用实体作为一个结构来“美化”代码吗?

  • 还是有一个更简单或更优雅的解决方案,我错过了?

  • 或者这个实现是我所希望的最好的吗?

注:我正在处理一个相当大的数据集。地图上将会有1500-2000个实体。每个实体将具有4-10个属性。每个属性将有近10000个值。性能是一个约束。

+3

使用typedef? –

+0

multimap代替映射如何 ST3

+1

@ ST3 multimap是一个允许多个值针对单个键存储的映射。对?在这种情况下multimap会有帮助吗? –

回答

2

无论如何,我将建议一个Entity类或结构。原因在于您的实现可能会随时间发生变化(例如,从map<string, vector<T>>multimap<string, T>unordered_map),并且给实体一个实际的API允许您封装这些更改并对实体由其他代码处理的方式施加限制。它还会使代码和可能的编译器错误消息更容易阅读。

如果将类/结构实现完全放置在标题中并且不使用virtual方法,则性能不应该受到影响。用Stroustrup的话来说,C++是一种“轻量级抽象语言”,被解析为“轻量级抽象语言”,这是一个轻量级抽象看起来合适的地方。

+1

确实,这似乎是一种干净的方式,除非您绝对确定*实体可用或使用的属性不会在将来需要更改或扩展,否则您的设计应该保留属性选择器(字符串或枚举),以便将来可以添加新的(并删除其他)。 –

相关问题