Sont const_iterators plus vite?

Question

Nos directives de codage dire préférez const_iterator, parce qu'ils sont un peu plus rapide par rapport à la normale de l'itérateur. Il semble que le compilateur optimise le code lorsque vous utilisez la const _iterator.

Est-il vraiment correct ? Si oui, ce qui se passe vraiment à l'interne pour faire const_iterator prend le bord?.

EDIT: j'ai écrit petit test pour vérifier const_iterator vs itérateur et trouvé des résultats différents:

pour l'itération de 10 000 objets const_terator a été prise quelques millisecondes(autour de 16 ms) moins. Mais pas toujours. Il y avait des itérations dans lequel les deux sont égaux.

Answer 1

Si rien d'autre, un const_iterator lit mieux, puisqu'il raconte n'importe qui qui lit le code "je suis juste de parcourir ce conteneur, de ne pas jouer avec les objets contenus".

C'est une grande victoire, jamais l'esprit les différences de performances.

Answer 2

La ligne directrice que nous utilisons est:

Préférez toujours const sur les non-const

Si vous avez tendance à utiliser const objet, vous vous habituez à l'utilisation constante des opérations sur les objets que vous obtenez et qui est autant que l'utilisation *const_iterator* autant que possible.

Constness a un virale de la propriété. Une fois que vous obtenez à utiliser, il se propage à l'ensemble de votre code. Votre non-mutation des méthodes devenir constant, et qui nécessite l'utilisation seule constante opérations sur les attributs, et en passant la référence constante autour de, que même les forces de la constante d'activités...

Pour moi, l'avantage de performance de l'aide constante des itérateurs sur les non constante itérateurs (le cas échéant) est beaucoup moins important que l'amélioration dans le code lui-même. Les opérations signifié (conçu) pour être non-mutation sont constants.

Answer 3

Il y a plusieurs raisons de préférer const_iterator, n'importe quoi:

1. L'utilisation de const exprime code de l'intention (c'est à dire la lecture, pas de mutation de ces objets).
2. L'utilisation de const(_iterator) empêche toute modification accidentelle de données. (voir ci-dessus)
3. Certaines bibliothèques utilisent manque-de-const begin() de drapeau données sale (c'est à dire OpenSG) et de l'envoyer à d'autres threads/sur-le réseau de synchronisation, de sorte qu'il a une réelle incidence sur les performances.
4. Aussi, vous permettant d'accéder à des non-const fonctions de membre pourrait avoir des effets secondaires, que vous n'avez pas l'intention (de la même manière que ci-dessus), par exemple le détachement de copie sur écriture des conteneurs à partir de données partagées. Qt pour l'un, c'est exactement ce que.

Comme un exemple de ce dernier point ci-dessus, voici un extrait de qmap.h en Qt:

inline iterator begin() { detach(); return iterator(e->forward[0]); }
inline const_iterator begin() const { return const_iterator(e->forward[0]); }

Même si l'itérateur et const_iterator sont pratiquement équivalentes (sauf pour l' const), detach() crée une nouvelle copie de données si il y a deux ou plusieurs objets à l'aide.

Bien sûr, il y a des points de données dans l'autre sens:

1. Pour les conteneurs STL et et beaucoup de simples copier-sémantique des conteneurs n'a pas d'importance pour la performance. Le code est équivalent. Cependant, la mesure d'écrire un code clair et éviter les bugs qui l'emporte.
2. Const est viral, donc si vous travaillez dans un héritage de la base de code où const est mal (ou tout simplement pas) mis en œuvre, vous pourriez avoir à travailler avec des non-const itérateurs.
3. Apparemment, certains pré C++0x STL a un bug où const_iterators ne pouvait pas être utilisé pour effacer() éléments de conteneurs.

Answer 4

Nos directives de codage dire préférez const_iterator

Jetez un oeil à cet article de Scott Meyers ici. Il explique pourquoi on doit préférer itérateur sur const_iterator.