Un adage bien connu dit qu’enseigner, c’est répéter. Ceux qui fréquentent depuis quelque temps le forum C++ de Developpez le savent très bien : on revoit les mêmes discussions revenir régulièrement. Ce billet de blog va tenter d’analyser un peu les arguments concernant l’apprentissage du C++, en se focalisant plus particulièrement sur les difficultés d’utilisation. En particulier le raisonnement suivant, que l’on entend souvent : « il est préférable d’apprendre le C avec le C++ », ainsi que l’affirmation suivante, souvent pas comprise : « le C++ est un meilleur langage pour débuter que le C ».
Au delà de l'aspect volontairement provocateur du titre, le but n'est pas la critique du C, mais bien la comparaison de quelques spécificités de ces langages et leurs conséquences en termes d'apprentissage. Et plus globalement, la question posée est comment doit être abordé l'enseignement du C++ moderne.
Comment pensez-vous que les différences d'approche entre le C et le C++ peuvent impacter leurs apprentissages respectifs ? Quelles autres spécificités d'utilisation de ces langages peuvent poser des difficultés d'apprentissage ?
Une erreur dans cette actualité ? Signalez-le nous !
Ah ? Il me semblait au contraire qu'il démontrait qu'il était simple de les éviter avec une telle méthode. Tu peux développer ton point de vue ?
Commençons par le plus simple: quelle connaissance dois tu avoir pour comprendre la structure et la fonction, selon toi
En fait, tu dois déjà avoir pas mal de connaissance:
ce qu'est un pointeur
ce qu'est la différence entre la pile et le tas
ce que fait la fonction malloc
ce que fait le mot clé goto
ce que fait la fonction free
les risques que tu prend en cas de dépassement de mémoire
Pour tout développeur C un tout petit peu habitué, cela n'a l'air de rien, mais cela implique, pour le type qui veut apprendre C, qu'il doit s'intéresser à une série de concepts très importants (en C du moins) pour arriver à le comprendre.
Ceci étant posé (et je présume que tu ne me contrediras sur ce point ), posons nous une deuxième question: quand faudra-t-il que celui qui apprend C s'intéresse au point précédent
La réponse a presque de quoi choquer, car, en gros, c'est "dés que l'étudiant voudra écrire une nouvelle fonction", et, si on reprend purement le code que tu donnes en exemple, c'est encore pire, car la réponse devient "dés qu'il voudra gérer une chaine de caractères ton il ignore a priori la taille".
Autrement dit: très tôt dans l'apprentissage, car il aura à peine eu le temps d'apprendre ce qu'est une boucle et un test
Si l'on trace la boucle d'apprentissage, tu as donc (ce n'est qu'un résumé de ce que j'ai écrit quelques intervention plus haut )
apprendre à écrire la fonction main: ca prend cinq minutes
apprendre à écrire une boucle: allez, ca prend un quart d'heure pour voir les trois types de boucles
apprendre à écrire un test: dix minutes pour avoir les tests simple et les tests de type switch case
Jusque là, il n'y a pas grand chose de compliqué, je crois que tu seras du même avis que moi
Puis d'un seul coup, tu va lui dire "oui, mais, attention, il faut gérer les ressources", et tu vas, littéralement, devoir l'assommer avec les notions que j'ai citées au début de mon intervention, c'est à dire avec des notions réellement complexes et particulièrement importantes.
Et après, tu vas reprendre avec des notions comme les structures dynamiques (pile, file et autres) "simples", à condition d'avoir assimilé les notions complexes, "casse gu...le" si, par malheur, il ne les a pas assimilées.
Regardons maintenant la courbe d'apprentissage de C++...
on apprend à écrire la fonction main : cinq minutes (elle ne change pas de C, finalement )
on apprend les différentes boucles : un petit quart d'heure, (idem)
on apprend les différentes sortes de test: c'est toujours 10 minutes
On a besoin d'une chaine de caratère on introduit std ::string, et il faut même pas commencer à s'inquiéter des fonctions membres
Il est plus que temps de pouvoir utiliser des collections!! on introduit celles de la STL ("vous inquiétez pas de push_back, utilisez le, on en parle plus tard )
Il faut commencer à convertir des données de différents types on introduit stringstream (vous inquiétez pas de str(), ca viendra en meme temps que push_back )
Le passage d'argument commence vraiment à faire lourd: on introduit les références (c'est un alias de la variable que vous passez en argument, très compliqué, n'est-ce pas )
et on pourrait continuer comme cela
Il y a parfaitement moyen de voir en C++ l'ensemble du paradigme impératif sans avoir à s'inquiéter de la gestion des ressources (et la gestion de la mémoire est sans doute la pire bête noir des débutants )
Bien sur, on a "laisser quelques trucs de coté", mais, ou est le problème
Le fait que l'étudiant n'ait pas forcément conscience de ce que fait push_back au niveau de la mémoire est il handicapant
Sommes toutes, beaucoup moins qu'on ne pourrait le croire
En plus, on a une transition toute trouvée pour aborder le paradigme OO: "Ah, au fait, il est temps de nous intéresser à push_back et à str... Ce sont des fonctions membres".
Hé oui, C++ est un langage qui utilise le paradigme Orienté Objet: C'est un paradigme qui s'intéresse plus aux services qu'un objet peut rendre qu'aux données qui lui permettent de rendre ce service.
De fil en aiguille, on arrive au besoin d'héritage, bien sur...
Et ce n'est qu'à ce moment là qu'il devient intéressant de parler de pointeur et de tout ce qui s'y rapporte.
Mais les problèmes de syntaxe sont déjà assimilés depuis longtemps, et l'on a meme sans doute eu déjà largement l'occasion de s'habituer à un grand nombre d'erreurs lancées par le compilateur
Il est alors peut etre temps de revenir un peu plus en détail sur des fonctions comme push_back pour leur faire se rendre compte de l'impact d'une telle fonction en mémoire
ET s'il reste encore un peu de temps à l'horaire, on peut envisager d'aborder le paradigme générique
Au final, la courbe d'apprentissage est beaucoup plus souple et régulière que ce que l'on aurait eu en C
Pour ma part je considère le C comme obsolète. Non seulement parce qu'il n'est rien en C qui ne soit pas faisable aussi efficacement en C++, mais aussi parce que c'est un langage limité face au C++(11 encore plus) qui l'englobe tout en proposant plus de liberté, plus de flexibilité, et plus de paradigmes. En bref c'est comme si on avait le choix entre le tire-bouchon et le couteau-suisse complet.
Je ne le dirais pas obsolète, car pour moi il a deux avantages où il bat le C++ sans hésiter :
- Il est tellement simple qu'il est possible de trouver un compilateur C partout, et que ce compilateur ne sera pas trop buggé, voire même sera certifié conforme (important dans certaines parties de code embarqué touchant à la sécurité).
- Il reste un très bon dénominateur commun pour interfacer entre eux des langages divers et variés, alors qu'on ne sait même pas toujours interfacer entre eux deux bouts de programmes C++, même écrits avec le même compilateur (mais des options différentes).
A part ces deux usages, en effet, il faudrait vraiment trouver de très bons arguments pour me faire faire du C.
Parce que ce paragraphe ne ressemble à rien d'autre qu'à une dictature de l'esprit .
Alors je réponds simplement que non. Le style SOLID ne me convient pas, je le trouve trop rigide. Parce que je suis persuadé que tout n'a pas encore été inventé, et qu'aucune méthode n'est parfaite. C'est aussi simple que cela.
Ce n'est pas pour autant que je ne respecte aucun de ces principes, bien au contraire. Toutefois, ce n'est qu'une conséquence remarquée, non le résultat d'une règle appliquée. Aussi s'ils sont foulés au pied, cela ne me fait ni chaud ni froid.
Oui, j'ai l'arrogance de me sentir libre dans un vaste univers à peine effleuré, inexploré...
Par contre, il y a une chose qui m'a fait sauter au plafond (enfin, non, parce qu'ici il est bien à 3m et je suis pas un athlète...):
"std::shared_ptr pour les pointeurs, etc."
STOP!!!!!!!!!!
Par pitié, éviter de citer shared_ptr à tout va comme ça... Cet outil est dangereux: risques de références circulaires que l'on dois combattre avec weak_ptr, empêchements de maintenir parce qu'on ne sait pas qui exactement est responsable, augmentation des ressources consommées du programme (ram et cycles, même si ce n'est pas énorme, sur une ou deux instances, sur quelques milliers, ce n'est pas la même affaire!), ce genre de choses... pas très joyeuses.
Alors qu'a côté, on à un joli unique_ptr, qui consomme bien moins de ressources, évite quelques problèmes architecturaux de responsabilité, et n'a absolument aucun risque de références circulaires.
Pour le reste, c'est marrant de constater qu'a chaque fois que quelqu'un sort l'objet, il sort des principes dans tous les sens, et des acronymes à coucher dehors dont je n'ai jamais entendu parler.
Liskov? Euh, j'ai tenté de lire le truc sur wikipedia, j'ai rien compris... SOLID? J'ai eu la flemme de chercher un mot de ce genre... trop de risques de devoir fouiller 3H.
Cela dis, j'en connais quand même quelques uns aussi: GRASP, et le truc qui dit que si on implémente un Ctor, il faut faire d'autres implémentations... me rappelle jamais le nom...
Pour autant, suis-je un mauvais "dev objet"?
Je n'en suis pas si sûr... quoique si quelqu'un veut me juger, j'en serais heureux (avoir l'avis d'autres confrères n'est jamais une mauvaise chose, il faudra que je cherche du côté des communautés de revue de code, si ça existe)
Ne pas être mauvais ne signifie pas forcément être bon, bien sûr, et je sais que je ne suis pas encore bon, mon arrogance de débutant, j'en ai perdue une grande partie (pas tout, j'avoue) en 10 ans de dev autodidacte.
Et pour finir:
@gcorbineau:
C++ peut être objet, oui. Mais C++ peut aussi être générique, ou impératif, ou n'importe quel mélange de ces paradigmes.
Ta réponse prouve 2 choses:
_ tu n'as pas lu l'article
_ tu n'as pas lu la discussion, ou tu as occulté les gens qui répondaient directement à ta question
L'envie de dire "troll spotted" est donc super forte...
Juste une petit question comment on peut dire que le C++ est mieux que le C pour commencer!!
On ne dit pas que C++ est mieux pour commencer (quoi que (*)), on dit qu'il ne faut pas connaitre C pour apprendre C++
(*) A vrai dire, oui, C++ est mieux pour commencer que C car il permet justement de n'avoir pas à s'inquiéter directement de problème dont on ne prend réellement conscience qu'avec un minimum d'expérience.
L'exemple le plus frappant consiste en la gestion dynamique de la mémoire: En C, tu dois aborder les pointeurs et la gestion dynamique de la mémoire dés le deuxième chapitre (tout de suite après avoir vu ce qu'est une boucle ou un test), rien que pour pouvoir concaténer deux chaines de taille inconnue à l'écriture du code.
En C++, tu peux ne commencer à t'inquiéter des problèmes liés aux pointeurs qu'une fois que tu as déjà "pris de la bouteille" car il propose des mécanismes qui rendent la gestion de la mémoire totalement transparente (si tu veux concaténer deux chaines, tu utilises l'opérateur + ou += sur deux std ::string, et "basta", tu utilises push_back sur n'importe quelle collection pour ajouter un élément, sans avoir à t'inquiéter de savoir s'il faut ou non prévoir d'augmenter la capacité de cette collection)
Déja le C++, s'appuie sur le C, deplus le C n'est pas un langage objet contrairement au C++.
A vrai dire, C++ n'a plus rien à voir avec C, même s'il ne renie absolument pas son héritage.
Cependant, si je ne renie absolument pas mes origines, et que j'avoue avoir hérité de certains aspects du caractère de mon père, je refuserai toujours qu'on me confonde avec lui, et même sans doute qu'on tente de m'y comparer.
Il en va de même pour C++: il assume son héritage de C, il assume une certaine compatibilité avec celui-ci, mais il est totalement faut et restrictif de dire que C++ n'est "que du C amélioré".
C'est un langage totalement différent, qui apporte un grand nombre de possibilités totalement nouvelles par rapport au C et qui, surtout, est en mesure d'apporter une sécurisation beaucoup plus importante
Perso je pense que pour bien appréhender le langage (synthaxe, mot clé, ...) il est préférable de s'affranchire de la couche objet du C++, cela permet de bien maitriser les technique en C pour pouvoir les appliquer au C++.
Justement:
Vouloir limiter C++ à son paradigme orienté objets est particulièrement réducteur car il propose trois paradigmes (impératif (orienté fonctions), orienté objets et générique).
Le sens de l'article est de dire que l'on peut s'habituer à la syntaxe et à la grammaire de C++ en se limitant à son paradigme impératif et que cela aura pour principal intérêt de permettre de ne s'inquiéter de certains problèmes que lorsqu'ils se poseront réellement (encore une fois, on n'a besoin de l'allocation dynamique de la mémoire qu'un fois qu'on aborde la programmation OO et l'héritage )
Certain dirons, peut être, que je suis vieux jeux, mais je pense quand developpement il ne faut pas bruler les étapes!!
Je me pose la même question que Klaim : as tu lu l'article avant de répondre
Si ce n'est encore fait, je te conseille de prendre le temps de le lire, cela évitera au moins de devoir répéter ici ce qui est clairement expliqué dans l'article
Je tiens à préciser une chose concernant mon apparent extrémisme concernant les différents principes qui jalonnent le développement en général.
J'ai commencé le développement de manière strictement autodidacte, et même lorsque j'ai entrepris des études spécifiques, je n'ai jamais entendu parler, dans mes cours du moins, de la plupart de ces principes (à part le principe de responsabilité unique).
Et comme tout le monde, je me suis retrouvé "empêtré" dans certains projets qu'il m'était devenu impossible de faire évoluer dans le sens que je voulais.
A force d'"errer sur le forum", j'ai entendu parler de Liskov, et ca m'a intrigué.
En reprenant mes projets devenus impossibles à faire évoluer, j'ai pu me rendre compte qu'une bonne partie des problèmes d'évolution auxquels j'étais confronté venait du non respect de ce principe.
De LSP à SOLID et à déméter, il n'y a qu'un pas, qui fut, encore une fois, franchi grâce au forum.
Je me suis alors rendu compte que tous les problèmes d'évolutivité auxquels j'étais confronté avait pour origine le non respect de l'un de ces principes.
Depuis, j'avoue que je ne manque aucune occasion d'insister sur ces principes, uniquement parce que je sais ce que leur respect m'a apporté.
Maintenant, soyez sur d'une chose: je ne pourrai jamais faire plus que de vous inciter instamment à les respecter, libre à vous de le faire... ou non.
Mais, si vous décidez de ne pas les respecter, il ne faudra pas venir pleurer chez moi
Je pense avoir compris : "get" veut dire obtenir, le sujet est donc la fonction appelante alors que "give" signifie donner, le sujet est donc l'objet utilisé.
Ce serait donc plus une question de grammaire que de programmation ?
Par contre, quid du fait qu'on a plus l'habitude de voir "get" que "give" ? Ie qu'un programmeur s'attend plus à trouver un "get" qu'un "give" ?
Si je remplace tous mes "get" par des "give", je pense que ça va faire bizarre/que ça va déconcerter la personne qui va me relire
On est bien d'accord sur ce fait...
Pourtant, si on applique la logique des to, is, create, il semblerait logique d'effectivement remplacer tous les get par des give (ou provide )
Mais le problème du get n'est pas forcément la manière dont on nomme la fonction, tant que l'utilisateur comprend ce que fait la fonction, le problème est, surtout, de savoir s'il est opportun de donner un accès (fusse en lecture seule) à une donnée membre de la classe
Mais ca, c'est un autre débat
Et je suppose que c'est le même débat pour "set".
Pour rename(), c'est assez courrant mais pour setFont(), setSize(), qu'est-ce qui serait le plus adapté pour remplacer "set" ? "change" (ou "modify" ?
Ben, combien de fois vas tu modifier l'intégralité de la police de caractères
Généralement, tu vas plutôt soit changer la police, mais ni la taille ni les différents attributs (bold, italic, et autres), soit changer la taille, mais pas les autres attributs ni la police en elle-même, soit changer les attribut, mais ni la taille ni la police.
Je verrais donc d'un très bon oeil le fait d'avoir autant de fonctions qui correspondent à autant de service réellement attendus.
Maintenant, que tu les appelles addBold / removeBold ou modifyBold m'indiffère plus ou moins, tant que cela correspond à un service clairement défini
je dois avouer que tu m'as perdu. Tu peux préciser comment tu aurais écrit le code avec realloc ?
Ben... fais remonter l'erreur au cran de la fonction au dessus. Et pense à prévoir comment nettoyer, tout ça quoi.
Tu vois l'enfer ? C'est la plus belle démonstration que le simplisme du C n'en fait pas un langage dans lequel il est simple de développer. C'est pour ça aussi que je ressors régulièrement les exemples de l'article de Lahman qui a été traduit il y a peu.
Envoyé par Iradrille
a- Je trouve par contre bizarre de comparer C et C++, une comparaison Java et/ou C# vs C++ m'aurait semblé plus approprié (histoire de comparer des langages objets).
b- Sinon j'ai dans l'ensemble un avis contraire, je pense que le C est plus simple à prendre en main, le concept objet est quand même un gros morceau à apprendre. (Même si les avantages de l'objet en valent le coup )
c- Le C est un langage plus bas niveau et je pense que c'est une bonne chose quand on apprend : beaucoup moins d'abstraction, on sait exactement ce que le code qu'on écrit va faire (on pourrait presque en avoir une représentation en asm dans la tête, ce qui est bien plus dur en C++).
d- Les pointeurs, y a toujours une erreur possible faut vraiment faire gaffe mais là pas vraiment de différence entre C et C++.
e- Pour les std::string (et plus généralement la STL), c'est une répercution d'avoir un langage objet, une couche d'abstraction qui nous permet de ne pas nous soucier de la gestion de la mémoire car gérée en interne.
Ça permet de coder plus rapidement et de manière plus sure, et c'est évidement un gros avantage pour le C++.
e-
- le paradigme objet (ça peut sembler con, mais c'est une façon de penser complètement différente).
- déjà cité mais la gestion de la mémoire, qui est vraiment au cœur de ces 2 langages.
TL;DR: les avantages de l'objet sont indéniables mais c'est des principes pas forcément faciles à maîtriser, ce qui rend, selon moi, le C plus simple à appréhender.
a- C'est une comparaison qui ne vient pas de nous, mais de débutants qui la posent et demandent leur chemin de temps à autre, et bien plus souvent qu'on ne peut le croire.
b- Ecris des codes robustes aux erreurs et on en reparlera. Et maintenant enseigne des codes corrects et robustes aux débutants en C, et vois à faire la même chose, tout en restant en impératif en C++.
Quel est le langage qui permet d'enseigner correctement (pour montrer des choses justes et robustes et simples) ?
c- Je ne suis pas d'accord. Ada est un excellent langage d'apprentissage, de même que Pascal. Et pourtant ils fournissent des abstractions, non OO, pour les premiers pas -- OK, Pascal moins.
La SL fais parti du langage, ce n'est pas une annexe.
d- Dans une séquence d'apprentissage newbs-friendly, tu n'as pas besoin de perdre les étudiants dès le second chapitre avec les pointeurs en C++. On peut attendre le chapitre sur le polymorphisme pour le faire -- ou du moins le dernier moment avant les classes.
Je renvoie comme d'hab' à /je me lance/ de Francis Glassborrow qui est un bouquin d'initiation pour profil de non-informaticien/geek/technophile avec C++ comme langage support. Le livre n'aborde que la partie impérative du C++ et sa lib standard. Pas un mot (en fait si, une (seule) note de bas page) sur les pointeurs. Pas de classes à écrire, pas des templates à écrire.
Bref, pointeurs ? -> string, vector, RAII, shared_ptr<>, ... Une utilisation idiomatique du C++ utilise les pointeurs d'une façon radicalement différente de celle du C. Et on n'a pas le choix, les idiomes du C ne sont pas applicables à cause des exceptions. Heureusement pour nous le résultat fait que c'est plus facile de coder en C++.
e- Ce n'est pas le sujet. Ce n'est pas la question de "commencer OO ou impératif ?", mais de "C ou C++ pour commencer en impératif ?"
En attente de confirmation mail https://www.developpez.com
Le 22/01/2013 à 13:41
Envoyé par koala01
Il en va de même pour C++: il assume son héritage de C, il assume une certaine compatibilité avec celui-ci, mais il est totalement faut et restrictif de dire que C++ n'est "que du C amélioré".
C'est un langage totalement différent, qui apporte un grand nombre de possibilités totalement nouvelles par rapport au C et qui, surtout, est en mesure d'apporter une sécurisation beaucoup plus importante
+1 Mais on y est pas encore malheureusement.
Dans l'éducation, il est courant d'avoir des profs qui font apprendre le C avant d'aborder le C++ ou encore apprendre du C++ avec la libc et hop on se retrouve avec les deux directives pour inclure iostream et stdio.h et ça devient ni plus ni moins que du C avec un compilateur C++.
Ça fait bien longtemps que le synonyme C++ = "C with class" est obsolète et qu'il ne reste plus qu'un lien de parenté historique et une certaine compatibilité.
J'aimerais souligner que dans une filière scientifique, on aborde des aspects physiques en allant de modèles simples à complexes en retirant de nombreuses abstractions alors qu'en programmation on commence à aborder des aspects techniques bas-niveau avant d'en faire abstraction...
C'est du moins ce que j'ai pu constater durant ma scolarité scientifique (et non IT) et celles des autres.
En tout cas, mon avis est simple et stupide mais pas évident pour tout le monde :
Si tu veux faire du C, fait du C. Si tu veux faire du C++, fait du C++.
Faire du C pour faire du C++ a autant de sens que de faire du Java pour faire du C# (histoire de réveiller une fois encore une autre rivalité).
Mais, hors ce point qui n'est ici qu'un détail, ton code montre bien à quel point il est difficile d'éviter de faire des erreurs en C, surtout en période d'apprentissage.
Et cela confirme finalement le but général de l'article.
Pour rappel, il ne propose pas de ne pas apprendre C, il propose uniquement de ne pas l'apprendre "en prerequis à l'apprentissage de C++"
Bien sur, quelqu'un qui passe de C++ auras un gros effort de "mise à niveau" à faire pour passer à C, mais l'inverse est tout aussi vrai, et très certainement encore plus vrai au vu de l'approche historique qui consiste à envisager C comme un prérequis à l'apprentissage de C++.
Nous n'avons, comprenons nous bien, strictement rien contre le fait que quiconque apprenne le C, pour quelque raison que ce soit, sauf s'il le fait parce qu'il croit que cela lui facilitera les choses pour l'apprentissage de C++
Bonjour à tous
Comment pensez-vous que les différences d'approche entre le C et le C++ peuvent impacter leurs apprentissages respectifs ?
Envoyé par Taurre
), posons nous une deuxième question: quand faudra-t-il que celui qui apprend C s'intéresse au point précédent 
.
je dois avouer que tu m'as perdu. Tu peux préciser comment tu aurais écrit le code avec realloc ?