Version imprimable
Bonjour, j'essaye d'avancer des arguments pour mettre en valeur la STL à un ami développeur réticent (au boulot il doit utiliser VC6).
Evidemment si j'arrive à le convaincre, il ne l'utilisera pas sous VC6 mais plutôt dans ses projets persos sous 2005.
Il me demande si elle est optimisée. Que puis-je répondre ?
Optimisée par rapport à quoi ? Une std::map sera moins optimisée qu'un int quand il s'agit de la copier, mais elle ne fournit pas les mêmes services...
La STL est une spec, et différentes implémentations peuvent avoir un niveau d'optimisation différent.
Elle est optimisée dans le sens où :
- Elle n'ajoute pas de tests de validité (certaines implémentations en ajoutent, mais c'est désactivable)
- La complexité algorithmique de beaucoups d'algorithmes est spécifiée (par exemple, une classe comme vector redimentionnable écrite par un développeur pas très doué aura une complexité en O(n) pour ajouter un éléments, alors qu'un std::vector a une complexité en O(1) amorti).
- Elle de demande pas de downcast pour être utilisée (contrairement à des collections où tout dérive d'une classe de base "Object" comme on a pu en voir au début du C++)
- Elle utilise des techniques permettant un bon inlining facilement (voir par exemple st::sort qui explose généralement en bench qsort)
- Les implémentations sont écrites par des gens qui savent, qui ne sont pas mauvais, et qui on eu plein de temps pour optimiser
- Comme on passe moins de temps à faire des bugs, on gagne du temps sur la phase d'optimisation ;)
Maintenant, c'est une bibliothèque générique, et il y a des cas où, généralement parce que tu sais que tes données vérifient des contraintes supplémentaires, une collection spécifique peut s'avérer préférable. Même dans ce cas, il peut être intéressant de calquer l'interface de ces collections sur celles de la STL, afin de bénéficier du bras de levier des algorithmes, et de la maîtrise du sujet par les autres développeurs. Voir par exemple les collections proposées par boost (exemple : boost::array qui gère les collections où le nombre d'élément est connu à la compilation, ce qui évite une allocation dynamique inutile).
+1Citation:
Envoyé par JolyLoic
j'ajouterai :
- gestion de la mémoire
- limite les erreurs mémoire
- simplifie le dégugage
- lecture de code amélioré
- améliore la productivité
- vector aussi performant qu'un tableau C avec que des avantages
- string beaucoup plus simple que les char *
- portable
- template
Et si il ne trouve pas tous ce qu'il veut dans la S(T)L, il faut ajouter BOOST.
Ok merci à vous pour ces arguments.
En fait, il ne travaille pas avec des char* ou des tableaux C, mais plutôt avec un vieux framework maison développé dans les années 90 dont il ne parvient pas à se défaire.
à mon avis non :?Code:Mais je ne suis pas sur que se soit légale..
de quoi ???:roll::roll::roll::roll:Citation:
Envoyé par NiamorH
:P
Donc en terme d'optimisation, il faudrait comparer avec celles mises en place dans ce vieux framework.Citation:
Envoyé par NiamorH
S'il date des années 90, il y a peu de chance qu'il soit templatisé, et impose que tout dérive d'une classe Object. Rien que ça peut faire une différence non négligeable sur des conteneurs de petits objets.