Discussion :

[Luc Hermitte]

a- C'est exactement ça.
Quand on pense à JAVA on pense à l'API Java et tout ce qu'elle propose.
C++ avec STL mais pour tout ce qui est plus haut niveau c'est ce qu'on souhaite.

b- L’inconvénient c'est que les enseignants que j'ai eu s'arrêtent au package de base : Langage C++ + STL et c'est tout. Du coup, en sortant du cours, on se dit que le C++ pour faire quelque chose de haut niveau ça semble bien plus compliqué qu'en Java ou C# surtout que parfois l'installation de bibliothèque et le link n'est pas trivial.

a- On pense aussi à SWT / eclipse RCP, et à apache -- et à une pléthore de cots trouvables grâce à google.

b- Et encore, c'est quand ils daignent exposer les étudiants au sous-ensemble STL+string de la SL. (la critique première relative à l'enseignement)

[seeme]

C'est exactement ça.
Quand on pense à JAVA on pense à l'API Java et tout ce qu'elle propose.
C# rime avec .Net
C++ avec STL mais pour tout ce qui est plus haut niveau c'est ce qu'on souhaite.

L’inconvénient c'est que les enseignants que j'ai eu s'arrêtent au package de base : Langage C++ + STL et c'est tout. Du coup, en sortant du cours, on se dit que le C++ pour faire quelque chose de haut niveau ça semble bien plus compliqué qu'en Java ou C# surtout que parfois l'installation de bibliothèque et le link ne sont pas trivial.

Je ne suis pas trop d'accord. Pour moi, que ces packages haut niveau ne soient pas intégrés est une force du langage. C'est à toi de regarder ce qui existe, de tester, de te renseigner et de choisir ce qui correspond au mieux à ton besoin.

Il n'y a pas beaucoup d’intérêt à apprendre à se servir de Qt si au final ta cible ne permet pas de le faire tourner. Par contre connaitre les principes MVC et autre permettront d'évaluer correctement les autres libs.

Le choix me parait moins évident avec par exemple Java (mais je ne connais pas trop son utilisation du point de vue pro, à vous de me dire si je me trompe). Je pense que beaucoup de gens vont juste partir avec ce qui est fourni de base sans se demander s'il n'existe pas des lib qui répondraient mieux à leur besoin.

Tout dépend du degré d'intégration/somme de travail/réponse précise au problème que tu cherches.

[Kaamui]

Je ne suis pas trop d'accord. Pour moi, que ces packages haut niveau ne soient pas intégrés est une force du langage. C'est à toi de regarder ce qui existe, de tester, de te renseigner et de choisir ce qui correspond au mieux à ton besoin.

Il n'y a pas beaucoup d’intérêt à apprendre à se servir de Qt si au final ta cible ne permet pas de le faire tourner. Par contre connaitre les principes MVC et autre permettront d'évaluer correctement les autres libs.

Le choix me parait moins évident avec par exemple Java (mais je ne connais pas trop son utilisation du point de vue pro, à vous de me dire si je me trompe). Je pense que beaucoup de gens vont juste partir avec ce qui est fourni de base sans se demander s'il n'existe pas des lib qui répondraient mieux à leur besoin.

Tout dépend du degré d'intégration/somme de travail/réponse précise au problème que tu cherches.

Je suis assez d'accord avec lui. Un langage en lui-même qui ne propose pas de framework intégrée dans son contenu standard n'est pas une tare. Au contraire, c'est ce qui me plait dans le C++, contrairement aux autres langages très haut niveau et très répandues de nos jours dans le monde pro, qu'il ne soit qu'un base. Rien n'empêche après d'avoir des bibliothèques externes comme la SFML pour les JV 2D qui fait plus que bien son boulot. Je trouverais ça bizarre qu'elle soit intégrée au contenu standard.

[Drannor]

Je ne suis pas trop d'accord. Pour moi, que ces packages haut niveau ne soient pas intégrés est une force du langage. C'est à toi de regarder ce qui existe, de tester, de te renseigner et de choisir ce qui correspond au mieux à ton besoin.

Il n'y a pas beaucoup d’intérêt à apprendre à se servir de Qt si au final ta cible ne permet pas de le faire tourner.

La grande force du C++ c'est de convenir aussi bien à de la programmation embarqué que d'application haut niveau.

Mais aujourd'hui force est de constaté que pour tout ce qui est haut niveau, les entreprises préfèrent souvent faire du Java et du C# car le C++ est plus complexe et n'a pas de réel suivi sur les bibliothèque qu'on va utiliser pour éviter le syndrome DIY.

Pour revenir aux débutants, ils ont généralement un background de programmation orienté objet avec du Java dans leur cursus et ils aiment retrouvé dans un nouveau langage leurs marques avec une API et une doc facile à exploiter. Un langage qui leur permet d'avoir rapidement le résultat escompter sans passer deux ou trois jours à savoir pourquoi il faut choisir BOOST plutôt que POCO. Sans oublier le temps passer à l'installation, à réussir à compiler avec l'inclusion des librairies son premier programme etc ...
C'est loin d'être user friendly.

En reprenant ton exemple, SFML est une très bonne librairie C++ mais généralement les gens utilisent SDL car elle est historiquement plus connue et qu'on trouve plus de référence dessus alors qu'elle est plus proche du C.
Un framework officiel pourrait éviter d'utiliser des librairies dont la conception relève plus du C avec de l'objet que du C++.

[Bousk]

Ayant un bon niveau en C, connaissant le principe des classes, je pensais pouvoir écrire C/C++ sur mon CV, en tout bonne fois. Mais depuis quelques mois, je lis de temps en temps des sujets C++ sur Developpez.com et je ne comprends rien ! Mais rien de rien ! J'ai découvert il y a peu la STL et les vectors en faisant un code en Qt à la maison. Mais pourquoi on ne m'avait jamais parlé de ces vectors et de la STL ?? POURQUOI ???

J'ai eu la surprise il y a quelques mois de faire passer un entretien à un jeune diplomé qui postulait pour intégrer notre équipe en tant que développeur junior (comme moi), et de m'apercevoir que... il ne connaissait pas les std::vector, il ne connaissait rien de la std, il ignorait le terme de namespace (et tout un tas d'autres trucs supplémentaires dont il ignorait jusqu'à l'existence).
Puis je me suis rappelé de mes cours, ou plutôt de l'absence de mes cours puisque j'ai tout appris en autodidacte ((mal)heureusement ?).
Apparement ce jeune n'est pas un cas isolé.

[seeme]

J'ai eu la surprise il y a quelques mois de faire passer un entretien à un jeune diplomé qui postulait pour intégrer notre équipe en tant que développeur junior (comme moi), et de m'apercevoir que... il ne connaissait pas les std::vector, il ne connaissait rien de la std, il ignorait le terme de namespace (et tout un tas d'autres trucs supplémentaires dont il ignorait jusqu'à l'existence).
Puis je me suis rappelé de mes cours, ou plutôt de l'absence de mes cours puisque j'ai tout appris en autodidacte ((mal)heureusement ?).
Apparement ce jeune n'est pas un cas isolé.

Pour moi ça montre qu'il n'a pas beaucoup lu/appris de son côté. On ne peut pas attendre de l'école qu'elle nous tienne la main. Si je veux devenir dev junior C++, j'ai lu un minimum sur le sujet, je me suis renseigné. Ca me parait difficile de développer quoi que ce soit d'un peu évolué sans à un moment tomber sur un forum/tuto/article qui n'utilise pas des vector (et donc des namespaces, au moins std:: )

[pyros]

Personnellement, cela ne me choque pas plus que ça que la STL ne soit pas enseignée (j'ai d'ailleurs découvert la STL une fois diplômé seulement). Si on enseigne la STL, pourquoi ne pas enseigner QT, BOOST ou n'importe quelle autre framework ? Bien qu'elle fasse partie des spec du langage, elle s'utilise comme n'importe quelle autre lib.

Un étudiant sachant utiliser une librairie quelconque saura utiliser la STL, et surtout il saura s'en passer si elle n'est pas disponible. Il comprendra aussi pourquoi le std::vector n'est pas un conteneur magique et pourquoi ses perf s'effondre quand il le remplis à coup de push_back.

Un étudiant ayant été formé a utiliser la STL dès le début ne saura plus quoi faire s'il n'a pas son précieux std::vector sous la main. Il faut arrêter de penser que la STL est un acquis absolue toujours disponible en toute circonstance.

Après, il faut aussi faire la différence entre ceux qui se contentent de ce qu'ils connaissent et continue à faire des new int[...] à outrance, et ceux qui comprennent tout l'intérêt d'utiliser des choses nouvelle plus haut niveaux.

[Kaamui]

Personnellement, cela ne me choque pas plus que ça que la STL ne soit pas enseignée (j'ai d'ailleurs découvert la STL une fois diplômé seulement). Si on enseigne la STL, pourquoi ne pas enseigner QT, BOOST ou n'importe quelle autre framework ? Bien qu'elle fasse partie des spec du langage, elle s'utilise comme n'importe quelle autre lib.

Un étudiant sachant utiliser une librairie quelconque saura utiliser la STL, et surtout il saura s'en passer si elle n'est pas disponible. Il comprendra aussi pourquoi le std::vector n'est pas un conteneur magique et pourquoi ses perf s'effondre quand il le remplis à coup de push_back.

Un étudiant ayant été formé a utiliser la STL dès le début ne saura plus quoi faire s'il n'a pas son précieux std::vector sous la main. Il faut arrêter de penser que la STL est un acquis absolue toujours disponible en toute circonstance.

Après, il faut aussi faire la différence entre ceux qui se contentent de ce qu'ils connaissent et continue à faire des new int[...] à outrance, et ceux qui comprennent tout l'intérêt d'utiliser des choses nouvelle plus haut niveaux.

je comprend ton point de vue, mais quand même, la STL est plus qu'une librairie (c'est une façon de parler), elle utilise des concepts qui sont loin de ce qu'on peut faire dans une utilisation basique de ce langage. Et quand on veut faire du code très propre et robuste, on ne peut plus l'ignorer. Je trouve ça bien dommage que quelqu'un qui fait des études où il croit apprendre le C++, découvre ensuite une vaste étendue de connaissances et d'outils/concepts qui sont à des années lumière de ce qu'il avait pu apprendre.

[gbdivers]

Personnellement, cela ne me choque pas plus que ça que la STL ne soit pas enseignée (j'ai d'ailleurs découvert la STL une fois diplômé seulement). Si on enseigne la STL, pourquoi ne pas enseigner QT, BOOST ou n'importe quelle autre framework ? Bien qu'elle fasse partie des spec du langage, elle s'utilise comme n'importe quelle autre lib.

Un étudiant sachant utiliser une librairie quelconque saura utiliser la STL, et surtout il saura s'en passer si elle n'est pas disponible. Il comprendra aussi pourquoi le std::vector n'est pas un conteneur magique et pourquoi ses perf s'effondre quand il le remplis à coup de push_back.

Un étudiant ayant été formé a utiliser la STL dès le début ne saura plus quoi faire s'il n'a pas son précieux std::vector sous la main. Il faut arrêter de penser que la STL est un acquis absolue toujours disponible en toute circonstance.

Après, il faut aussi faire la différence entre ceux qui se contentent de ce qu'ils connaissent et continue à faire des new int[...] à outrance, et ceux qui comprennent tout l'intérêt d'utiliser des choses nouvelle plus haut niveaux.

Ca me semble un peu contradictoire ce que tu dis. Tu déconseilles l'apprentissage de la STL à un étudiant, mais il devra quand même connaître les limites de son utilisation. L'apprentissage du second point nécessite d'avoir vu le premier point avant, non ?

Le problème n'est pas plutôt la manière dont on enseigne l'utilisation de la STL ("une solution qui fait tout et pas juste un outil") que la bibliothèque en elle même ?

Crois tu qu'il faille enseigner que le langage C++ "pur" ou au contraire l'utilisation des bibliothèques doit faire partie de la formation au C++ ? (avec la nécessité de faire un choix sur les bibliothèques que l'on étudiera dans ce cours)

[seeme]

je comprend ton point de vue, mais quand même, la STL est plus qu'une librairie (c'est une façon de parler), elle utilise des concepts qui sont loin de ce qu'on peut faire dans une utilisation basique de ce langage. Et quand on veut faire du code très propre et robuste, on ne peut plus l'ignorer. Je trouve ça bien dommage que quelqu'un qui fait des études où il croit apprendre le C++, découvre ensuite une vaste étendue de connaissances et d'outils/concepts qui sont à des années lumière de ce qu'il avait pu apprendre.

Pour ma part, je persiste à croire qu'il vaut mieux connaitre la différence entre un vector et une list que de savoir s'en servir avec la STL.

La STL n'est pas disponible partout, n'est parfois pas un choix pertinent, et je vois énormément de gens qui utilisent des vector "parce qu'ils savent s'en servir" mais qui ne savent absolument pas comment ça marche et pourquoi une list ou une hashmap serait bien plus efficace.

Un autre exemple: sur console (et l'embarqué en général), tu as rarement la STL et si tu l'as, en général c'est plus intéressent de recoder ce qu'il te faut que de l'utiliser.

[Bktero]

Apparement ce jeune n'est pas un cas isolé.

Ca me fait plaisir de ne pas être tout seul (encore que je connaisse le principe des namespaces ). Il faut dire aussi qu'on m'a toujours fait mettre using namespace std;, ça n'aide pas à savoir que outest en fait std::out.

cela ne me choque pas plus que ça que la STL ne soit pas enseignée

Moi ça me choque un peu. Aujourd'hui, ça m'apparait comme l'un des gros avantages du C++ par rapport au C.

Il faut arrêter de penser que la STL est un acquis absolue toujours disponible en toute circonstance.

Si ton compilateur respecte la norme, elle est forcément disponible, non ?

[Kaamui]

Pour ma part, je persiste à croire qu'il vaut mieux connaitre la différence entre un vector et une list que de savoir s'en servir avec la STL.

La STL n'est pas disponible partout, n'est parfois pas un choix pertinent, et je vois énormément de gens qui utilisent des vector "parce qu'ils savent s'en servir" mais qui ne savent absolument pas comment ça marche et pourquoi une list ou une hashmap serait bien plus efficace.

Un autre exemple: sur console (et l'embarqué en général), tu as rarement la STL et si tu l'as, en général c'est plus intéressent de recoder ce qu'il te faut que de l'utiliser.

Et je me reconnait parfaitement (malheureusement) dans ce que tu dis. J'ai un projet en cours ou j'utilise des vector "en remplacement" de tableau, sans réfléchir, alors que ta simple remarque et un tour sur google me montrent que je ferais mieux d'utiliser des listes doublement chainées, car je peux très bien me retrouver à vouloir ajouter un élément en plein milieu de ma liste (liste d'états d'un automate). Mais je persiste (et signe ), si ce n'est pas la STL elle-même ce sont les principes généraux qui sont à la pointe de ce qu'on peut faire en C++ et qu'elle manipule qu'il faudrait rendre accessible très tot au "commun des mortels"

[Flob90]

@Bktero: En théorie si le compilateur respecte la norme il doit fournir une implémentation de la bibliothèque standard. Mais en pratique, si la plateforme est un peu "exotique" (embarqué par exemple), il se peut que juste le langage soit pris en compte et pas la bibliothèque standard. Ca dépend de ce que les constructeurs ont founis et ce que la communauté a développé.

@Kaamui: Choisir son conteneur par rapport aux complexités théorique n'est bon qu'en première approximation, sutout concernant std::vector. Il faut bencher pour en avoir le coeur net.

[pyros]

Ca me semble un peu contradictoire ce que tu dis. Tu déconseilles l'apprentissage de la STL à un étudiant, mais il devra quand même connaître les limites de son utilisation. L'apprentissage du second point nécessite d'avoir vu le premier point avant, non ?

Je pensais plus au fait qu'un étudiant ayant apris dès le début à utiliser un std::vector se contera des faire des push_back sans trop réfléchir (allez-pas me faire croire que l'étudiant vas allez lire la doc pour voir ce que ça implique).

Un étudiant ayant appris à faire des new et gérer sa mémoire à la main est plus sensibilisé au fait qu'on ne fait pas ce qu'on veut avec la mémoire et se posera peut être plus de question sur ce qu'il se passe en interne.

Crois tu qu'il faille enseigner que le langage C++ "pur" ou au contraire l'utilisation des bibliothèques doit faire partie de la formation au C++ ? (avec la nécessité de faire un choix sur les bibliothèques que l'on étudiera dans ce cours)

Je pense qu'il vaut mieux enseigner le C++ pur et dire qu'il existe des lib plus haut niveaux (en parlant de la STL bien sûr) disponible la plupart du temps. Cela rend les étudiants peut être moins opérationnel dès le début, mais plus polyvalent et plus "malléables" au sens où comme ils n'ont pas encore leurs petites habitudes et leur lib préférées qu'ils ont appris à l'école, ils adoptent plus facilement les conventions utilisées dans leur boulot. Une lib s'apprend sur le tas en fonction de la politique et des contraintes de l'entreprise.

[Luc Hermitte]

Et je me reconnait parfaitement (malheureusement) dans ce que tu dis. J'ai un projet en cours ou j'utilise des vector "en remplacement" de tableau, sans réfléchir, alors que ta simple remarque et un tour sur google me montrent que je ferais mieux d'utiliser des listes doublement chainées, car je peux très bien me retrouver à vouloir ajouter un élément en plein milieu de ma liste (liste d'états d'un automate).

Faites des benchs avant de croire qu'une liste donne de meilleures perfs qu'un vecteur.
Les résultats sont facilement surprenants.

Et accessoirement, le vecteur reste préférable à un new[] en l'absence de scoped_array. Si vous êtes capables de faire un new[taillemax], vous êtes aussi capable de faire un reserve ou un resize. Hormis l'argument de la 0-initialisation induite sur les types POD, cette critique du vecteur ne tient pas. Aller, en C++03 je vous concède aussi le cout possible, mais non certain, d'une copie en sortie de fonction.

Franchement, je préfère optimiser des allocations ralenties car non anticipées à des plantages et des fuites pour cause de types choisis non RAII.

Et si les étudiants n'ont pas le réflexe RAII, il vont perdurer avec le réflexe hand-written-leaks du C/C++. Non merci.

[Freem]

De son coté, le langage Qt (je l'appelle langage car il ajoute de paradigmes et des mots clés inexistants en C++ standard, comme les foreach, les signal, les slots, rapprochant énormement de Java) apporte un API claire, très bien structurée et hyper complete (XML, SQL, Http, FTp, socks, GUI, FS, scripts etc)

Je l'appelle aussi un langage. Et je ne l'apprécie pas vraiment, donc le "super" et tous les compliments que tu lui donnes je ne m'y associe pas.
Je n'apprécie pas vraiment les lib qui modifient la chaîne de compilation, et Qt ajoute son outil la ou d'autres ont juste développé des mécanismes à base de template. Bon, c'est une question de goûts après

Quand je lis ça, je suis dégoûté et encore plus énervé comme les cours bidons que j'ai eu en école. Je m'aperçois au fil des mes lectures sur Developpez, et ton commentaire particulièrement, que je passe à côté de à côté de ce langage à cause de cette méconnaissance ! Oui, monsieur, je suis pas content

Je suis ravi que mon post ait servi à quelqu'un, vue sa longueur, j'avais un peu peur qu'il ne soit pas vraiment lu
Si ça peut te rassurer, je suis moi-même assez blasé d'avoir dû apprendre son existence seul. Ca, et celle des template, entres autres.

Pour le reste, je trouve que la STL devrait être enseignée au début de l'enseignement du C++. Et ensuite, que l'on force les gens à recoder certaines parties, puis de leur faire s'échanger les codes sources afin qu'ils s'aperçoivent à quel point les outils standards peuvent être bien foutus, et pourquoi il faut éviter le NIH.

Pour le fait que la SL ne soit pas complètement implémentée par tous les compilateurs, j'ai déjà entendu dire, en effet. Ainsi que certaines fonctionnalités du C++ qui semblent être fréquemment désactivées volontairement afin de réduire la taille du binaire et de booster ses performances, comme la RTTI (Run-Time Type Information, ce qui permet les cast dynamiques. Note pour ceux qui sont en cours et qui n'ont pas encore vu ce que c'est.), manifestement majoritairement dans l'embarqué.
Mais je pense que l'embarqué, même si c'est une utilisation du C++ qui ne mérite pas d'être négligée (aucune utilisation de C++ ne le mérite, amha) n'est pas la cible de la majorité des développeurs. (J'adorerai toucher du doigts l'embarqué, mais je ne pense pas pouvoir le faire de sitôt, à mon grand dam).
Donc, je ne pense pas que l'on devrait prendre en compte ce type de développement dès le début. Je pense qu'on devrai casser cette réputation de langage inutilisable dans un premier temps, et une fois ceci fait, apprendre aux gens à utiliser les bons outils du langage aux bons endroits, ce qui est loin d'être aisé je pense.

Bien sûr, j'ai remarqué aussi qu'a chaque fois qu'on parle de comment enseigner, les gens ne sont jamais d'accord (sûrement parce que personne n'a entièrement raison)

Une dernière chose. Je constate que très souvent les gens s'amusent avec les "using namespace xxx". Je trouve que c'est regrettable, parce que je trouve au final que ça ne contribue pas à rendre la lecture du code aisée. J'identifie plus vite std::vector comme faisant partie de la stl que vector.
D'autant que vector pourrait très bien être utilisé pour représenter un vecteur mathématique!
Ce qui fait que j'utilise rarement cette fonctionnalité, je lui préfère les typedef quand l'ensemble est trop long. Par exemple "std::vector<MaClasse>::iterator" devient souvent "iterMaClasse" dans mes codes. (bon, je sais, si jamais j'utilisais une liste avec MaClasse à côté, j'aurai un petit souci de convention de nommage... faudra que j'y réfléchisse un jour)

[Bousk]

Personnellement, cela ne me choque pas plus que ça que la STL ne soit pas enseignée (j'ai d'ailleurs découvert la STL une fois diplômé seulement). Si on enseigne la STL, pourquoi ne pas enseigner QT, BOOST ou n'importe quelle autre framework ? Bien qu'elle fasse partie des spec du langage, elle s'utilise comme n'importe quelle autre lib.

Un étudiant sachant utiliser une librairie quelconque saura utiliser la STL, et surtout il saura s'en passer si elle n'est pas disponible. Il comprendra aussi pourquoi le std::vector n'est pas un conteneur magique et pourquoi ses perf s'effondre quand il le remplis à coup de push_back.

Un étudiant ayant été formé a utiliser la STL dès le début ne saura plus quoi faire s'il n'a pas son précieux std::vector sous la main. Il faut arrêter de penser que la STL est un acquis absolue toujours disponible en toute circonstance.

Après, il faut aussi faire la différence entre ceux qui se contentent de ce qu'ils connaissent et continue à faire des new int[...] à outrance, et ceux qui comprennent tout l'intérêt d'utiliser des choses nouvelle plus haut niveaux.

On parle quand même du standard, pas d'une lib supplémentaire.

Et quand je vois les cours de JAVA, on utilisait très bien les List, Spring et je ne sais plus quels autres éléments pour créer fenêtres et collection. Alors pourquoi ne pas faire de même en C++ ?

[gbdivers]

Je pensais plus au fait qu'un étudiant ayant apris dès le début à utiliser un std::vector se contera des faire des push_back sans trop réfléchir (allez-pas me faire croire que l'étudiant vas allez lire la doc pour voir ce que ça implique).

Un étudiant ayant appris à faire des new et gérer sa mémoire à la main est plus sensibilisé au fait qu'on ne fait pas ce qu'on veut avec la mémoire et se posera peut être plus de question sur ce qu'il se passe en interne.

Ok, je comprend l'idée de l'approche (même si c'est pas l'approche que je préfère).

Mais on est bien d'accord pour dire que le cours qui aborde la STL sans montrer les limites de l'utilisation des vecteurs est aussi mauvais que le cours qui utilise l'approche par new sans montrer les limites (en particulier les problèmes de libération de mémoire en cas d'exception), non ?

Le problème revient donc encore à la qualité de l'enseignement, pas au langage lui même, je crois.

Je pense qu'il vaut mieux enseigner le C++ pur et dire qu'il existe des lib plus haut niveaux (en parlant de la STL bien sûr) disponible la plupart du temps. Cela rend les étudiants peut être moins opérationnel dès le début, mais plus polyvalent et plus "malléables" au sens où comme ils n'ont pas encore leurs petites habitudes et leur lib préférées qu'ils ont appris à l'école, ils adoptent plus facilement les conventions utilisées dans leur boulot. Une lib s'apprend sur le tas en fonction de la politique et des contraintes de l'entreprise.

Donc c'est qu'une question d'objectif pédagogique.

Par contre, l'approche "bas niveau" n'entre-t-elle pas en contradiction avec les reproches que l'on entend souvent avec les formations universitaires ? (à savoir, former des théoriciens, qui n'ont aucune idée de comment ça se passe dans "la vraie vie", qu'il faut former quand ils entrent dans l'entreprise)

Pour le reste, je trouve que la STL devrait être enseignée au début de l'enseignement du C++. Et ensuite, que l'on force les gens à recoder certaines parties, puis de leur faire s'échanger les codes sources afin qu'ils s'aperçoivent à quel point les outils standards peuvent être bien foutus, et pourquoi il faut éviter le NIH.

Je crois aussi que c'est la "bonne" approche. Tester soi même les limites de son code et voir les choix techniques qui ont été fait dans la STL (ou autre).
On ne peut faire du code plus "performant" (en terme de performances pures ou de sécurité) que quand on maîtrise les outils existants.

[seeme]

On parle quand même du standard, pas d'une lib supplémentaire.

Et quand je vois les cours de JAVA, on utilisait très bien les List, Spring et je ne sais plus quels autres éléments pour créer fenêtres et collection. Alors pourquoi ne pas faire de même en C++ ?

Parce que ces éléments font partis de Java, et sont disponibles sur toutes les plateformes supportant Java. Pas en C++.

De plus, en C++ la gestion de la mémoire est critique et à la charge du développeur (ce qui ne veut pas dire qu'on en fait pas ou qu'on ne fait jamais de conneries en Java). C'est essentiel de maîtriser la gestion mémoire avant d'utiliser des conteneurs dont on n'a pas la moindre idée de ce qu'ils font.

On choisi C++ quand on veut de la performance et un très haut niveau de personnalisation et d'optimisation. C'est donc critique de connaitre toute cette partie bas niveau. D'après moi on part de plus loin avec C++ donc on met plus de temps avant d'arriver à se poser la question de la STL.

Un enseignant n'est pas là pour rendre le langage sympa. Il est ce qu'il est et il faut l'enseigner tel qu'on l'utilise.

[Kaamui]

@Bktero: En théorie si le compilateur respecte la norme il doit fournir une implémentation de la bibliothèque standard. Mais en pratique, si la plateforme est un peu "exotique" (embarqué par exemple), il se peut que juste le langage soit pris en compte et pas la bibliothèque standard. Ca dépend de ce que les constructeurs ont founis et ce que la communauté a développé.

@Kaamui: Choisir son conteneur par rapport aux complexités théorique n'est bon qu'en première approximation, sutout concernant std::vector. Il faut bencher pour en avoir le coeur net.

Faites des benchs avant de croire qu'une liste donne de meilleures perfs qu'un vecteur.
Les résultats sont facilement surprenants.

Et accessoirement, le vecteur reste préférable à un new[] en l'absence de scoped_array. Si vous êtes capables de faire un new[taillemax], vous êtes aussi capable de faire un reserve ou un resize. Hormis l'argument de la 0-initialisation induite sur les types POD, cette critique du vecteur ne tient pas. Aller, en C++03 je vous concède aussi le cout possible, mais non certain, d'une copie en sortie de fonction.

Franchement, je préfère optimiser des allocations ralenties car non anticipées à des plantages et des fuites pour cause de types choisis non RAII.

Et si les étudiants n'ont pas le réflexe RAII, il vont perdurer avec le réflexe hand-written-leaks du C/C++. Non merci.

@Flob90 et @LucHermite : je préfère vous demander que demander à Google... c'est quoi des benchs ?

Comment on procède ?

@LucHermite : comment savoir quels sont les types non RAII ?

PS : encore des notions qu'on n'apprend pas à l'école...