Discussion :

[JolyLoic]

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.

[Invité]

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

[JolyLoic]

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).

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

Et, au risque d'abuser un peu 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.

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.

[koala01]

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 ) 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 ), 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 ) )

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

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 )

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

[Médinoc]

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!

[CedricMocquillon]

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.

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).

[Invité]

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)

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

[Médinoc]

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

[ptyxs]

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.

[Fmunch]

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.

[Nogane]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

[Médinoc]

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

[metagoto]

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.

[Luc Hermitte]

À 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.

Et, au risque d'abuser un peu 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.

[Mac LAK]

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.

[koala01]

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

[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 !

[koala01]

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"

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)"

[Mac LAK]

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

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

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.

[camboui]

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.