[formation] C et C++ ensemble ou séparé.

Bonjour à tous,

je commence a avoir un peu d'expérience en c++, et récemment j'ai eu des développeurs juniors sous ma responsabilité, qui devaient implémenter ce que j'avais conçu. Rien d'impressionnant, c'étaient des petits projets, mais je me suis un peu énervé car leur code était très instable à cause des char* et autres int[] - sans parler des void* - qu'il y avait dans leur code. Je n'ai pas voulu faire l'intégriste dès le début et je les ai laissé faire. Du coup on a perdu beaucoup de temps en debug.

Du coup j'en ai discuté avec pas mal de collègues, et mon point de vue est: "lors de la formation, il faut absolument insister sur le fait que C et C++ sont des langages différents et insister sur ces différences". Mais ici, en Espagne, peu de gens sont d'accord avec moi. Pour eux, puisque ces deux langages sont quasiment pareil, il n'est pas nécessaire de l'enseigner séparément, ce serait une perte de temps etc.

Et du coup, je suis un peu à cours d'arguments. Sauriez-vous m'aider à répandre la bonne parole? :aie:

J'insiste sur le fait que la discussion porte sur la formation (universitaire ou professionnelle).

Salut,
Déjà, je suis parfaitement d'accord avec toi. Un des arguments, c'est que le C est extrêmement limité par rapport au C++: Beaucoup de choses "propres" en C ne paraissent propres que parce qu'on n'a pas le choix, mais horriblement sales dans les autres langages.

Avec le C, on met les mains dans le cambouis. Avec le C++, on a droit à des gants, et ne pas les utiliser relève d'un manque de compétence.

Citation:

---

Pour eux, puisque ces deux langages sont quasiment pareil, il n'est pas nécessaire de l'enseigner séparément, ce serait une perte de temps etc.

---

Ca me semble la base du problème. Avant de les convaincre qu'il faut les enseigner séparément, il faut les convaincre que ce sont deux langages différents.

A ce titre, quelques exemples de programmes simples, avec un code C, un code C++, peuvent aider.

Bonjours,
Je suis convaincu qu'on ne devrai pas apprendre le C et le C++ ensemble. Justement pour éviter, en C++, l'usage de tout ses truc hérités du C et pas forcement pertinent en C++.(les pointeurs nus, les tableaux, les cast, les malloc/free bêtement remplacé par new/delete, les void*, etc...)

En même temps il n'est pas facile de faire comprendre a un programmeur "C with class" que ce qu'il fait n'est pas du C++.

En revanche, je constate que les programmeurs sont très réceptifs a tout se qui peut leur simplifier la vie. Et donc ce qui marche c'est de leur montrer qu'elle sont les méthodes C++ qui vont bien pour remplacer les méthodes C, en leur expliquant bien les avantages. Ils y sont d'autant plus réceptifs après avoir passé deux heurs a chercher un bug.

Exemple: Un développeur a passé l'après midi a chercher un bug, pour se rendre compte qu'on écrivait dans un tableau a un index hors limite...
La tu lui dit: "Tu vois, avec un vector, il y aurais eu une assertion fausse, et donc localisation immédiate du bug".
Ben la t'es sur qu'il a retenu la leçon ;)

Et puis aussi je pense qu'il ne faut pas tout leurs dire d'un coup. Bien codder en C++ ne s'apprend pas en trois jours.

À mon avis, le plus simple pour faire comprendre aux utilisateurs la différence: La saisie de lignes de texte de longueur arbitraire.

• C: Une boucle impliquant des fgets ou getc, avec au moins un realloc quelque part (sous Visual, histoire de ne pas avoir la fonction helper non-standard de gcc).
• C++: std::getline().

Je ne suis qu'à moitié d'accord avec vous.

Citation:

---

Envoyé par Médinoc

Avec le C, on met les mains dans le cambouis. Avec le C++, on a droit à des gants, et ne pas les utiliser relève d'un manque de compétence.

---

Ou un manque de compétence du prof qui n'a pas su enseigner...

J'ai appris les deux à une semaine d'intervalle il y a très longtemps. D'abord le C, puis le C++ en temps qu'extension du premier. On n'a pas vu les exceptions, ni la STL. On a à peine parlé des templates et de la surcharge des operators. L'accent était mis sur la POO et le polymorphisme.

Par la suite, en entreprise j'ai constaté que les autres informaticiens étaient à peu près au même stade de connaissance en C++. A l'époque on se batait surtout à contourner les bugs des compilateurs Borland et de leur framework BWC (ou BCW, j'sais plus). A la mort de Borland, ce fut la migration vers Visual Studio qui fut pénible. Sans parler de la migration 16 vers 32 bits, les problèmes de compatibilté entre compilos C++ à cause d'un manque de normalisation formelle (ce n'est qu'en 1998 qu'intervient la première norme offcielle du C++, non ? Avant on suivait ou pas les recommantions de Barj S.).

Aujoud'hui, C++ est délaissé par C#, Java, flash, et tous les brols interprétés. Et je le comprends, c'est bien plus productif.

@Camboui, c'est justement des profs qu'on discute ici. ;)

Je suis 200% d'accord sur le fait que C++ et C sont différents. Et même plutôt que de se poser la question de savoir s'il faut les enseigner séparément (ce qui est une évidence pour moi), il faut déjà se poser la question : "Doit-on enseigner les deux ?"

S'il y a des domaines où la connaissance du C est assez indispensable, il y en a à mon avis une majorité où l'on peut totalement la passer sous silence, et apprendre dès le début un C++ "procédural", mais qui utilise déjà les types qu'on utilise tous les jours, string et vector, en particulier.

Ensuite, si on est dans un cas où les deux sont nécessaires, la question se pose de savoir dans quel ordre les enseigner. Si j'avais mon mot à dire sur ce sujet, je dirais de commencer par le C++, du moins un sous ensemble (en gros, on peut s'arrêter au moment où on défini des types utilisateurs), et de finir par le C, ce dernier étant plus compliqué d'utilisation, on respecte ainsi mieux une progressivité d'apprentissage.

Maintenant, sur la manière de convaincre tes interlocuteurs, j'avoue que je n'ai pas trop d'idées. Peut-être peux-tu leur citer l'existence de personnes qui se débrouillent en C++, mais seraient incapables de faire un quelconque programme en C, car ne connaissant de ce langage que ce qui est nécessaire pour s'interfacer avec (j'en suis un exemple).

Peux-être peux-tu leur parler de livres qui enseignent le C++ directement, sans parler de C (accelerated C++, par exemple, le dernier livre de Stroustrup aussi, probablement, ou bien celui de Francis Glassborrow ("je me lance" en français le titre, je crois)).

Peut-être peux-tu leur dire que de toute façon, Espagnol et Catalan, c'est la même chose, et donc qu'on pourrait enseigner les deux ensemble à l'école, ça éviterai de perdre du temps (mmm, pas certain que ce soit une bonne idée, ça ;) )

Merci à tous pour vos réponses. J'ai d'ailleurs commencé la rédaction d'un papier (en espagnol) à ce sujet. Comme ça, à chaque fois que je devrais m'expliquer, je renverrai vers ce papier... on appelle ça optimisation non? ;)

Citation:

---

Envoyé par JolyLoic

Maintenant, sur la manière de convaincre tes interlocuteurs, j'avoue que je n'ai pas trop d'idées. Peut-être peux-tu leur citer l'existence de personnes qui se débrouillent en C++, mais seraient incapables de faire un quelconque programme en C, car ne connaissant de ce langage que ce qui est nécessaire pour s'interfacer avec (j'en suis un exemple).

---

J'en suis aussi :oops:
Mais cet argument s'est retourné contre moi récemment: on avait un client qui voulait absolument qu'on utilise log4c (des fois faut pas chercher, le client est roi...), et lorsque j'ai commencé à poser des questions sur des morceaux de code en C que je ne comprenais pas bien, ils ont sauté sur l'occasion et m'ont dit, en substance: "ha ben tu vois, ça arrive souvent de devoir utiliser des libs C, c'est donc une bonne chose de connaître les deux". S'ensuivit une discussion interminable sur le fait qu'effectivement, il est bien de connaître les deux, mais que ça n'a rien à voir avec la discussion sur la formation, etc...

Citation:

---

Envoyé par JolyLoic

Peut-être peux-tu leur dire que de toute façon, Espagnol et Catalan, c'est la même chose, et donc qu'on pourrait enseigner les deux ensemble à l'école, ça éviterai de perdre du temps (mmm, pas certain que ce soit une bonne idée, ça ;) )

---

Héhéhé, bonne idée, je vais le tenter :ccool:
Mais bon, le potentiel trollesque des espagnols est (encore) plus élevé que celui des francophones. Et là, j'ai bien peur que la seule allusion au catalan/castillan n'ouvre trop la vanne "trollifère". Mais je vais le tenter :mouarf:

C'est un sujet courant au final. Et plus ça va plus je me rends compte que finalement les développeurs C++ moderne (par opposition a historique j'entends) sont pas monnaie courante. (en tout cas pas en majorité amha).
L'histoire que tu racontais est a mon avis a elle seule l'argument le plus convaincant, c'est à dire que quand ils ont le nez dans la mer** leur dire, tu vois ça sent pas bon au final, maintenant laisse moi te montré les bons outils.
Mais le problème c'est que c'est une trop grosse perte de temps, donc le problème revient à l'enseignement. Et là... ben c'est pas gagné, vu que les profs (dans la majorité?) non même pas entendu parler de la SL ou pense que c'est une bizarrerie inventé par des universitaires boutonneux. (pas sympa pour notre ami stepanov :p).
Le problème c'est que du coup sa renforce la """chute""" (vraiment entre guillemets) du C++ aux yeux des patrons, si les jeunes savent pas ou savent mal, à quoi bon.

Citation:

---

Maintenant, sur la manière de convaincre tes interlocuteurs, j'avoue que je n'ai pas trop d'idées. Peut-être peux-tu leur citer l'existence de personnes qui se débrouillent en C++, mais seraient incapables de faire un quelconque programme en C, car ne connaissant de ce langage que ce qui est nécessaire pour s'interfacer avec (j'en suis un exemple).

---

Un autre :p. (c'est moins vrai maintenant).

Quand à l'apprentissage, je suis partisan du commencé par le C++, et revenir sur du C plus tard si besoin il y'a. (les profs devraient prendre comme bouquin de référence un de ceux cité par Loic.)


Enfin un dernier truc, mais qui est au final a la base de l'amalgame qui est fait, cette appellation de C/C++. Combien de fois j'ai repris des gens sur : Non C ET C++ pas un mix des deux. Et combien de fois derrière j'ai du expliqué pendant dix minutes pourquoi c'était pas les mêmes langages et pourquoi c'était mal de les assimiler (parfois en vain d'ailleurs).

Citation:

---

Envoyé par Goten

Et combien de fois derrière j'ai du expliqué pendant dix minutes pourquoi c'était pas les mêmes langages et pourquoi c'était mal de les assimiler (parfois en vain d'ailleurs).

---

Et, au risque d'abuser un peu :oops: comment t'y prendrais-tu pour expliquer cela. Par exemple, si tu tombes sur quelqu'un qui te dit:
"Ben oui, moi j'utilise des char*, parce que c'est comme ça que j'ai appris et maintenant je le maitrise, alors que la classe string je ne la connais pas et au final, je n'en ai pas besoin"

Je pense que string est un mauvais exemple, car elle n'a pas assez de défauts (à part l'absence de méthode GetBuffer()). Je te conseillerais plutôt les streams, pour lesquels il est beaucoup plus dur de convaincre (en dehors de getline()).

A vraie dire, je suis tout sauf un bon pédagogue... j'ai donc tendance a m'énerver assez vite et a renvoyer le terlocuteur dans les cordes =).
Pour l'expliquer... c'est là que c'est dur. Et ça dépend fortement de a qui je m'adresse. Si je m'adresse à un gars qui a fait un peu de C, connait le C++ de nom, en général c'est perdu d'avance / pas facile du tout. Pourquoi? parce que les arguments que j'ai sont techniques et prennent des exemples du C, celui qu'a cité medinoc est un que j'utilise assez souvent, plus généralement j'aime exposer la classe string.
Quand je m'adresse à quelqu'un qui n'a fait que du C en général c'est pas forcément compliqué (même si dans ce cas là ce genre de profil aime le C et veut y rester). Et après y'a le profil qui fait du C/C++ (ou C with classes ou peu importe le nom) et là c'est pas facile du tout. La difficulté étant proportiennelle aux connaissances du gars dans ce mix. (ie si il en fait beaucoup, souvent et qu'en plus il s'en sort pas trop mal niveau entretien, ben va falloir sortir l'artillerie lourde).
Donc désolé j'ai pas de recette miracle. Le problème en fait c'est de convaincre les gars que ce qu'ils font n'est pas bon alors qu'ils n'ont pas forcément eu des pépins majeurs jusqu'à présent. (si tu dis au gars ouai mais là ça risque de te péter a la gueule et qu'il te dit, non non ça m'est jamais arrivé... ça peut duré longtemps).

Mais ton exemple va être ressorti sur la table au cour de ce genre de discussion à l'avenir :p.

Mais même pour les char*, le gars s'en sortirait mieux avec un vector<char> qu'avec un char* normal, donc on revient au C++.

On est d'accord entre nous pas de soucis. L'expliqué après c'est une autre pair de manche. enfin par expliqué j'entends convaincre.

Pour moi l'argument massue reste le RAII.

Le problème, c'est que Resource Acquisition Is Initialization ne veut rien dire pour moi, et je n'en vois pas l'intéret.
Si tu l'appelles Resource Release Is Finalization (ou mieux, dit dans l'autre sens) par contre, c'est là que ça prend tout son intérêt...

En clair, le nom ne lui fait vraiment pas justice. On se fout du constructeur, c'est le destructeur qui est important!
(enfin d'accord, il y a aussi le constructeur de copie)

Oui le terme des RAII est peu explicite, je te l'accorde. D'ailleurs il y'a une autre abbréviation que je trouve plus explicite même que RRIF. Mais je la bouffe tout le temps, elle commence en Scope et y'a du bound dedans mais impossible de retrouvé.
Bref le concept reste et c'est lui qui est important.

Un étudiant :

A mon avis, il est aussi faux de les dissocier que de les associer. Le c++: c'est ""juste"" du c orienté objet, avec une couche de "conventionalisme" très efficace. Le problème, c'est que souvent les formations passe du coq à l'âne... Du coup, le c++ devient un vieux truc hybride entre le java et le c >< !

Ce que je te propose est un exercice beaucoup plus dur : du C (vraiment c) orienté objet. C'est pas une mince affaire; mais là, ça fait méchamment réfléchir à la différence C/C++.

Après, reste à prouvé l'efficacité des conventions (c'est pas mince non plus). A mon avis, le mieux, c'est d'essayer de leur faire maintenir/évoluer un programme c++ porcasse (l'un le code, l'autre l'explique), et l'autre en vrai c++.

Qu'est-ce que t'en penses ?

Pourquoi serait-ce faux de les dissocier ? Je serais curieux d'entendre tes arguments contre la dissociation :p.
Après tout si on fait une analogie (bancale) avec le français et l'espagnol, ce sont deux langues latines et pourtant... ben n'importe quel français ne parle pas espagnol (et ce même juste un peu ou mélangé).
En gros : je vois pas quel mal il peut y'avoir a les dissocier.
D'ailleurs je suis pas plus d'accord avec le reste, pour moi il faut justement sortir de cette idée préconçu de : le C++ n'est que du C a qui on a rajouté le paradigme objet. Non, ça c'était vraie avec le C with classes, ça ne l'est plus maintenant.

Il y a(vait) des compilateurs C++ qui générait du code C. Je n'ai jamais entendu parler de compilateur C qui générait du code C++...

Citation:

---

Envoyé par camboui

Il y a(vait) des compilateurs C++ qui générait du code C. Je n'ai jamais entendu parler de compilateur C qui générait du code C++...

---

Ça ne veut rien dire (ou alors, comme il existe des compilateurs C++ qui génère du langage machine, le C++ n'est rien d'autre qu'un langage machine ?). On peut faire un compilateur Java ou Python ou Ruby ou... qui génère du code C. Quand un langage commence son existence, c'est d'ailleurs une assez bonne idée de le compiler vers du C, car de nos jours le C peut être considéré comme un assembleur, mais portable. A partir du moment où on a généré du C, on est compatible avec des dizaines d'architectures.

A mon avis, partir de l'argument "C et C++ ce sont deux langages différents", si tout le milieu dit le contraire, ou expliquer que "les pointeurs c'est pas bien" à des gens qui sont fiers de les maitriser enfin, ce n'est pas une bonne idée!

Quand au RAII et autres arguments théoriques, ca ne convainc que ceux qui sont déjà convaincus.

Personnellement, j'éviterais le débat, et je commencerais par montrer les avantages du C++ en tant que raccourcis d'écriture (tu parleras des avantages en terme de stabilité après).

Donc, montrer comment les stream remplacent avantageusement les printf, comment les new c'est drolement mieux que les malloc, et tant qu'on y est comment les vecteurs c'est mieux que les new... Puis passer à la STL et quelques trucs sympas (les paires, les complexes s'ils font des maths, les algos les plus courants comme find, ou sort, ou merge). Et puis les set et les map, parce que ca change la vie du programmeur C.

C'est un peu la méthode suivie par Accelerated C++, c'est bien plus pédagogique que les arguments théoriques à la française, et c'est directement utile. (c'est aussi un peu ce que fait Stroustrup dans ses bouquins)

Après, si tes étudiants veulent toujours croire que c'est une extension du C, c'est leur affaire, du moment qu'ils écrivent du bon C++.

Francois

Citation:

---

Envoyé par Goten

Mais le problème c'est que c'est une trop grosse perte de temps, donc le problème revient à l'enseignement. Et là... ben c'est pas gagné, vu que les profs (dans la majorité?) non même pas entendu parler de la SL ou pense que c'est une bizarrerie inventé par des universitaires boutonneux. (pas sympa pour notre ami stepanov :p).

---

C'est étrange d'entendre dire que des profs négligent une chose parce qu'ils la considèrent comme trop universitaire :)

Mon expérience est plutôt que les cursus (du moins ceux que je côtoie, c'est à dire écoles d'ingénieurs françaises) négligent totalement l'apprentissage d'un langage, car justement, c'est trop pratique, trop appliqué, pas assez universitaire (et certains profs négligent la mise en pratique du code, considérant que seule l'algorithmique est une activité noble dans leur travail).

Là où j'enseigne, j'ai 9 séances d'1h30 pour parler de C++, alors qu'il y a 18 séances sur les réseaux de neurone, 18 sur les actionneurs électriques, 24 sur les microprocesseurs et électronique associée.

Je trouve ça une peu court, et j'ai bien du mal à faire quelquechose d'un minimum complet et cohérent.

Par contre, une chose est claire, il y a std::string dans les premières 5 minutes du cours, std::vector et std::map arrivent assez vite après. Et je n'ai pas le temps de parler de char* ou new[] (en fait, j'en parle mais uniquement avec les élèves qui amènent d'eux même le sujet parce qu'ils ont des connaissances en C). Et je parle plus globalement des problématiques de gestion de la mémoire, mais je prend un exemple avec un simple new (et j'essaye à ce moment d'introduire les smart ptr, même si je suis certains que tous ne suivent pas).

Citation:

---

Envoyé par Goten

Le problème c'est que du coup sa renforce la """chute""" (vraiment entre guillemets) du C++ aux yeux des patrons, si les jeunes savent pas ou savent mal, à quoi bon.

---

C'est pour moi un des principaux problèmes du C++ pour l'industrie, et ça risque de tuer le langage : Il est difficile de recruter quelqu'un de compétent en C++.

Citation:

---

Envoyé par r0d

Et, au risque d'abuser un peu :oops: comment t'y prendrais-tu pour expliquer cela. Par exemple, si tu tombes sur quelqu'un qui te dit:
"Ben oui, moi j'utilise des char*, parce que c'est comme ça que j'ai appris et maintenant je le maitrise, alors que la classe string je ne la connais pas et au final, je n'en ai pas besoin"

---

Demande lui d'écrire 2 programmes.

Le premier demande simplement son nom à quelqu'un, puis écrit "Bonjour, Machin". C'est ce qui vient juste après un hello world en terme de complexité. Je suis persuadé que nombre de développeurs "char*" vont l'écrire avec une taille maximale, je t'invite donc à le faire planter... Et ceux qui ne le font pas vont avoir un programme qui fait plus que les 2 lignes nécessaires.

Ensuite, demande leur d'écrire un programme à qui on passe un texte et qui compte le nombre d'occurrence de chaque mot. Là encore, c'est 5 lignes avec un map<string, int>. Faire la même chose sans map et sans string, je n'ose pas imaginer.

Citation:

---

Envoyé par Médinoc

Je pense que string est un mauvais exemple, car elle n'a pas assez de défauts (à part l'absence de méthode GetBuffer()). Je te conseillerais plutôt les streams, pour lesquels il est beaucoup plus dur de convaincre (en dehors de getline()).

---

Je ne suis pas certain de voir où tu veux en venir.

En tout cas (mais est-ce que je suis le seul ?), je trouve les flux bien plus simples que les printf : Déjà, pas de syntaxe tordue à retenir quand on veut simplement afficher sans mise en forme particulière. Rien que ça, j'aime. Pas de risques d'erreurs, même quand un type change, prise en compte des types utilisateurs... La seule chose qu'il n'a pas (mais printf non plus, je crois, sauf extension) c'est la prise en compte de paramètres positionnels (et les performances...). Là, il faut recourir à boost::format.

Salut,

Je n'ai lu qu'une grosse partie des interventions, mais, si je peux me permettre, je vais parler un peu de mon vécu récent:

J'ai eu des cours de C mélangés avec le cours d'algorithmique, car il fallait bien que les élèves puissent tester leurs algo (au grand désespoir du prof qui aurait préféré nous apprendre pascal), puis des cours de C++ (avec un autre prof :P) pour nous apprendre la POO...

Evidemment, c'était un prof qui nous apprenait encore le C++ de manière "historique" (comprenez: sous la forme de C with class :aie:), et, comme j'ai une grande g...le et que je connaissait la S(T)L, je faisais remarquer, chaque fois qu'il utilisait un char* pour représenter une chaine ou qu'il avait recours à un Type* + new[] / delete[] pour représenter un tableau qu'il serait possible de faire bien plus simplement avec respectivement std::string et vector.

(J'en ai profité pour lui rappeler qu'il n'était pas "logique" de provoquer un affichage + saisie dans le constructeur ( re :aie: ) )

Par chance, le prof m'aimait bien, car, à chaque fois qu'il présentait un code en C with class de 15 lignes, je faisais quelque chose de similaire (en C++ / S(T)L) en 10, si pas en 5...(un autre aurait pu en prendre hombrage)

Et bien souvent, mon code était non seulement plus sécurisé mais aussi plus rapide que le sien (pourtant, il veillait à "blinder" son code (re re :aie:) )

A la fin de l'année (après qu'il se soit quand même un peu intéressé à la S(T)L), il m'a demandé comment il pourrait réorganiser son cours pour apprendre aux suivants les "bonnes" pratiques.

Je lui ai conseillé de commencer son cours par "vous avez appris le C, c'est très bien: il vous sera peut être utile, mais maintenant, vous devez tout oublier, parce qu'on va parler C++, et que c'est un autre langage", et de donner directement les classes string et vector (en plus de cin et cout, cela va de soi), quitte à ne pas passer en revue l'ensemble de leurs fonctions membres, mais uniquement celles qui sont le plus régulièrement utilisées, et de n'aborder la gestion dynamique de la mémoire avec new( [] ) / delete( [] ) que lorsque cela devient indispensable: lorsqu'on parle d'héritage et de collections d'objets polymorphes.

Tout cela pour dire que je rejoins l'avis généralement émis (me semble-t-il du moins) selon lequel la connaissance des deux langages est importantes, mais aussi que, selon moi, les deux devraient être appris de manière strictement autonome (ce qui n'empêche pas d'apprendre les deux conjointement, pour autant que ce soient vraiment deux cours clairement séparés ;)).

Et, à ceux qui font valoir que "c'est quasiment la même chose", j'aurais tendance à objecter que tous les entiers sont des réels, et que "c'est quasiment la même chose" aussi, étant donné que ce sont... des nombres...

Comme ils risquent fort de s'écrier qu'il est illogique de considérer les réels comme s'il s'agissait d'entiers sous prétexte que c'est "quasiment la même chose", il devient facile d'argumenter qu'il en va de même pour le C++ ;) (je sais, c'est une comparaison à la c... mais c'est celles qui marchent le mieux :D)

[EDIT]En fait, l'idée que j'essaye de faire passer, c'est que, si on prend n'importe quel domaine, il est "facile" de trouver quelque chose qui est "quasiment identique" à autre chose, mais qu'il est illogique de vouloir apprendre comme cette autre chose...

Si les gens admettent (et ils y seront presque forcés) l'illogisme qu'il y a à apprendre cette chose comme s'il s'agissait de l'autre sous prétexte que c'est "quasiment la même chose", il devient facile de faire valoir qu'il en va de même entre C et C++ ;)

Citation:

---

Envoyé par fcharton

A mon avis, partir de l'argument "C et C++ ce sont deux langages différents", si tout le milieu dit le contraire, ou expliquer que "les pointeurs c'est pas bien" à des gens qui sont fiers de les maitriser enfin, ce n'est pas une bonne idée!

---

Mais l'argument n'est pas "les pointeurs c'est pas bien"! C'est "les pointeurs, c'est mieux quand tu n'as pas à t'en occuper."
Il faut montrer aux gens qu'ils se facilitent la vie en implémentant une classe RRIF (ou en utilisant des pointeurs intelligents existants) plutôt que d'utiliser des pointeurs nus!

Citation:

---

Envoyé par fcharton

Quand au RAII et autres arguments théoriques, ca ne convainc que ceux qui sont déjà convaincus.
...
et tant qu'on y est comment les vecteurs c'est mieux que les new...

---

Pour moi, tout l'intérêt des vecteur et des string (notamment) c'est qu'ils gèrent l'acquisition de ressources (et leur libération). C'est l'exemple le plus frappant de RAII/RRIF.

Citation:

---

Envoyé par medinoc

Le problème, c'est que Resource Acquisition Is Initialization ne veut rien dire pour moi, et je n'en vois pas l'intéret.
Si tu l'appelles Resource Release Is Finalization (ou mieux, dit dans l'autre sens) par contre, c'est là que ça prend tout son intérêt...

---

Je suis d'accord avec toi que le sens commun donné à RAII est mieux exprimé par RRIF. Personnellement, je donne un autre sens à RAII: le fait qu'à l'initialisation, l'objet est exploitable.

Par exemple pour les fstream, j'utilise systématiquement la construction prenant le nom du fichier en paramètre, mon objet est donc directement exploitable (je peux écrire dedans sans provoquer une erreur).

Citation:

---

Envoyé par CedricMocquillon

Pour moi, tout l'intérêt des vecteur et des string (notamment) c'est qu'ils gèrent l'acquisition de ressources (et leur libération). C'est l'exemple le plus frappant de RAII/RRIF.

---

Je doute de l'efficacité de cet argument au début de l'enseignement du C++.

A mon avis, la bonne façon d'enseigner le C++, c'est de montrer qu'il permet d'écrire rapidement du code assez avancé, et pourtant rapide. Les détails relatifs à la gestion de la mémoire, des exceptions, et tous les trucs compliqués que fait la STL, on peut en parler, mais après.

Un langage, c'est un outil, ce qui intéresse l'étudiant, en premier lieu, c'est ce qu'il peu faire avec.


La mauvaise façon de l'enseigner, c'est de commencer par la liste des "interdits" (et des catastrophes qui peuvent se produire), et d'introduire le langage comme la solution à ces problèmes. Ce n'est pas intéressant, ça rebute les élèves, et c'est comme ca qu'on soigne la mauvaise image du C++ (langage gratuitement abstrait, affreusement compliqué ou spécialement conçu pour autistes...)

Mais c'est un travers très français de toujours commencer l'enseignement par le petit bout abstrait de la théorie...


Quant à l'utilité des string et des vector, pour moi, c'est le fait que cela simplifie le code. Leur inconvénient, c'est la vitesse... (leur amour immodéré pour la recopie, et dans le cas des vecteurs, leur incapacité à réduire leur taille mémoire)

Citation:

---

Envoyé par CedricMocquillon

Par exemple pour les fstream, j'utilise systématiquement la construction prenant le nom du fichier en paramètre, mon objet est donc directement exploitable (je peux écrire dedans sans provoquer une erreur).

---

Quand il s'agit de fichiers, je préfère écrire mes open() et mes close(), qui servent de documentation de mon code. Le risque d'écrire dans un fichier non ouvert me parait très faible. Dans des programmes de traitement, qui utilisent de gros volumes de données, j'écris aussi mes new et mes delete explicitement, ce qui me permet de savoir précisément où j'utilise mes ressources. Quand il faut se relire, six mois plus tard, ça aide énormément...

Ceci dit, je viens de passer plusieurs jours à éliminer quasiment tous les appels aux fstream de mon programme. Sur de gros fichiers, c'est d'une lenteur ridicule... (avec STLPort c'était encore acceptable pour de petits fichiers, mais avec le Dinkumware que j'ai aujourd'hui, c'est absurde)

Francois

L'autre problème du terme "RAII", c'est qu'un constructeur a tendance à signaler un échec par une exception.
Et je peux te garantir, par expérience, que pour un type qui vient du C, les exceptions, ça fait peur. À l'époque où j'ai commencé java, tous mes codes contenaient des wrappers pour attraper les exceptions des classes standard et retourner un code d'erreur à la place...

Je me risquerai à conseiller (quoique je n'aie guère de titre à faire le "conseilleur" en ce domaine...) à chaque professeur de C++ de lire et de faire lire le remarquable ouvrage récent de Bjarne Stroustrup, ouvrage qui est à lui seul une sorte de vaste réponse à la question posée par ce fil :
Programming - Principles and practise using C++

(Dans ce livre du reste BS ne fait pas l'impasse complète sur le sous-ensemble C du C++, mais il l'aborde dans le chapitre numéro ... 27 !!)

EDIT C est plutôt (au moins grosso modo) un sous-ensemble du C++ (plutôt qu'un "langage différent"), un outil disponible en C++ à n'utiliser que quand on en a vraiment besoin, pour l'interopérabilité ou peut-être dans quelques cas où l'on veut travailler à très bas niveau, mais certainement pas l'outil par défaut.

Un document que j'aime bien ce sont les cours et tutoriels pour apprendre la programmation C++ : http://cpp.developpez.com/cours/.

Je pense que à l'inverse de java où il est difficile d'utiliser les connaissance acquise en C, C++ laisse cette porte grandement ouverte, ce qui engendres des mélange. Je pense donc que le langage C devrait être enseigner pour comprendre la logique qui permet à un langage de fonctionner. À l'inverse un cours de C++ devrait beaucoup porter sur l'aspect orienté objet, et sur l'API, et ne devrait pas être un cours de C avec la couche objet en plus.

Je vient de penser a un argument intéressant, pour prouver que les deux langage ne peuvent pas être confondue.
Supposons qu'on ait en C le code suivant:

Code:

---

1 2 3 4 5

int *intTab = malloc(500 * sizeof(int)); if(intTab == NULL) return; uneFonctionQuiPeutEchouer(intTab); free(intTab);

---

La conversion brutale(et très courante) en "C with class" serais:

Code:

---

1 2 3 4 5

int *intTab = new int[500]; if(intTab == NULL) return; uneFonctionQuiPeutEchouer(intTab); delete[] intTab;

---

Première chose: le test == NULL n'as pas d'intérêt vu que new renvoie une exception.(sauf avec Borland et Visual 6, qui ont grandement contribué a cette mauvaise habitude)
Deuxième chose, une fonction qui échoue en C++ lancera généralement une exception, et donc la il y as fuite mémoire. La version avec RAII règle ce problème:

Code:

---

1 2	vector<int> intTab(500); uneFonctionQuiPeutEchouer(intTab);

---

Si les cours sont donnée avec un compilateur qui gère les erreur d'allocation par une exception(comme gcc ou un Visual récent par exemple), la démonstration et vite faite car nimporte quel allocation sur le tas peut lancer une exception, et donc new/delete sans RAII = fuite mémoire.

Je crois que tu peux préciser "visual 6", car il y a au moins la version 2005 qui marche correctement.

Je pense qu'il faut apprendre les 2 dès lors qu'on souhaite étudier et faire du C++ pour la simple raison que le C est a peu près partout et que un jour ou l'autre un code C++ devra s'interfacer avec du C (ce qui a été mentionné ici plusieurs fois).

Par contre, un truc important selon moi, il faut commencer l'apprentissage par le C++ : simplement parce qu'il est plus aisé de faire des choses simples en C++ qu'en C.

Bon, je dis ça, je dis rien. Je connais un peu le C++ mais je suis incapable de faire du C, du vrai (avec les variables en haut des scopes et tout le bordel).

Finalement, je pense que tout développeur un tant soit peu sérieux devrait connaitre ne serait-ce qu'un peu de C ou un partie du subset C du C++: avoir des notions d'adressage, de pointers, de déréférence et ce genre de conneries pour non seulement briller en société, à l'occasion, pourquoi pas, d'accord, mais surtout pour réaliser que toute chose a un cout et qu'il n'y a rien de magique en informatique.

Citation:

---

Envoyé par Médinoc

À mon avis, le plus simple pour faire comprendre aux utilisateurs la différence: La saisie de lignes de texte de longueur arbitraire.

• C: Une boucle impliquant des fgets ou getc, avec au moins un realloc quelque part (sous Visual, histoire de ne pas avoir la fonction helper non-standard de gcc).
• C++: std::getline().

---

On en revient à l'article de Stroustrup relativement au C++ qui devrait être enseigné comme un langage à part entière.

Citation:

---

Envoyé par r0d

Et, au risque d'abuser un peu :oops: comment t'y prendrais-tu pour expliquer cela. Par exemple, si tu tombes sur quelqu'un qui te dit:
"Ben oui, moi j'utilise des char*, parce que c'est comme ça que j'ai appris et maintenant je le maitrise, alors que la classe string je ne la connais pas et au final, je n'en ai pas besoin"

---

Les chemins non nominaux sont la chose qui fait toute la différence. Ca, et les stagiares, les lendemains de bitu^Wsoirée, les jemenfoutistes non perfectionnistes, etc qui ne sauront pas maintenir correctement du code où les ressources sont maintenues avec de l'huile de coude.

Mais comme le dit fcharton, il faut être plus pragmatique et leur montrer que leur vie sera plus facile avec ces petits trucs intégrés incrémentalement.

Citation:

---

Envoyé par ptyxs

EDIT C est plutôt (au moins grosso modo) un sous-ensemble du C++ (plutôt qu'un "langage différent"), un outil disponible en C++ à n'utiliser que quand on en a vraiment besoin, pour l'interopérabilité ou peut-être dans quelques cas où l'on veut travailler à très bas niveau, mais certainement pas l'outil par défaut.

---

Pas vraiment : le C et le C++ sont deux langages ayant une partie "commune" (ou, pour être plus précis, une partie commune dans leur grammaire respective), mais tu as des éléments C totalement incompatibles avec le C++, et réciproquement. De plus, du C compilé en C++ (même en restant dans ce sous-ensemble) n'est PAS du C, mais bien du C++ : c'est l'ABI du C++ qui est utilisée par défaut, interdisant le plus souvent la moindre édition de liens au sein d'un "vrai" programme C.

Travailler dans le sous-ensemble commun aux deux langages peut avoir un intérêt de portabilité toutefois : classiquement, c'est très pratique pour les interfaces (structures, déclarations, constantes, etc.) entre un système C++ (un PC par exemple) et un système C (souvent un truc embarqué), notamment lorsque l'on passe par un réseau.
Cela permet d'avoir les mêmes fichiers, souvent sans même une seule ligne de compilation conditionnelle, et donc d'assurer que le code n'est pas dupliqué (coût de maintenance), ni incohérent (plus de communication et/ou régressions).

En dehors de ce cas de figure très particulier, et que beaucoup d'entre vous ne feront jamais d'ailleurs, ce n'est pas forcément une bonne idée de trop mélanger les deux langages.
Il ne faut pas non plus bannir systématiquement la programmation procédurale en C++ pour autant, ni refuser toute programmation orientée objet en C, mais il faut quand même s'en tenir au langage.

Citation:

---

Envoyé par Fmunch

<snip>
Je pense donc que le langage C devrait être enseigner pour comprendre la logique qui permet à un langage de fonctionner.
<snip>

---

Je ne suis pas d'accord avec cela...

En dehors de tout problème de syntaxe, voire de grammaire, propre au C (ou au C++ d'ailleurs), il existe un "tronc commun" à l'ensemble des langage dits "procéduraux" (ce qui comprend aussi les langages OO;))

Les boucles, les tests, les fonctions, et même les concepts de pile, de file, de liste (simplement / doublement) chainées se retrouvent dans tous les langages de ce type...

Si le but est, simplement, de permettre à l'élève de comprendre la logique qui permet à un langage de fonctionner, autant le lui apprendre avec un pseudo code "maison", et pourtant je n'ai jamais caché tout le mal que je pense de cette pratique.

Si tu dis que le C est intéressant pour permettre à l'élève de "tester la logique" qu'il a mise au point, je suis déjà un peu plus d'accord, bien que j'estime à titre personnel que d'autres langages procéduraux seraient plus faciles dans ce but particulier.

Par contre, j'estime aussi qu'un bon programmeur doit au minimum connaitre (quitte à ne pas les aimer ni les maitriser entièrement) plusieurs langages, ne serait-ce que pour "le cas où"...

A ce titre, une connaissance minimale du C fait, à mon sens, partie du "bagage" obligatoire de tout programmeur, au même titre que Java ou C# (et pourquoi pas ASP ou PHP dans certains domaines ;)), quitte à ce que sa préférence et sa maitrise soient réellement orientées vers le C++.

Par la seul existence des pointeurs, des tableau, etc... Oui il y a des très fort point commun.

Le c++ reste une évolution du c. Pourquoi le c++ ? parce que c'est la maj du c ! Et une super grosse maj en plus.

Renier le liens des deux langages... Je trouve ça totalement puéril.

Oui on peut apprendre le C++ sans apprendre le C... Et faire du smart pointeur partout. M'enfin là, c'est vous qui avez un problème. Si c'est pour du Garbage Collector, vous êtes dans le mauvais langage.

Le C++, rarement plus performant que le C, n'est pas simplement plus pratique, il est surtout mieux pensées. Il dispose d'une palette d'outils largement plus étendu que le "C with Classes", qui permette de beaucoup mieux respecter les exigences d'une conception bien conçue.

Bon un autre argument est que le compilateur g++ optimise le vrai c++, mais plutôt mal le c with classes... pour msvc, je sais pas oO !

Citation:

---

Envoyé par Lavock

Par la seul existence des pointeurs, des tableau, etc... Oui il y a des très fort point commun.

Le c++ reste une évolution du c. Pourquoi le c++ ? parce que c'est la maj du c ! Et une super grosse maj en plus.

Renier le liens des deux langages... Je trouve ça totalement puéril.

Oui on peut apprendre le C++ sans apprendre le C... Et faire du smart pointeur partout. M'enfin là, c'est vous qui avez un problème. Si c'est pour du Garbage Collector, vous êtes dans le mauvais langage.

Le C++, rarement plus performant que le C, n'est pas simplement plus pratique, il est surtout mieux pensées. Il dispose d'une palette d'outils largement plus étendu que le "C with Classes", qui permette de beaucoup mieux respecter les exigences d'une conception bien conçue.

Bon un autre argument est que le compilateur g++ optimise le vrai c++, mais plutôt mal le c with classes... pour msvc, je sais pas oO !

---

Attention...

Il n'a jamais été question de renier les origines du C++.

Seulement, je doute que les descendants de Claus Barby soient enchantés d'être assimilé à leur aïeul simplement parce "qu'il en descendent" ;):P

De même, C est beaucoup moins typé que C++ (entre autres caractéristiques), et, si c'est pour faire du C++ comme tu fais du C, non seulement, tu perds une grande partie des avantages du C++ par rapport au C, mais, de plus, il est presque plus simple de continuer à ... faire du C ;)

L'idée n'est absolument pas de "renoncer à tout ce qui est isssu du C", le but est plutôt de dire "choisissons de préférence les possibilités propres au C++ et tournons nous vers les possibilités issues du C uniquement lorsque nous n'avons pas le choix (quelles que soient les raisons pour lesquelles nous n'avons pas le choix)" ;)

Citation:

---

Envoyé par koala01

Seulement, je doute que les descendants de Claus Barby soient enchantés d'être assimilé à leur aïeul simplement parce "qu'il en descendent" ;):P

---

Ça commence à sentir le Godwin, là... :mouarf:

Plus sérieusement, même si ce sont deux langages différents avec un "tronc commun", je fais autant de C++ "pur et dur" que de "C with classes" que de C "le dév qui murmurait à l'oreille des CPU"... Et c'est aussi grâce à ça que j'ai du boulot, d'ailleurs : je connais les deux langages, et je sais les faire cohabiter lorsque c'est nécessaire.

A mon sens, il est important de connaître les deux. La "guéguerre" pour savoir lequel des deux est le plus beau est encore plus stérile que toutes les autres guerres de langage, car ils restent quoi que l'on dise indissociables l'un de l'autre. Les API des OS sont toutes en C, par exemple, et ça n'a jamais tué un dév C++ d'utiliser ces primitives "C" dans des classes C++, non ? ;)

Sur le sujet de les apprendre ensemble ou séparément, et dans ce dernier cas il faut définir le "bon" ordre d'apprentissage, c'est plutôt à la tête du client je dirais. Le côté plus "abstrait" du C++ peut gêner des débutants, et de l'autre côté de la barrière, les pointeurs et allocations dynamiques "manuelles" peuvent en gêner d'autres.

C'est pour ça que j'aurais tendance à dire qu'il faut enseigner les deux en même temps, et à la même "vitesse" : à part pour une tanche intégrale, tout étudiant comprendra un concept donné (ex : chaînes, vecteurs, modularité, etc.) dans au moins un des deux langage, et aura donc plus de facilité à comprendre ledit concept dans le langage pour lequel il n'a pas trop d'affinité s'il a déjà une référence dans celui qui lui plait.

Et bien la voilà la conclusion: les deux en même temps. Faire du C++ sans C c'est choisir le mauvais langage. Surtout une fois confronté à la réalité de terrain où on va devoir partager son code, et plus encore s'approprier celui des autres qui est à 90% du "C with classes".
Peut-être dans 10 ans, lorsque l'héritage du passé ne sera plus trop lourd, il en sera autrement.