嵌套地圖是否正常或非常糟糕？

嵌套地圖的幾個級別是正常的做法還是非常糟糕的？嵌套地圖是否正常或非常糟糕？

 // name property  // name singal   // interval of Ranges  // values 

typedef std::map<std::string, std::map<std::string, std::map<RangeSignalValue, std::string > > > sgHashSignals;

來源

2011-03-30 G-71

沒有錯，但多了一些類型定義可能更容易閱讀。 – 2011-03-30 17:23:12

我已經這樣做了。不過，我會打破定義成了不容易消化的塊狀：

typedef std::map<RangeSignalValue, std::string> RangeIntervalMap; 
typedef std::map<std::string, RangeIntervalMap> NameSignalMap; 
typedef std::map<std::string, NameSignalMap> NamePropertyMap;

來源

2011-03-30 17:24:43 sbi

+1，用於實際寫出'typedef's，而我仍然試圖記住語法！ ;） – FrustratedWithFormsDesigner 2011-03-30 17:34:53

如果它在上下文中有意義，那麼我看不到任何問題，除非它可能很難閱讀。可能使用typedef來使這些嵌套地圖中的一些更易於理解？

來源

2011-03-30 17:21:39 FrustratedWithFormsDesigner

謝謝你的好主意 – 2011-03-30 17:23:19

最大的問題是，查找是比選擇稍微慢一點：

  // property+signal, concatenated // interval of Ranges // values 

typedef std::map<std::string, std::map<RangeSignalValue, std::string > > sgHashSignals;

正是你應該如何連接第一兩個字符串取決於儘管如此，他們的語法。

這將用一個替換兩個字符串查找。缺點是需要更多的內存。

來源

2011-03-30 17:26:10 MSalters

你確定嗎？在帶有字符串鍵的地圖中查找需要字符串比較。如果這些字符串具有相同的前綴，那麼查找將不得不總是至少迭代前綴的字符。這是O（N），而地圖查找是O（log N）。我會說這取決於你所擁有的數據。 – sbi 2011-03-30 17:31:30

由於你的建議更快，這遠非如此。這取決於很多因素（包括執行情況）。我會用最自然的解決方案（這可能是嵌套地圖），並試驗如果我有性能問題。 – 2011-03-30 17:36:46

@sbi更不用說爲第二個鍵的每個實例複製第一個鍵都可以使用更多的內存。也許破壞當地。 – 2011-03-30 17:38:06

例如：

typedef std::map<RangeSignalValue, std::string> RangesValues; 

typedef std::map<std::string, std::map<std::string, RangesValues > > sgHashSignals;

來源

2011-03-30 17:26:45

嵌套地圖是否正常或非常糟糕？

回答

相關問題