Hors de l'embarqué temps réel, les raisons citées par Mac Lak restent en partie valables...

Pour la STL et Boost, sur des projets où pas mal de monde travaille (ou des projets où il y a un fort turnover), on essaye souvent de limiter le nombre des "prérequis" pour quelqu'un qui rentrerait dans le code. L'idée générale, c'est que le temps passé à apprendre telle ou telle librairie particulière, qui apportera un "petit plus" n'est pas passé sur le projet, et qu'une librairie rarement utilisée a toutes les chances d'être mal utilisée...

A côté de la STL, presque tous les projets utilisent une ou plusieurs librairies. Les composants des framework graphiques, de la VCL à Qt, contiennent leurs Strings, leurs Listes, leurs Vecteurs maison, parfois optimisés pour eux, ou plus facilement intégrables. Il faut leur ajouter diverses "boites à outil maison", qu'on garde parce qu'on les connait, et qu'on les a tellement utilisées qu'elles sont quasiment garanties sans bug...

La STL, ce sont des éléments en plus, des connaissances à acquérir, souvent un peu redondants, et ne fonctionnant pas exactement pareil, donc sujets à des bugs subtils.

Et puis, il y a des pans de la STL qui sont très peu utilisés (les deque, les valarray, les multimachins, presque tous les algos hors de la recherche...). Ajouter un de ces objets rares pour le plaisir d'être standard, c'est faire courir un risque au projet si le prochain mainteneur s'avère moins STL-savvy...

Boost, c'est pire. C'est encore plus gros, ca change souvent, et ce n'est pas spécialement facile à apprendre. Chaque développeur en connait un bout différent, donc la maintenance en équipe...

Au total, beaucoup de projets reposent sur un compromis (souvent tacite): on essaye de limiter la liste des outils qu'on utilise, ce qui permet de bien les connaitre, et de former rapidement les nouveaux. Ca veut dire des bouts de STL, des bouts de Boost, et une certaine résistance au changement (c'est un peu logique, un logiciel, ça devient rentable quand on commence à ne plus trop avoir à le développer, et quand la maintenance se stabilise, ce qui veut dire, pas trop de nouveautés)

Les templates, c'est autre chose. En général, les projets où ils sont interdits sont ceux où l'on s'est déjà pris un méchant bug de template. Quand ca va bien, les template, c'est super, mais quand ca commence à mal tourner, on peut se retrouver avec des choses vraiment très dures à débuguer. un bug classique, une fois reproduit, c'est rare qu'il dure longtemps, un bug de template, c'est le genre de chose qui fait dire "je ne sais pas" au client, et ça, ça fait drolement peur...


Quant aux contraintes de vitesse et de ressources, même si elles ne figurent pas dans le cahier des charges, elles restent importantes sur les appplications PC. Avec la crise, les parcs des utilisateurs se renouvellent peu, on voit pas mal de vieilles machines, et comme toutes les autres applis (bureautique, mails, gestion de projet, autres applis métier) sont assez gourmandes, la place restant pour l'appli qu'on développe est souvent assez contrainte. Généralement, partir du principe que le logiciel tournera sur une machine vétuste, avec un système dépassé, est une assez bonne stratégie (quand on écrit des programmes destinés à "l'extérieur").

Il n'y a pas longtemps, j'ai raté un gros client parce que je ne tournais plus sur Windows 2000... Tout ca pour deux appels systèmes pour "faire moderne", dans un module pas très central de l'appli... Ca calme par rapport aux technos de demain.

Francois