Utilisation std::vector vs std::deque
Le
David FLEURY
Bonjour,
je suis plutôt pour l'utilisation générale du std::vector, et
j'utiliserais plus volontiers des std::list lors de fréquente insertion
(même si mon usage est plutôt restreint des std::list, les std::map
m'étant souvent plus utiles).
Avec des collègues, on a reparlé des std::deque. Il y a une dizaine
d'année, après des tests (*), j'en étais arrivé à la conclusion que ce
n'était pas vraiment rapide, en accès notamment, et qu'un std::vector
bien reservé (en cas de volume important) était bien plus efficace.
Aujourd'hui, je recherche de nouveau sur le sujet et je tombe (ou
retombe) sur http://www.gotw.ca/gotw/054.htm où il préfère l'utilisation
du std::deque et ce malgré son tableau de performance qui donne toujours
l'avantage au std::vector.
Du coup, j'ai un peu du mal à comprendre son raisonnement.
Avez-vous une idée sur la question(**)?
(*) Je referais des tests ce matin pour voir si les choses ont changé.
(**) La question pourrait s'étendre à l’intérêt nouvelle classe
std::array, utile ou juste pour rassurer des développeurs d'autres
horizons ? Est-ce que le std::vector est vraiment aussi lent que ça
et/ou "trop" gros pour avoir à utiliser une nouvelle classe pour
représenter un tableau (ou un espace de mémoire continue?)
David
je suis plutôt pour l'utilisation générale du std::vector, et
j'utiliserais plus volontiers des std::list lors de fréquente insertion
(même si mon usage est plutôt restreint des std::list, les std::map
m'étant souvent plus utiles).
Avec des collègues, on a reparlé des std::deque. Il y a une dizaine
d'année, après des tests (*), j'en étais arrivé à la conclusion que ce
n'était pas vraiment rapide, en accès notamment, et qu'un std::vector
bien reservé (en cas de volume important) était bien plus efficace.
Aujourd'hui, je recherche de nouveau sur le sujet et je tombe (ou
retombe) sur http://www.gotw.ca/gotw/054.htm où il préfère l'utilisation
du std::deque et ce malgré son tableau de performance qui donne toujours
l'avantage au std::vector.
Du coup, j'ai un peu du mal à comprendre son raisonnement.
Avez-vous une idée sur la question(**)?
(*) Je referais des tests ce matin pour voir si les choses ont changé.
(**) La question pourrait s'étendre à l’intérêt nouvelle classe
std::array, utile ou juste pour rassurer des développeurs d'autres
horizons ? Est-ce que le std::vector est vraiment aussi lent que ça
et/ou "trop" gros pour avoir à utiliser une nouvelle classe pour
représenter un tableau (ou un espace de mémoire continue?)
David
Poser une question
Il me semble que l'intérêt de std::array est que chaque objet de cette
classe est nettement plus léger que std::vector, ce qui le rend plus
adéquat quand on a beaucoup de tableaux. Par exemple, si tu veux
représenter un point dans un espace 3D (i.e. des triplets de 'int' ou
de 'double'), std::array est plus adapté.
Ajoutons que la taille d'un std::array est connue à la compilation, ce
qui peut permettre au compilo d'optimiser.
Par exemple :
template <class Conteneur> int Sommme (Conteneur const& c)
{
int s= 0;
for (size_t i=0; i {
s+= c[i];
}
return s;
}
Si tu passes un vector à cette fonction, on aura bien une boucle.
En revanche, si tu lui passes un array<int,3>, le compilateur verra
quelque chose comme
int s= 0;
for (size_t i=0; i<3; ++i)
{
s+= c[i];
}
return s;
et pourra remplacer ça par :
return c[0] + c[1] + c[2];
Du moins, en théorie...
Mon conseil : choisis un conteneur par défaut, et utilise-le partout.
Dans la plupart des cas, ce choix n'aura pas d'influence mesurable sur
les performances.
Dans les rares cas où il a une influence, effectue des mesures, et
choisis le conteneur le plus adapté à ce cas précis.
Je suis aussi de cet avis. J'utilise couramment std::deque pour
le bon compromis souplesse/rapidité, mais dès que les perfs
sont demandées alors j'adapte: je stocke plutôt des pointeurs, si pas
suffisant je passe à std::vector (surtout si les insertions se font
plutôt à la fin).
Pourquoi « en théorie » ? Le compilateur Intel par exemple fait ce genre
d'optimisations (entre autres).
--
LL
Ok merci à vous.
A priori pas de raison de changer mes habitudes. Rester sur std::vector
(j'utilse aussi des pointeurs pour mon cas présent) et voir au cas par cas.