Depuis le temps que je lis ces forums, j'ai l'impression que les programmeurs C++ évitent la STL et les flux comme la peste.
*Parce qu'ils ne savent pas?
*Parce qu'ils codent en C mais aiment enregistrer leur travail dans des fichiers .cpp?
*Parce qu'ils n'aiment pas?
*Parce qu'ils aiment le challenge des bugs?
*Parce qu'ils aiment les fuites mémoire?
*Parce qu ça fait chier d'avoir du code propre?
*Parce que c'est trop facile?
*ou trop efficace?
 
Enfin, il y bien quelques cas où la STL ne sert pas, mais on les reconnait quand on les voit, et c'est pas tous les jours.
J'aimerais savoir ce que les codeurs C++ en pensent
et dire aux débutants :
 "ne prenez pas un bouquin de C pour apprendre le C pour ensuite passer au C++, ça laisse de mauvaises habitudes.
La STL c'est bien"
 
Si Bjarne était mort, il serait en train de mouliner dans sa tombe, et pas qu'à cause de Java.

*Parce que c'est chiant pour débugger (comme toutes les templates)

[edit]--Message édité par z51--[/edit]

Et puis les templates, c'est bien, mais en C++, ça devient vite le b****l total à gérer dès que tu veux écrire des applications portables (i.e. qui compilent et qui tournent sur des OS différents). Par expérience...
 
Parce que chaque compilateur a sa façon de gérer les templates qui lui est propre. Et puis tous les compilateurs ne supportent pas toujours la STL (trop templatisé).

Je dirais que bcp disent faire du c++ alors qu'ils font du C.
En principe avec les compilos récents, la STL ne posent aucun pb (d'ailleurs elle est sûrement fournie avec). Sinon, changer de compilo (g++ marchent bien avec avec la STL).
 
Et sauf de rares cas, il y a tout intérêt à l'utiliser.

moi je code en c et en c++, mais c'est quoi la STL ?

 
Standard Template Library si je ne m'abuse

j'oubliais : c'est un amas de classes génériques qui gèrent pas mal de situation courante en programmation : vecteurs, liste chînées, ... l'idée étant de se servir de code bien écrit (:D) au lieu de réinventer la roue en boucle infini.

 
Y'a toujours qques pb avec VC++ il me semble, non?
A+,

Y a des patchs (payants) pour VC++ chez dinkumware qui améliorent pas mal les choses.

Ben bien sur, si professionellement je devais utiliser la STL en C++ avec VC++, c'est sur que j'utiliserais les libs de Plauger.
Mais je ne me placais pas dans ce contexte la, etant donne le post initial.
A+,

tout a fait d'accord avec verdoux, rien qu'en lisant les posts de ce forum, on se rend vite compte que beaucoup codent en C en croyant coder en C++ ...
y'a pas mal de raisons a ca, tout d'abord le C est plus accessible et direct. Il faut plus de rigueur et de travail pour faire du code objet propre que pour aligner des lignes de C en croyant reinventer l'algorithmie a chaque fois.
ensuite la STL reste peu connue a cause des fameuses MFCs de msieur billou qui elles, par contre, sont beaucoup moins portables (meme pas du tout)!

 
 
En fait la STL est vraiment difficile a utiliser sans mode d'emploi, et elle n'est pas vraiment portable si on n'a pas de compilo recent. Je me suis trouve pris au piege. Nouvelle fonctionnalite developpee avec la STL a retro-ajouter aux version precedentes dont une est compilee avec une ancienne version de compilo incompatible avec la STL, et utilisant des lib qui ont ete remplacees par la STL et sont incompatibles avec le compilo actuel...
 
Travailler en C++ n'oblige pas a utiliser les templates (interdits par certains referentiels de prog) et n'oblige pas a utiliser la STL...
 
A titre de confirmation allez faire un tour sur wxWindow...
Et vous verrez que les MFC sont peut-etre plus protable que vous ne le pensez !

Je vois pas trop le rapport entre MFC et STL.

Comme Verdoux : le rapport ?
MFC c'est clairement un wrapper C++ pour l'API win32, ce qui n'est pas du tout le cas pour la STL.

 
Les MFC fournissent aussi des types tels que les Carrays et les Cstrings qui doivent incontestablement faire de l'ombre au vector et strings de la STL.

Les conteneurs des MFC sont quand même très basiques. Y a même pas d'itérateurs.

Les iterateurs c'est comme les pointeurs il faut y avoir gouter pour aimer (et il y en a qui n'aiment toujours pas tout en y ayant goute).
 
La STL est relativement recente, et certains utilisent les MFC et ne connaissent pas la STL.

Mais, heuu......
Arretez de m'embeter.
C'est pas ma faute si j'ai étudié dans l'ordre C, java.
Et que j'essaie betement de mixer les 2 sans bouquin de C++.
C'est quand même cool la POO.
Bon j'vous ait pas trop embeté ces derniers temps ça doit pas être moi qu'on accuse.

[edit]--Message édité par Roswell_--[/edit]

Roswell_ a écrit a écrit : Mais, heuu...... Arretez de m'embeter. C'est pas ma faute si j'ai étudié dans l'ordre C, java. Et que j'essaie betement de mixer les 2 sans bouquin de C++. C'est quand même cool la POO. Bon j'vous ait pas trop embeté ces derniers temps ça doit pas être moi qu'on accuse.

 
Si tu cherches un bon bouquin il y a le Bjarne Stroustrup (approx.) edition special (env 250 FF) qui est bien et qui explique bien comment utiliser la fameuse STL...
 
Elle ne devrait d'ailleur pas te poser trop de Pb puisque on en retrouve des idees dans Java...
 
Mais je maintiens que l'on peut faire du C++ sans utiliser la STL ni les flux.
 
Et je pense que pour les gens qui connaissent un langage tel que le FORTRAN il vaut mieux passer par le C pour arriver au C++.
J'ai souvent du demonter les mecanismes objets du C++ pour expliquer comment les reconstruire en C pour que les debutants comprennent la notion d'objet et d'heritage (c'est presque une philosophie) que je pense que faire les chose en deux temps n'est pas si mal : la syntaxe, les pointeurs et les structures (le C quoi), puis les objects, les surcharges...
 
Pour quelqu'un qui ne connait pas de langage procedural tel que le FORTRAN on peut peut-etre passer directement au C++...

qu'on puisse faire du C++ sans STL je suis d'accord, mais mon experience perso me prouve qu'il arrive souvent un moment ou il faut manipuler des chaines, listes, et plein d'autres structures de donnees basiques. Et aussi faire des tris, des recherches ... etc, tout ce que la STL sait tres bien faire ! Alors pourquoi passer des heures de programmation pour refaire quelque chose qui sera probablement plus bugge est moins performant ?
sinon pour le parallele avec les MFCs, c'est tout simplement que, en plus de "wrapper" l'API win32, elles fournissent des outils et des types de bases (les fameuses CString...).
Par contre je veux bien admettre que les STL ne sont pas finalisees dans l'ensemble. Mais un simple GCC supporte les STL et cela sans aucun probleme (enfin d'apres mon experience).

hello,
 
un ptit commentaire à propos de la STL.
Ca fait quelques temps deja que je fais de l'objet, et pas si longtemps que cela que j'ai commencé à utiliser la STL.
C'est vrai, la STL c'est TERRIBLE.
 
Mais tres franchement, il manque une chose:
un VRAI bon document qui explique les choses simplement.
J'ai pas encore trouvé un seul vrai document qui explique bien comment ca s'utilise.
L'autre jour, un stagiaire veut lire des fichiers, etc... ok, alors il va pour utiliser des objets fstream de la STL.
1/2 journee de recherches sur le web, et abandon parce que ya pas 1 personne qui a été capable d'expliquer clairement sur un papiercomment ca fonctionne, sans avoir a cliquer sur 25 liens pour comprendre et pour avoir un appercu des fonctions qu'il pouvait utiliser sur cet objet.
 
Donc quand il n'y a pas de bonne doc, l'adoption est plus difficile...

fstream c de la STL ??????
j'utilise la stl sans le savoir
 
euh mon borland tout vieux fait pour win95 et 3.1 il comprend les fstream les itérateurs et tout, ca doit pas être si incertain que ça de nos jours....

ben la doc elle est la : http://www.sgi.com/tech/stl/

mais fstream ne fait pas partie de la STL il me semble ...

C'est une doc sur UNE STL... pas sur LA STL
 
Je ne crois pas que les Hash_map soient standard...
Beaucoup de docs sont commes celle-ci (Rogue Wave par ex)
mais je ne trouve pas ca tres pratique (des gouts et des couleurs ...)
 
Par contre le Stroustrup est pas trop mal, mais ce n'est pas un ouvrage de reference comme le K&R. (je veux dire qu'il n'est pas aussi facile d'y trouver une information)...

Y'a un bouquin de reference:
[url=http://www1.fatbrain.com/asp/bookinfo/bookinfo.asp?theisbn=0134376331&vm=]The C++ Standard Template Library  
By Plauger, P. J. / Stepanov, Alexander A. / Lee, Meng / Musser, David R[/url]

A+,

BENB> ben c'est peut etre une doc sur "une" implementation STL mais au moins c'est une doc de STL oui ou non ?
bon ...
personne ne programme avec un compilateur standard, un jour ou l'autre il faut bien utiliser une STL specifique et je vois pas ou est le probleme la dedans. Un standard c'est bien beau a regarder devans la cheminee le soir quand il fait froid mais pour coder c'est beaucoup moins pratique !
Qui ici a appris le C/C++ avec le standard sous les yeux ?  
personne ...
Qui meme le possede a la maison ?
personne ...

 
Je crois que c'est justement tout le probleme, et c'est pour cela que tu ne comprend absolument pas mon point de vue. Le standard est un minimum commun. Utiliser des fonctionnalites qui sortent de ce minimum c'est prendre des risques et diminuer la portabilite. Quand a prendre la doc de la STL SGI pour l'utiliser avec une autre implementation ca confine au cretinisme (je suis desole d'appeler un chat un chat).
 
La doc SGI (dont l'adresse est donnee plus haut) s'applique a la STL SGI (gratuite il me semble) et pas a une autre.
 
Part contre une doc STL "standard" s'applique a toute STL (SGI, RW, MS) digne de ce nom.
 
Personne n'utilise de compilo standard, mais beaucoup d'entre nous n'utilisent dans le language qu'un sous ensemble du standard. C'est ce qui s'appelle le referentiel de programmation.
Le but est de produire un code propre et capable de compiler sur la plupart des compilo (et certains sont exotiques, crois moi).
 
Il est bien dommage que tout le monde n'ai pas appris le "standard", il serait bien plus facile de porter les codes...

Il suffit de lire la FAQ de la STL SGI.

 
La doc SGI est pas mal pour celui qui veut un aperçu sans acheter un bouquin.
 
Et si ton référentiel de programmation t'oblige à laisser tomber les exceptions, les namespaces, les RTTI, les templates, la STL, les flux, il reste plus grand chose du C++.

[edit]--Message édité par Verdoux--[/edit]

Revenont au post initial :
certains programmeurs C++ evitent la STL et les Flux...
certains programmeurs C++ ne font que du C...
 
1 - Quels sont les differences entre C et C++.
Le meilleur controle des types en C++.
Le support objet en C++
les possibilites de surcharges fct/operateurs en C++
la bibliotheque + riche... en C++
Par contre le standard C++ est plus jeune et certains compilo (en particulier ceux qui ont 5 ans) n'en supportent qu'un partie.
La Il y a encore peu d'ouvrages de vulgarisation, et ceux qui on "oublie de photocopier la doc en piratant le compilo" ne connaissent pas forcement la STL
 
Conclusion:
Si je sais que mon appli doit tourner sur plusieurs platformes on si je travaille sur un projet qui ne vient pas de demarrer il faut considerer les problemes de portabilite et la STL peut devenir inutilisable.
 
Savoir programmer ce n'est pas connaitre toute les finnesses d'un language c'est en connaitre la partie la plus fiable et resoudre les bp avec.
 
A titre d'indication, les societes qui cherche une haute qualite logiciel utilisent des referenciels de programmation qui reglementent les sources, et en C/C++ il est courement interdit d'utiliser l'operateur ternaire (il a ete peu fiable et est d'une lecture difficile) et les templates. Et ce a tel point qu'il y a des moulinettes qui cherchent ces elements et interdisent la compil si il en apparait dans le code. Utiliser la STL dans ces conditions est totalement impossible.
 
Enfin l'ancien compilo des stations HP ne peut pas compiler la STL.
 
Ne beneficier que du controle de type c'est deja faire du C++.

Justement les templates renforcent le contrôle de type.

Chez Thomson CSF sont interdits me semble-t-il
Exceptions, RTTI et templates (donc STL)
 
Chez HP
ce sont les exceptions et les templates sauf STL, et les namespaces y compris STL
 
On utilise une STL sans namespace std...
 
sachant que toutes les versions de compilo utilisee ne gere pas la STL de la meme facon :
la derniere bien
la precedente pas de membres templates ni de templates par default... (donc pas de STL)...

 
tout comme les nouveaux casts (reinterpret_cast, static_cast, const_cast, et dynamic_cast)
 
PS : ce n'est pas moi qui ecrit les referentiels, je me contente de les appliquer. Souvent il interdisent des fonctionnalites qui ont ete buggee au debut... (templates)

BENB> Pour ma part j'utilise la doc SGI pour coder avec la libstdc++ v3 pour GCC et meme si certaines implementations peuvent varier ca donne les idees de base et ca permet d'avancer.
Faut quand meme pas cracher dans la soupe, cette doc est assez bien faite et pratique a consulter.
Pour ce qui est de la question des standards, tout le monde sait bien que meme s'ils sont necessaires, les suivre betement (ca c'est pour le "cretinisme" ) nous prive de beaucoup de fonctionnalites interessantes. Si tous les programmeurs s'etaient arretes au standard du C, le C++ n'exiterait pas.

 
Perso je prefere les docs papiers, ca me permet de recouvrir mon bureau d'une epaisseur de 10 a 15 cm de papier
 
et la STL Rogue Wave que j'utilise a le meme type de presentation que la doc SGI (et j'aime pas, mais des gouts et des couleurs...).
 
Mais je ne critique pas la doc elle meme, mais plutot le fait de la conseiller comme une doc de reference sur la STL en general.
 
La betise n'est pas de suiver ou pas le standard, mais de savoir ce qui est standard et ce qui ne l'est pas afin de pouvoir encapsuler ce qui ne l'est pas pour le jour ou on changera de compilo.
 
Et je critique aussi la tendence mode qui consiste a dire que ne programme en C++ que celui qui utilise template, RTTI, STL, dans chacun des ses fichiers...
 
Un industriel developpe des produits, mais il les fait vivre aussi, et il est normal qu'il cherche a normaliser le code et eviter la production de code (efficace sans doute) mais incomprehensible pour beaucoup. C'est cela qui le differencie de beaucoup de petits developpeurs et de certains universitaires qui cherchent a utiliser toutes les subtilites.
 
Ma parole n'a sans doute pas beaucoup de poids, mais lisez (j'insiste) " le Language C++ " special edition par Bjarne. Et vous verrez que ses propos ne sont pas si eloingnes des miens.
 
Il conseille l'utilisation d'un compilo high end pour l'apprentissage bien sur, mais l'utilisation d'un plus ancien pour une production plus professionnelle.
Il conseille d'eviter de s'en tenir a une implementation mais au contraire au standard.
etc.
 
Enfin tu dis utiliser la doc SGI pour faire une STL concurente, pourquoi-pas ? il serait intelligent, a mon avis, d'utiliser la meme interface qu'une STL existante pour les ajouts qui ne sont pas dans le standard.  
 
Ce qui est cretin (j'assume jusqu'au bout) c'est de presenter cette doc comme etant LA doc de LA stl, car ce n'est pas le cas et pour quelqu'un qui utilise une autre implementation de la STL c'est meme mechant. Imagine le temps perdu si'il doit revenir dans plusieurs fichiers pour enveler toutes les references a quelque chose qui n'existe pas dans son implementation.
 
Je pense au contraire que c'est en utilisant les extentions avec prudence que l'on fait avancer les choses.
 
Je suis desoler d'eventuellement te vexer, mais les forums sont aussi faits pour les echanges d'idees et de points de vue, meme si cela frise et defrise.
 
Pour conclure je dirais, bien que je ne l'ai pas lu, que la doc de reference est sans doute le livre presente par Gilou.
Le Bjarne est pas si mal, bien que pas centre sur la STL.
 
PS: pour en finir avec le cretinisme et les betises, ce n'est pas pour moi une insulte tel que "cretin" mais plutot une facon de dire ce que fais la est cretin, et qui ne fait jamais de betises...   ...sans pour autant etre bete.

>Pour conclure je dirais, bien que je ne l'ai pas lu, que la doc de reference est sans doute le livre presente par Gilou.  
 
 
Ben j'ai decouvert que ce bouquin existait hier, je l'ai pas lu, mais ca ne saurait tarder.
Stepanov est un des concepteurs de la STL, et Plauger est au comite de standardisation du C++ (et du C il me semble), a ecrit pas mal d'articles dans la C/C++ Users Journal, et a ecrit des bouquins de reference, entre autre The C++ Standard Library, que j'ai toujous a portee de la main (En fait, c'est The Draft C++ Standard Library, car le standard avait pas encore ete approuve quand le bouquin est sorti, mais j'ai jamais eu de pb avec la norme decrite dans ce bouquin).
A+,

Mon poste initial était une incitation à coder avec intelligence pour éviter les merdes, une incitation aux personnes qui ne connaissent pas d'y goûter VITE.
La STL c'est cool pour aller vite.
Et il FAUT savoir que ça existe, ET que c'est standard (depuis 98 je pense).
Il faut choisir de ne pas l'utiliser si l'on doit ne pas l'utiliser.
C'est un peu savoir qu'il existe du poulain grand arôme (où même du 1848 mmmmm) quand on mange du nesquick (j'y ai passé 14 ans de ma vie qd même), ou savoir qu'acheter des pâtes genre barilla c'est vraiment meilleur que les pâtes top pas chères, même si les lider praillse c'est - cher.