Version imprimable
a- On pense aussi à SWT / eclipse RCP, et à apache -- et à une pléthore de cots trouvables grâce à google.Citation:
Envoyé par Drannor
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)
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.Citation:
Envoyé par Drannor
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.Citation:
Envoyé par seeme
La grande force du C++ c'est de convenir aussi bien à de la programmation embarqué que d'application haut niveau.Citation:
Envoyé par seeme
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++.
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).8OCitation:
Envoyé par Bktero
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:: )Citation:
Envoyé par 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.
Citation:
Envoyé par pyros
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.
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 ?Citation:
Envoyé par pyros
:fleche: 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 ?
:fleche: 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)
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.Citation:
Envoyé par Kaamui
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.
Ca me fait plaisir de ne pas être tout seul (encore que je connaisse le principe des namespaces :mrgreen:). 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.Citation:
Envoyé par Bousk
Moi ça me choque un peu. Aujourd'hui, ça m'apparait comme l'un des gros avantages du C++ par rapport au C.Citation:
cela ne me choque pas plus que ça que la STL ne soit pas enseignée
Si ton compilateur respecte la norme, elle est forcément disponible, non ?Citation:
Il faut arrêter de penser que la STL est un acquis absolue toujours disponible en toute circonstance.
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 :mouarf: ), 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"Citation:
Envoyé par seeme
@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.
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).Citation:
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 ?
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.
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.Citation:
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)
Faites des benchs avant de croire qu'une liste donne de meilleures perfs qu'un vecteur.Citation:
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).
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.
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.Citation:
Envoyé par TheBootroo
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 :)
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 :aie:Citation:
Envoyé par Bktero
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 :cry: (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)
On parle quand même du standard, pas d'une lib supplémentaire.Citation:
Envoyé par pyros
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++ ?
Ok, je comprend l'idée de l'approche (même si c'est pas l'approche que je préfère).Citation:
Envoyé par pyros
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.
Donc c'est qu'une question d'objectif pédagogique.Citation:
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.
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)
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).Citation:
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.
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.
Parce que ces éléments font partis de Java, et sont disponibles sur toutes les plateformes supportant Java. Pas en C++.Citation:
Envoyé par Bousk
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.
Citation:
Envoyé par Flob90
@Flob90 et @LucHermite : je préfère vous demander que demander à Google... c'est quoi des benchs ? :oops:Citation:
Envoyé par Luc Hermitte
Comment on procède ?
@LucHermite : comment savoir quels sont les types non RAII ?
PS : encore des notions qu'on n'apprend pas à l'école...