10
votes

std :: map: est la recherche (clé) -> seconde plus rapide que l'opérateur []?

std::map<long, double> x;
x[5] = 1.2;

double y = x[5];
double z = x.find(5)->second;
Will one of these 2 assignments execute faster than the other? (supposing that the requested key is always present in the map) Is there any overhead associated with the dereferencing of the iterator when doing x.find(5)->second ?EDIT: Thanks for the replies. In my particular function, now that I know it is not slower, I will probably go with x.find(5)->second as I need to mark my function const (the map is a member variable) and the [] operator obviously does not allow that (as it potentially modifies the map is a key is missing).

0 commentaires

3 Réponses :


11
votes

Cela ne répond pas à votre question, mais je voudrais souligner un problème avec la façon dont vous utilisez trouver . XXX

Je ne peux pas commenter sur lequel est plus rapide. Mais je peux sûrement dire que la première approche est sûre!

Et si la carte ne contient pas la clé donnée?

Dans la première approche, il sera créer une nouvelle paire > Avec la clé et initialiser la valeur avec la valeur par défaut de double (qui est zéro) et le renvoie.

Mais le deuxième après-autre? Recherche retournera Map :: end si la clé spécifiée ne se trouve pas dans le conteneur et que vous êtes la déséroférance. Crash de programme!

La bonne façon d'utiliser trouver est la suivante: xxx


8 commentaires

Je n'ai pas bownvote (en fait je vous ai donné +1), mais une pensée est que cela pourrait être subjectif lequel des résultats de la condition d'échec est meilleur. Peut-être que vous ne voulez pas créer de nouvelles valeurs silencieusement sur la carte et préférerais traiter une exception / comparer à plan :: end / autre. Cela dépend de votre cas d'utilisation.


Je ne t'ai pas répondu, mais cela ne répond pas vraiment à la question de l'OP.


Je n'ai pas répondu, mais je peux penser à quelques raisons que quelqu'un pourrait avoir. (1) Dans ce cas, le questionneur a dit de supposer que la clé serait présente. (2) La question est sur laquelle est plus rapide, non "plus sûre". (3) Le cas d'échec en silence n'est pas nécessairement "plus sûr" que d'échouer de manière spectaculaire. C'est ainsi que les missiles sont lancés accidentellement.


@Marlon: Je n'ai pas dit que cela répondit la question. J'expliquais le problème avec l'extrait de code.


Je ne suis pas le Downvoter, mais vous avez ignoré la partie de ma question qui dit "supposant que la clé demandée soit toujours présente sur la carte" (Je sais certainement que les clés sont là, mais cela s'appelle un grand nombre de fois. dans une boucle, c'est pourquoi il doit être efficace). Je ne demandais pas ce qui se passe si ce n'est pas là (je sais déjà cette différence), ce qui est juste plus rapide.


Oups, n'a pas vu tous ces commentaires avant de poster le mien :)


@Nawaz: La réponse que vous avez donnée est une réponse latérale et non ce que PO veut. En ce qui concerne la mention qui est plus sûre, selon le scénario, on peut ne pas vouloir qu'une nouvelle entrée soit faite si la clé non trouvée. Dans ce cas, la recherche est la droite (donc sûre pour cette affaire).


@LAURENT: Je vois. Je pense que la publication de Marlon répond à peu près à votre question. La performance est presque la même!



2
votes

La première affectation utilisant opérateur [] devra effectuer la même déséroférence pour extraire la valeur explicite dans Rechercher () -> secondaire . Vous pouvez profiler pour être sûr, mais les performances doivent être suffisamment proches que vous devriez utiliser le formulaire le plus clair dans votre code.


0 commentaires

9
votes

a pris cette ligne droite de : xxx

il ressemble à peu près de la même chose. Devrait-il y avoir une différence entre: xxx

et xxx

Je ne le pense pas. < / p>


0 commentaires