std::map
написан с учетом производительности в любом случае, хотя он и имеет некоторые накладные расходы, поскольку они пытались обобщить на все обстоятельства, он, вероятно, в конечном итоге окажется более эффективным, чем ваша собственная реализация.В нем используется красно-черное двоичное дерево, обеспечивающее эффективность всех его операций O [log n] (кроме копирования и повторения по очевидным причинам).
Какчасто вы будете читать / писать на карте, и как долго каждый элемент будет на ней?Кроме того, вы должны учитывать, как часто вам нужно будет изменять размер и т. Д. Каждый из этих вопросов имеет решающее значение для выбора правильной структуры данных для вашей реализации.
В целом, одна из функций std, вероятно, будет той, которую вы хотите, если вам не нужна функциональность, которой нет ни в одной из них, или если у вас есть идея, которая может улучшить их временную сложность.
РЕДАКТИРОВАТЬ: На основании вашего обновления я согласен с KerrekSB что если вы используете C ++ 0x, тогда std::unordered_map
будет хорошей структурой данных для использования в этом случае.Однако имейте в виду, что ваша производительность может ухудшиться до линейной сложности времени, если у вас есть конфликтующие хэши (это не может произойти с std::map
), поскольку они будут хранить две пары в одном сегменте.Хотя это редко, вероятность этого очевидно увеличивается с количеством элементов.Поэтому, если вы пишете огромную игру, возможно, что std::unordered_map
станет менее оптимальным, чем std::map
.Просто соображение.:)