[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++...