Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Le C++ : un langage orienté débutant !
Le langage C++ évolue, son apprentissage doit évoluer aussi

Le , par gbdivers

0PARTAGES

7  0 
Quelles sont les difficultés majeures qui bloquent l'apprentissage du C++ en 2012
Ce n'est plus une nouvelle, le C++ continue son évolution avec la publication de la nouvelle norme, le C++11. Quels étaient les objectifs de cette évolution ? Il y a en avait plusieurs, mais nous allons nous intéresser ici à un seul point : "rendre le C++ plus facile à apprendre et à enseigner" (B. Stroustrup).

Or, en pratique, force est de constater que le langage C++ rebute beaucoup de débutants. Certains n'arrivent pas à maîtriser les abstractions de haut niveau. D'autres bloquent sur les problèmes de gestion mémoire. Il y en même qui ont peur de la réputation du C++ et fuient avant de le tester.
On reproche régulièrement au C++ d'avoir une syntaxe trop complexe, de permettre d'avoir 10 solutions pour un problème, de proposer des mécanismes d'abstraction trop complexes ou au contraire de ne pas sécuriser les manipulations de la mémoire, de ne pas fournir assez de fonctionnalités dans le langage et d'avoir trop de bibliothèques externes.
On retrouve ainsi des débutants qui rencontrent encore et toujours les mêmes difficultés et refont les mêmes erreurs.

Est-il possible de changer la façon dont est abordé le C++ pour en faire le langage parfait pour les débutants ?


A votre avis, qu'est-ce qui doit évoluer dans l'enseignement du C++ ?
Le C++ est-il par nature un langage trop complexe à force de vouloir trop en faire ?
Les développeurs seniors ont-ils réussi à évoluer avec le langage et à transmettre les bonnes pratiques ?

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de koala01
Expert éminent sénior https://www.developpez.com
Le 21/04/2012 à 17:28
Salut,

Je crois sincèrement que le gros problème, ce sont les profs qui doivent apprendre C++ aux élèves...

Trop souvent, ils font apprendre du "C with classes" sans avoir une once d'approche des principes même de conception OO (et sans parler des principes relatifs à la programmation générique )

En java (ou en C#), l'héritage est "facile", vu qu'il ne peut etre que simple, et l'on peut sans risque envisager l'héritage "simplement" parce que deux classes présentent une interface commune, alors que l'héritage n'a aucun sens "sémantique".

Si j'avais du attendre mes profs, jamais je n'aurais entendu parler de LSP, d'OCP, d'inversion de dépendance, de responsabilité unique, de sémantique d'entité VS sémantique de valeur ou encore de demeter!!!!

Or, c'est la mise en oeuvre stricte de ces principes qui permettent d'éviter bien des écueils, quel que soit le langage (OO s'entend ) envisagé.

En outre, les profs qui présentent, quand ils le font, la forme de Coplien ne présentent, le plus souvent, qu'une des formes: celle rendant obligatoire la présence d'un constructeur, d'un constructeur par copie, d'un opérateur d'affectation et d'un destructeur, puis obligent ( !!! ) les étudiants à l'utiliser de manière systématique.

Il peut, effectivement, etre utile de s'assurer que l'étudiant a bien compris cette forme, mais il faut aussi qu'il comprennent:
  1. Que ce n'est pas la seul forme de la règle de Coplien qui existe
  2. Qu'elle n'est adaptée que pour les classes ayant sémantique de valeur
  3. Que le compilateur est en mesure de créer ces différentes fonctions si leur action est triviale
On peut aussi parler du fait que la STL n'est pas (ou peu) abordée, et que le prof insiste beaucoup trop pour que leurs étudiants gèrent eux meme la mémoire, alors qu'il faudrait en fait faire l'inverse : parler d'abord et avant tout des classes telles que string vector et autres conteneurs, quitte à aller voir en profondeur à quoi cela correspond une fois que les bases sont acquises.

En dehors de cela, il est vrai que l'évolution lente de C++ (on a parlé de C++11 pendant plus de cinq ans, à tel point que cette nouvelle norme m'a presque fait penser au monstre du loch ness, par moment) n'aide pas vraiment à son utilisation, tant il pouvait ne pas être en adéquation avec les besoins des développeurs (un simple exemple : les threads )

J'ai aussi voté pour l'impossiblité de créer des IHM en natif, car j'ai l'impression que, à l'heure actuelle, on jure bien plus par l'aspect IHM d'une application que par son utilisation en mode console (ou en mode serveur )

J'ai, enfin, voté pour les messages d'erreur incompréhsensibles, tels qu'ils apparaissaient avant la sortie de C++11...

Grâce aux apports de la nouvelle norme, on remarque maintenant que les messages deviennent sensiblemnt plus clairs, mais encore faut il décider de l'utiliser

Par contre, je ne crois sincèrement pas que le nombre de bibliothèques ou d'outils externes, la gestion bas niveau de la mémoire, l'absence de mécanisme comme le GB ou que le manque de portabilité soient des freins à l'utilisation de C++...:

C++ est capable d'utiliser, en gros, toutes les bibliothèques C, en plus des bibliothèques "C++ only"... Ce n'est pas un mal, si ce n'est que l'on peut, effectivement, se trouver face à l'obligation de choisir entre deux bibliothèques fournissant des outils identiques.

Mais ce genre de choix permet, justement, d'avoir une préférence, que ce soit pour des raisons clairement objectives ou non, et la liberté commence par la possiblité de choisir

Si l'on travaille correctement, la gestion manuelle de la mémoire et l'absence de mécanisme de garbage collector deviennent suffisemment annecdotique pour que ce soit pas des problèmes... Tout au plus pourrait-on dire que cela nécessite "un tantinet" plus d'attention

Pour ce qui est du "manque de portabilité du langage, je crois qu'il est surtout du au fait que certains n'aiment simplement pas C++ et ne ressentent donc pas le besoin d'en fournir une implémentation correcte pour leur système

Enfin, je ne trouve pas la syntaxe de C++ *si complexe* que cela

Bien sur, nous avons affaire à un langage multi paradigme, ce qui fait qu'il y aura, fatalement, plusieurs types de syntaxe à prendre en compte.

Mais la syntaxe "de base" n'est vraiment pas compliquée!!! Il n'y a que quand on commence à s'intéresser à la programmation générique que les choses peuvent, tout doucement, commencer à se corser
15  0 
Avatar de benjani13
Membre extrêmement actif https://www.developpez.com
Le 24/04/2012 à 10:32
Il y a un réel problème d'apprentissage de la programmation en général je pense, le C++ ressort plus que d'autres langages du fait de sa complexité.

Je suis en première année de DUT Informatique, et en un an on apprend le C (semestre 1), le C++(1/2 semestre 2) et le Java (1/2 semestre 2).

Notre de prof de C nous a donné un enseignement trop abstrait dès le C. En TP nous ne faisions que des petits programmes du type programme de calcul de surface/volume de différents formes (a travers un menu, en console bien sur), lorsqu'on devait voir les scanf, et des programmes utilisant des doubles indirections lorsqu'on a commencé les pointeurs.

Au lieu de cela, il aurait du nous faire faire une multitude d'exos, qui paraissent bêtes pour certains peut être, du type "afficher le contenu d'un table", "retourner un tableau", "faire la somme des éléments d'un tableau", etc. Ce genre de petits exos, de quelques lignes, qui font que les élèves vont s'approprier la logique du langage. Et cette logique, je vous assure que certains ne l'ont toujours pas.

En C++ il a continué dans la même veine, mais le temps d'enseignement accordé ne l'a pas aidé. On a du avoir, au maximum, 8 semaines de cours de C++ (en en enlevant une pour le contrôle). C'est forcément trop peu pour tous voir et pratiquer assez.

On a eu épreuve pratique (notée) de fin de C++, qui consistait à écrire une classe représentant une planète. L'épreuve était divisée en trois partie:
- Écrire la classe de base, avec des champs simple (vitesse, rayon, type, révolution).
- Ajouter une chaine de caractère (de type C), et la créer de façon dynamique(gestion des pointeurs). Puis mettre la classe sous forme de Coplien.
- Introduction d'une composition en ajoutant deux champs de type Date (classe qu'on avait déjà écrit avant).

Résultat? En deux heures, au moins la moitié de la classe n'a pas passé la première étape. On a du être 3 ou 4 a passé à la troisième étape, et je suis le seul a avoir finit le TP.

Mais la faute en revient aussi en partie aux élèves! Indubitablement mordu de programmation (et d'informatique en général, je suis tombé dedans au collège), je m'attendais, en suivant un cursus informatique, à retrouver d'autres passionné(e)s. Et bien pas du tout, 95% des élèves baillent en amphi lorsqu'on leur parle de classe abstraite en C++, du fonctionnement d'un transistor en architecture, de l'organisation du noyau linux, pendant que les 5% restant s'extasie. J'ai souvent l'impression d'être le seul réellement passionnée par ce qu'on nous enseigne.
Car si je suis "bon" (par rapport a mes camarades) codeur c'est bien par ce que je suis passionné. C'est par ce que cela fait depuis la troisième que je lis des tutos sur internet, que je m'amuse à coder des petits jeux genre snake, etc.

En programmation je me suis bien rendu compte que pour progresser il faut continuer le cours sur internet, faire des exos dans son coin, se faire insulter par le compilateur pendant des heurs. Et pour cela il faut être motivé et passionné.

Citation Envoyé par Traroth2 Voir le message
C'est tout à fait vrai, même si ce n'est pas spécifique à C++. Les enseignants et les chercheurs ne connaissent souvent pas les réalités de l'entreprise. L'architecture, c'est un domaine où on cherche à réfléchir dans le but d'améliorer la maintenabilité, la réutilisabilité, la robustesse, la sécurité, etc. C'est souvent très loin des préoccupations académiques.
Et bien, malgrès ce que j'ai pu dire sur lui dans mon précédent post, une qualité de mon prof de C++ et qu'il venait du monde tu travail. Il nous a initié aux méthodes agiles, à la programmation par occurrence, aux séquence de tests et à la sacro-sainte réutilisabilité.
10  0 
Avatar de stardeath
Membre expert https://www.developpez.com
Le 21/04/2012 à 1:34
pour ma part j'ai commencé le c++ à la fac en master 1, déjà c'est tard et en plus le cours portais plus sur comment remplacer printf par cout. c'était pas glorieux, la suite c'est le projet, un annuaire, résultat, à la présentation j'étais hors sujet parce que j'avais utilisé la stl ... triste monde cruel. (sachant que faire joujoux avec des pointeurs et autres, je faisais ça en pascal et c pendant les 3 années de licence)

comment le langage peut attirer des gens si l'enseignement est aussi pauvre ; mais je ne sais pas finalement quel est le mieux, faire du java où les profs n'ont pas besoin d'être très compétents, ou du c++ qui visiblement n'est pas dans les bonnes grâce des profs.

par contre faire du c++ un langage facile à apprendre est une très mauvaise idée amha, on voit les dégâts avec php ou js qui sont des saletés pas possible.
11  2 
Avatar de CedricMocquillon
Membre averti https://www.developpez.com
Le 21/04/2012 à 11:56
Je pense que si c'est bien amené, le C++ n'est pas plus difficile à apprendre que d'autre langages. Le plus délicat est (comme dans beaucoup d'autres situations) la qualité de l'enseignement: du C++ présenté à base de STL et de RAII est très accessible et permet de faire déjà beaucoup de choses avec le langage. Les subtilités de ce que l'on peut faire au niveau de la mémoire ne devraient arriver qu'après.
Enfin je pense qu'il ne faut pas négliger la complexité algorithmique dans la présentation notamment de la STL, il faut idéalement voir la STL comme une "boite noire" au niveau de l'implémentation (en tout cas dans les premiers mois d'apprentissage) mais il faut être parfaitement informé des garanties de performances offertes.
9  1 
Avatar de Freem
Membre émérite https://www.developpez.com
Le 24/04/2012 à 16:12
Citation Envoyé par Bktero Voir le message
J'ai eu envie de cocher toutes les réponses également, je ne l'ai pas fait car je me suis aperçu ces derniers temps que je ne connaissais pas ce langage, au final.

J'ai (réellement) appris la programmation avec le C. Logique pour un étudiant en électronique et info industrielle. Et puis un beau jour, on a eu un cours de C++. Pardon : de C avec classes ! En réalité, ce cours était un cours de POO et le prof avait décidé d'utiliser le C++ pour montrer ce qu'est une classe. C'était pratique puisque ses élèves connaissaient le C et donc n'étaient pas perdus par la syntaxe.

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 ???

Pour aller au delà de l'enseignement, je pense que l'intérêt de C++ pour la plupart des gens est limité. C++ est comme C : un langage où tout (ou presque) est à la charge du développeur. Cela permet de faire des applications ultra personnalisables, optimisables, maitrisées. Le soucis pour moi est qu'on retrouve les problèmes du C : compilation parfois lourde, problème de portabilité, évolution relativement lente (comparé à Java ?).

J'ai aussi l'impression que, comme tout est à faire, il n'y a du coup rien de tout fait, prêt à l'emploi. Comme je l'ai dit, je ne connais pas la STL et c'est peut-être qu'une impression, mais je ne dois pas être le seul à l'avoir.

Je compare avec d'autres langages :
1) J'ai utilisé Java au boulot, alors que je n'y connaissais rien. La puissance de la Javadoc et des milliers de classes incluses dans le JDK font que tu peux coder rapidement des applications relativement complexes, sans faire appel à des lib externes. Cela attire plus qu'un langage CIY (Code It Yourself ^^).
2) J'apprends Python en ce moment et ce langage est simple et souple. J'aime la rigueur des langages compilés mais il est vraiment que pour faire des petites applications, un développeur amateur ou un pro souhaitant faire un outil perso, se tournera plus facilement vers Python que vers C++.

Enfin, de ma courte expérience professionnelle, je pense qu'il est plus simple de dire à un mec "tiens, tu connais pas, mais tu vas faire du Java" que de lui dire la même chose avec C++. Java est à la mode, Java ça a l'air cool, Java c'est portable, nianianiania. J'ai travaillé sur des projets où personne ne maitrisait vraiment les technos utilisées (vive les SSII) alors on utilise des technologies "simples". On remplace des applications en C / C++ (certes rapides mais difficiles à maintenir) par des applications en Talend Open Studio (moins rapides mais beaucoup plus simples à prendre en main).

Je ne vois pas C++ comme un langage à utiliser à tout va. Tu utilises ce langage quand tu sais pourquoi tu en as besoin. Pour cette raison, je ne vois pas C++ devenir un langage "grand public" que tout le monde aura envie d'apprendre.
En effet, on sens que tu n'utilise pas la STL.
Je suis en train de refaire un logiciel de dessin vectoriel open source sur mon temps libre, en C++. (autoREALM pour les connaisseurs, et le mot refaire serait idéalement complété par "from scratch", "traduction du delphi", et "tentative de conception soignée".)
En utilisant la STL, la fonction la plus grosse pèse 40 lignes, je n'ai fait, (et ne ferait probablement), aucun algo genre algo de tri.
Je n'ai aucune gestion de la mémoire, les seuls pointeurs que j'utilise sont la a des fins de polymorphisme. Encapsulé dans ces très confortable unique_ptr d'ailleurs (et la lecture de GotW 102 me fait penser qu'il va falloir que je corrige quelques lignes).
Il n'y a aucun tableau statique.

Pour le dessin à l'écran, je fais comme tout le monde, j'utilise des librairies: openGL pour le rendu, et un framework d'IHM (wxWidgets dans ce cas précis) pour les fenêtres. Pour ce qui concerne les fichiers de config, je fais mumuse avec boost::filesystem.
Je suis extrêmement loin du CIY comme tu dis. Limite je ne refais quasiment rien.

Comment ça se fait que des librairies permettent cette flexibilité et la transparence qui rend le code tout de même simple à lire? Très simple:
_ template
_ surcharge d'opérateur (que java ne propose pas, au passage, donc pour moi java est bien intuitif pour faire des tableaux dynamiques que le C++)

Mais je t'accorde que les gens voient souvent le côté "démerdes-toi" de C++. Il faut admettre que si on veut, on peut tout refaire à la main, mais moi, je suis flemmard, je réutilise la roue que les autres ont inventés. Et quand je n'aime pas la couleur de cette roue, plutôt que de la refaire, je l'enrobe. (je pense au système de menus de wxWidgets la, qui est selon moi assez foireux pour faire un truc dynamique)

Vu que le C++ est multi paradigme, c'est tout le contraire du DIY.
Avec la programmation générique, on peut réutiliser énormément de code.
Avec la programmation impérative fonctionnelle, on peut réutiliser les bibliothèques C, qui sont quand même très puissantes.
Avec la programmation impérative objet, on peut enrober le code générique, fonctionnel, et bas niveau dans des classes qui seront simples comme bonjour à utiliser.

Et j'aimerai beaucoup qu'on me dise en quoi C++ n'est pas portable?
En tout cas, wikipedia n'est pas d'accord avec ceux qui l'affirment:

C fut choisi parce qu'il est rapide, portable et d'usage général. En outre, il était une bonne base pour le principe original et fondateur de C++ : « vous ne payez pas pour ce que vous n'utilisez pas ». Dès le départ, le langage ajoutait à C la notion de classe (avec encapsulation des données), de classe dérivée, de vérification des types renforcés (typage fort), d'« inlining », et d'argument par défaut.
Je rappelle au passage, que portable, ça veut pas dire qu'il n'y a pas besoin de recompiler. Ca veut dire qu'après compilation, ça peut marcher partout, nuance. C++, étant héritier de C, est aussi portable que celui-ci.

C'est d'ailleurs sûrement pour ça qu'il n'y a pas d'IHM de base dans le standard, parce que les IHM, il n'y a rien de moins de portable.
Pas convaincu par ça? Qt ré-implémente les fonctions dont il a besoin, les IHM de microsoft ne fonctionnent que sur windows, et encore, ça dépend de la version, wxWidgets est bourré de #ifdef, java ré-implémente dans un framework à la façon de Qt, et un autre framework utilise la technique de wxWidgets.
Et de toute façon, une fenêtre ne sera pas la même selon l'écran, alors que je vois beaucoup de code qui précisent les coordonnées des fenêtres/composants en dur. Je pense que c'est dû aux RAD d'ailleurs...
Ce genre de choses qui font que les logiciels sont pénibles à utiliser sur des netbook car les fenêtres sont sur-dimensionnées, j'ai constaté qu'on ne les retrouve pas avec les logiciels qui utilisent ncurses (genre, aptitude pour les débianeux, ncmpcpp pour les utilisateurs de mpd, lynx... et beaucoup d'autres)

Le C++ est effectivement issu du C, mais s'il a pris une orientation qui lui permet de garder les avantages du C, il a aussi évolué pour ajouter des fonctionnalités.
Bon, il y a quelques pertes... Par exemple, mieux vaut prendre l'habitude d'utiliser "++i" au lieu de "i++", histoire de pas le faire pour les objets (pour un int, c'est pas grave, mais pour un itérateur on crée/détruit une copie pour rien. Juste un problème de performances, pas de bug.)
Mais quelques pertes qui ne sont rien quand on peut reléguer la gestion de la RAM au plus profond de son programme.

Je fais peut-être le fanatique, mais je ne vois pas ce que C++ ne peux pas faire face a des langages plus récents... Ah, si, il n'est pas réflexif.
Le reste, de dire que les langages gèrent les IHM, c'est faux. Ce sont les librairies standard de ces langages qui font ça.

Au sujet de la javadoc, GCC utilise doxygen. WxWidgets, et Qt aussi. Javadoc n'est pas un argument recevable, pour moi. Au passage, je trouve la javadoc d'oracle plutôt crade pour s'y retrouver. Ca a dû être organisé à une époque, mais la... (je me suis servi récemment de java en cours, et je me suis pas contenté des miettes que le prof donnait, ce qui m'a encore valu de me faire taper sur les doigts parce qu'en faisais plus que ce qu'il demandait, en moins de lignes de code. Du coup, pour brider mon code, j'ai ajouté un flag genre ifdef... j'ai honte de brider mon code mais bon, c'était ce qui était demandé...)

Les milliers de classes java, je trouve que ça fait trop fouillis.
Tout ça dans le standard? A quoi doit-on se référer du coup? Standard C++ est peut-être complexe, mais l'api est maîtrisable. JAva, j'en doute. D'autant plus quand ça fait doublon. C'est quoi la différence entre Array et Vector en java d'ailleurs? Bon, je suppose que c'est une question d'habitude ou de culture:
Le dev C++ va voir son standard pour les algorithmes les plus commun seulement (tri, aléatoire, trouver une occurrence, extraire une partie de conteneur...), et pour les interactions avec le système va voir l'API du système.
Le dev java va voir son standard pour tout, mais du coup a moins de choix en terme de conception de l'outil qu'il va utiliser.
8  0 
Avatar de dourouc05
Responsable Qt & Livres https://www.developpez.com
Le 20/04/2012 à 22:14
Citation Envoyé par gbdivers Voir le message
A votre avis, qu'est ce qui doit évoluer dans l'enseignement du C++ ?
Arrêter de l'enseigner en même temps que le C (au point que certains croient apprendre le C/C++ ) ou forcément après le C, comme s'il continuait parfaitement dans la lignée ? Le C a mauvaise presse en ce qui concerne l'enseignement, alors que le C++ ajoute pas mal de belles choses qui évitent notamment les pointeurs (vivent les références), la pire chose possible pour un débutant.
8  1 
Avatar de Bousk
Rédacteur/Modérateur https://www.developpez.com
Le 20/04/2012 à 22:34
J'ai un problème, j'aimerais cocher toutes les réponses du sondage.

Je pense que c'est un mélange de tout ça qui rebute les nouveaux utilisateurs, à fortiori les étudiants nommé par beaucoup "génération google".

Le fait que par défaut le langage ne permette rien en ihm leur laisse l'impression première d'inutilité.
Après ça, on leur montre comment on crée une fenêtre, et là ils commencent les gros yeux "mais je veux juste créer une fenêtre".
Dès qu'on parle pointeur, certains pensent déjà au suicide avant la moindre explication, et la gestion de la mémoire leur fait pousser des boutons.

Quand à côté on leur vend du JAVA sous eclipse/netbeans ou C# sous visual en WYSIWYG, beaucoup ne comprennent pas l'intérêt de "se prendre la tête" avec le C++.
7  0 
Avatar de koala01
Expert éminent sénior https://www.developpez.com
Le 25/04/2012 à 17:42
Citation Envoyé par gl Voir le message

Ce n'est pas tant du NIH que du "les premières versions datent d'avant l'introduction de ces fonctionnalités dans le standard et il faut maintenant supporté l'historique".
Je suis bien conscient que c'est du à un aspect historique de Qt, mais le résultat reste le meme, malgré tout, meme si la norme est de mieux en mieux prise en charge (je pense, par exemple, aux moyens de passer de QString à std::string, ou aux nouvelles futures fonctionnalités de la version 5 )

Mais, si j'ai un regret vis à vis de Qt (dont je ne remet nullement la qualité en question, ceci dit ), c'est que le projet a peut etre été lancé... un ou deux ans trop tot, à une époque où les compilateurs étaient encore tous loin de respecter une nomre à peine sortie
Citation Envoyé par pyros Voir le message
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.
Déjà, il faut quand meme se rendre compte que le framework S(T)L fournit, essentiellement, des concepts "basiques":
les concepts memes de chaine de caractère, de tableau, de pile, de file, de table de hashage, d'arbre binare, de différents algorithme de tri ou de recherche font, à mon sens, partie de ce que l'on pourrait appeler les "principes de base de la programmation" et existent, d'une manière ou d'une autre (quitte à souffire du syndrome du NIH ) dans tous les langages impératif de troisième génération


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.
Attention, on ne dit nullement qu'il ne faut enseigner que la STL en occultant, d'une manière ou d'une autre, la gestion manuelle de la mémoire ou le moyen de réimplémenter une liste personnelle

Je crois que tout le monde plaide pour qu'il y ait, au minimum, une approche sur les deux points de vue (haut niveau avec std::vector et autres conteneurs, et une approche bas niveau avec gestion dynamique de la mémoire )

Mais, à titre perso, je préférerais que l'on aborde, en priorité, la S(T)L pour permettre de faire le parallèle entre les conteneurs qu'elle fournit et les concepts qu'elle soutient, et de reporter l'approche "bas niveau" à un moment où, ayant "maitrisé" les conteneurs, la gestion manuelle de la mémoire s'avère plus intéressante encore que le simple fait d'avoir trois entiers contigus en mémoire : Le moment où l'on va, par programmation décider du type réel d'une donneé sur base d'informations obtenues par ailleurs (héritage et polymoprhisme inside )
Citation Envoyé par pyros Voir le message
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).
C'est là que l'on fait la différence entre un étudiant "passionné" et un étudiant qui attend avec impatience la fin des cours

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.
à condition toute fois que le cours qui lui a appris à gérer la mémoire à la main ait été bon

Plus sérieusement...

L'apprentissage de la STL ne devrait pas se limiter au seul apprentissage de std::vector, mais devrait, à tout le moins, indiquer qu'il existe différents conteneurs (et lesquels) adaptés à différentes situations, tout comme un apprentissage de la gestion manuelles de la mémoire devrait mettre en évidence les bienfait qu'il peut y avoir à utiliser les différents concepts (tableau d'éléments contigus, liste, pile, file, arbres binaires et autres )

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.
A titre personnel, si je devais tomber dans un projet de moins de cinq ans pour lequel la STL a été volontairement écartée (donc, en excluant toutes les situations dans lesqelles elle n'est simplement pas disponibles ), je refuserais de travailler pour le projet

Je comprend ton point de vue dans le sens où, contrairement à d'autres langages, C++ devient particulièrement efficace grâce aux bibliothèques / frameworks extèrnes et donc dans le sens où il est bon, de manière générale, qu'un étudiant puisse apprendre à intégrer une bibliothèque externe dans son projet (et qu'il s'y soit frotté une première fois, si possible )

Par contre, je le répète, la S(T)L ne fait que fournir une implémentation, peut etre perfectible, de concepts que l'on retrouve dans n'importe quel langage de troisième génération, tel que des algorithmes et des structures de conteneurs classiques...

Il est vraiment dommage que l'étude de C++ ne passe pas par une approche minimal de ce que cette bibliothèque, sensée être disponible avec n'importe quel compilateur, est en mesure d'apporter, ne serait ce qu'en terme de qualité et de sécurisation du code
7  0 
Avatar de Dalini71
Membre averti https://www.developpez.com
Le 20/04/2012 à 23:18
Moi je pense que le plus gros problème c'est que ce qui semble etre de plus en plus enseigné a l’école c'est les langages a la mode comme Java ou C#. C'est simple, haut niveau, y'a pas besoin de savoir gérer la mémoire, y'a des outils drag & drop, ça fait le café... Bref ça parait tellement plus facile que le C++.

Et par conséquent les débutants ne voient pas l’utilité d'un tel langage, ils ne sont pas conscient de sa puissance, de son utilité.

Apres la syntaxe et la complexité du C++ rebutent également beaucoup. Si on fait n'importe quoi on est plus rapidement punit qu'en Java ou C#.

Si je dois résumer, les débutants ne sont souvent pas suffisamment formés (gestion de la mémoire, POO et programmation générique), et les atouts du C++ ne sont certainement pas assez mis en avant !
6  0 
Avatar de JolyLoic
Rédacteur/Modérateur https://www.developpez.com
Le 24/04/2012 à 9:36
Citation Envoyé par DonQuiche Voir le message
Une chose me chiffonne tout de même dans tout ce que je lis. Tout le monde insiste sur la nécessité d'introduire au plus tôt la STL et tout ce qui fait le C++ moderne. D'un autre côté, si vous n'avez que cent heures de cours à prodiguer, que vaut-il mieux former : des élèves capables de joliment manipuler la STL ou bien des élèves capables de manipuler les pointeurs sans se vautrer ?
Les deux ! Je donne un cours d'une vingtaine d'heures, pendant lesquelles j'introduis à la fois des concepts (paradigmes de développement, OCP, POO, exceptions...), des outils (contrôle de version...) et le C++ (plus des bribes de C# et Java). Et pour la partie C++, je parle à la fois de la gestion manuelle de la mémoire, et des moyens d'automatiser ça (shared_ptr, pas auto_ptr). Alors même si mon cours est dense et destiné à des élèves qui comprennent vite, j'imagine qu'en 100h, il y a de quoi faire des choses intéressantes si on ne dois faire que du C++. Non, pour moi la problématique principale n'est pas "quoi enseigner", mais plus "dans quel ordre enseigner". Et là, je suis partisan de commencer par les aspects haut niveau qui permettent de faire des programmes ayant un intérêt simplement (et qui corresponde à 90% du code écrit en C++) pour ensuite se concentrer sur les aspects plus bas niveau (qui bien que ne correspondant qu'à 10% du code écrit font partie de ce qui fait l'intérêt du langage).
Citation Envoyé par DonQuiche Voir le message
Enfin certains critiquent le manque de formation à la POO. Mais cela a t-il sa place dans un cours de C++ ? C'est plutôt un module à part. Qu'on fasse une embardée pour les spécificités du C++ qu'on retrouve de moins en moins ailleurs (héritage multiple, patterns spécifiques, etc).
Je suis d'accord que ça peut être séparé, même si le risque alors est d'avoir un cours de POO tellement abstrait que personne n'y comprends rien. Mais j'ai déjà enseigné le C++ à des élèves ayant un background de C et à d'autres ayant un background de Java, et il est clair que je pouvais aller bien plus vite dans mon enseignement avec les javaistes.
Citation Envoyé par DonQuiche Voir le message

Un dernier pour la route : le modèle de compilation. Ajouter aux normes un second modèle de compilation, moderne, dont les fichiers seraient compilés comme l'est n'importe quel langage aujourd'hui (sans headers, avec un traitement préprocesseur purement local et une étape de résolution des noms avant la compilation proprement dîte), ne serait pas du luxe. Cela n'enlèverait rien à la puissance du C++ (templates et defines toujours utilisables via des include) et accélèrerait grandement sa prise en main, sans même parler d'un intérêt pour de nouveaux projets.
Les modules sont actuellement le "silver bullet" du C++, qui permettraient tout et son contraire... Mais je suis d'accord que pour l’aspect enseignement, quels que soient les choix effectués sur le design de cette fonctionnalité, il ne peuvent qu'améliorer les choses !
6  0