comme tu vois, il y a les pour et les contre !
moi je suis partisant du pour

" C´est lourd, trop généraliste ( pas optimisé pour ton cas à TOI...) et gonflé de code à coucher dehors, savez qu´à regarder les " header-source(?)" des différents composants de la STL pour voir..."

Certainement le problème majeur de la STL qui est très ( parfois trop ) généraliste et lourde dans ses données inutile. Si on a besoin que d´une classe simplifié ou d´une classe à l´usage très précis et particulier, il vaut mieux créer la sienne.

" Consommation abusive du POO, surutilisation des templates ( à mon avis), enfin bref, ça fait pas dans la dentelle..."

Certes un petit peut, mais bon cela s´explique un peu historiquement
Quand à la philosophie des templates, je suis loin d´être contre.

Alors certes il n´y a pas que des avantages à l´utiliser loin de la, cependant elle évite à avoir à tout reprogrammer soit même ce qui peut comme je l´ai déjà évoqué mener à l´abandon du projet par découragement.
De plus par son caractère ultra orienté objet, elle forme un bon moyen d´apprendre les mécanismes clés de ce type de programmation en vue de les réutiliser soit même ( template, héritage, . .. )

Je ne suis personnelemnt ni pour ni contre, mais dans un contexte ou le gain d´espace mémoire et parfois la performance n´est pas cruciale, on peut y avoir recours sans problèmes.

en regardant le code du fichier stdlib.h, je m´apercois qu´a part quelques macro et constante, aucune fonction n´y est définie.

C´est normal, sinon, on ne pourrait pas inclure le fichier dans plusieurs fichier source.

Les fonctions elle même sont stocké dans des DLL.

Masi ce que je ne comprend pas ( et c´est une question récurrente) c´est comment se passe l´appel à la DLL :

_CRTIMP wchar_t * __cdecl _itow ( int, wchar_t *, int);
par exemple avec :

1. define _CRTIMP __declspec(dllimport)

c´est bien beau, mais en supposant que que le nom de la fonction exporté par la DLL soit le même que celui du fichier . h, ça ne nous dit pas où est la DLL et encore moins comment est ce qu´elle s´appelle.

Si quelqu´un a une idée sur comment est ce que ça marche, je serais très content.

merci d´avance pour toute les réponses.

Dans une DLL ?
C´est pas dans une lib plutôt ?
Dont tu fais le lien avec les external dependencies dans les options du linker ?

c´est^peut-être vrai, j´ai cru que c´était une DLL à cause du dllimport, masi ça ne résoud pas vraiment mon problème. Parce que comment sait-il quelle lib utiliser ( ou alors elle doit avoir le même nom que le header) vu que le fait d´inclure un fichier . c ne modifie pas les options du linker justement.

quoi que, il y a tout une batterie de . lib déjà défini ( user32.lib, advapi32.lib, etc.) les fonctions sont-elle défini à l´intérieur de celle là ?
Mais alors, le linker " pioche" dans le . lib les fonctions nécessaire au programme ou il mets tout en bloc ?

Une librairie est composée d´un ensemble de fichiers objets ( des . c/.cpp compilé donc ) .

Perso, je suis un grand utilisateur des std::vector, std::list, string, iostream & co
C´est efficace, rapide ( enfin, relativement bien sur et ca fait gagner un temps fou. J´ai bien entendu, reecit des classes de string, de listes chainées doubles, de buffers circulaires et autre, mais malgres tout, la préference va a la stl.
A titre de comparaison, j´ai tester les equivalents MFC, CPtrArray, CStringArray, CString, CFile [...] et franchement, je regrete que le framwork MFC/VC++6 n´entegre pas mieux la stl.

En tout cas, pour les gros projets, pour moi y a pas photo, c´est stl. Le code est fiable, purement OO ( contrerement au MFC) et efficace.
Bref, vous l´aurez compris, je ne vois pas de gros desvantages a utiliser la stl.