Discussion :

[Cheps]

Comme je l'ai déjà dit, s'il y a, à mon sens, un prérecquis indispensable à l'apprentissage de n'importe quel langage de programmation procédural ou OO, c'est ce que je pourrais appeler la connaissance des "principes de programmation".

En gros, il s'agit d'avoir compris ce que signifient des termes comme[...]

Ces pré-requis font parti de l'apprentissage, tu ne peux pas leur apprendre tout ça avant qu'ils aient codé la moindre ligne. Faut y aller de manière incrémentale à mon avis. Tu commences par entrées/sorties et déclaration de variables, hop ils font 2 exercices. Ensuite calculs simples et fonctions, hop 2 exercices. Ensuite conditions et boucles, hop 2 exercices. Voir et utiliser les vecteurs je suis pour, mais finir un cours d'introduction sans aborder les tableaux je suis contre (d'où mon "il faut choisir l'ordre"). Après ça dépend des étudiants et des objectifs du cours.

[screetch]

Jusqu'ici j'avais l'impression que les flux C++ étaient de magnifiques outils... qu'est-ce qui te chiffonne donc précisément avec les flux screetch?

le formattage est peu clair, je n'aime pas devoir couper mes phrases au milieu. un exemple idiot, c'est que j'oublie toujours de rajouter un espace a la fin de mes mots lorsque la phrase devient découpée, du coup un nombre devient collé au mot qui le precede ou qui le suit. c'est aussi super mal foutu pour les traductions de texte. je prefere les chaines formattées. c'est un avis plus discutable que std::string, mais ca reste assez courant de ne pas aimer les flux.

[koala01]

Ces pré-requis font parti de l'apprentissage, tu ne peux pas leur apprendre tout ça avant qu'ils aient codé la moindre ligne.

Si, tu peux...

Il est tout à fait possible de leur apprendre ces prérequis sans leur faire écrire une seule ligne de code dans n'importe quel langage de programmation existant.

Et je dirais même que c'est la meilleure approche possible: celle qui consiste à se dire que le langage de programmation n'est qu'un outil permettant de faire comprendre à quelque chose d'aussi bete que l'ordinateur ce que l'on attend de lui.

La conception (au sens le plus large, allant de l'analyse des besoins à la création d'algorithmes en passant par l'identification du contenu de structures ou par les interactions qu'il y a entre les différents éléments d'un programme, et j'en oublie surement) est tout un art, mais, normalement, lorsque tu écris ta première ligne de code, tout le travail réellement intéressant a déjà été fait

Cela n'empêche nullement de revenir sur une étape ou une autre de la conception si, lorsqu'on commence à implémenter la solution, on se rend compte que l'on est passé "à coté de quelque chose", mais, pour autant que ton travail de conception tienne "la route" et que tu aies choisi une représentation pour tes algorithmes qui permette la "traduction immédiate" - ce qui n'est, effectivement, pas le cas du flowchart, mais qui est, par contre, celui du nassi-schneiderman, du moins, à mon sens, et malgré tout le mal que certains sur le forum peuvent en penser - tu pourrais presque demander à un ordinateur de se charger de l'écriture du code, parce que ce n'est qu'un travail de traduction et de dactylographie

Après tout, en dehors de la syntaxe propre à un langage particulier, un "quick sort" (par exemple) se fera en suivant exactement la même logique, que ce soit en C, en java, en C++ ou en Cobol...

Le gros problème de beaucoup de débutants (et sans doute de certains "pro"), c'est que, lorsqu'on leur demande d'écrire une fonction, ils se jettent sur leur clavier et commencent à "pisser du code" sans avoir pris la peine de réfléchir ne serait-ce que deux minutes à la logique qu'il faut mettre en oeuvre pour qu'elle fournisse le résultat attendu de la meilleure manière possible.

Le résultat, c'est que, non seulement, ils sont confrontés aux inévitables fautes de frappe, mais que, en plus, ils vont perdre un temps incroyable en débuggage, simplement parce qu'ils n'ont pas pensé plus loin que la troisième instruction qui suit celle qu'ils sont occupés à écrie.

Or, si tu réfléchis à ton algorithme avant d'écrire ta première ligne de code et que tu le teste mentalement (en te mettant à la place de l'ordinateur), si tu utilise la bonne méthode de représentation des algorithmes (comprend: celle qui ne laisse planer aucun doute sur la manière d'implémenter l'algorithme), la première compilation réussie (une fois corrigées les inévitables fautes de frappe et erreur de syntaxe) te donnera exactement le résultat attendu.

Ca peut ne pas être le résultat "optimum", dans le sens ou ton algorithme, n'est peut être pas le meilleur, mais le résultat correspondra à ce qui est attendu.

[JolyLoic]

je pense que quelqu'un qui n'est pas capable de créer sa propre classe de string est pas un bon candidat pour le C++.

Je pense qu'il y a aux moins trois sujets distincts mais liés à ne pas confondre :
1 - Est-il nécessaire pour être autonome en C++ de savoir gérer manuellement la mémoire, être capable de réécrire une classe string ou vector...?
2 - Dans quel ordre présenter les différentes parties d'un cours de C++ (ce qui me semblait la question initiale de ce post)
3 - Faut-il utiliser dans la vie courante string, vector et cie plutôt que char*, allocation manuelle...

A 1, je répond sans hésiter oui. Mais à 2, je répond que la courbe d'apprentissage me semble beaucoup plus progressive si on commence par string/vector, et qu'on garde les choses plus manuelles pour la fin.

A la question 3, je répond oui par défaut. Ce qui vient renforcer mon point de vue sur la question 2, ce qu'on utilise dès le début fait moins peur que quelque-chose qui n'arriverait que dans la dernière leçon.

pas grand monde ne reconnait ici que la classe std::string est tres mauvaise d'un point de vue conception (beaucoup, beaucoup trop de fonctionnalités)

Au second ordre, elle est très mauvaise, certes. Mais au premier ordre, elle gère correctement ce pour quoi elle a été conçue : Gestion de l'allocation mémoire, de la taille, sémantique de valeur. On aurait pu faire une classe de string meilleure, mais la classe actuelle est quand même largement au dessus des alternatives de type char*.

[metagoto]

Pour un néophyte total en prog, je pense que commencer par python est un très bon choix. Pas de C, pas de C++, rien de tout ça car ces derniers sont "trop proches du hardware". Il y a plusieurs années, on aurait commencé par le BASIC ou le logo (hé, vous avez connu ça ?)

Ensuite, quand vient le moment d'aborder le C++, avant le C, je conseillerai de commencer par les notions de scopes, de passage par copie ou référence le tout en manipulant des POD sur la pile et les objets de base de la SL, string, vector, io*. De ce coté là, effectivement, AC++ est un bon bouquin.

Aprés tout, quelles sont les choses importantes sur lesquelles il faut se focaliser dès le début quand un programmeur professionnel a la lourde tâche d'apprendre un nouveau langage ? Par quoi commencez-vous ?

[koala01]

En dehors de la syntaxe et de la grammaire propre au langage, je dirais (peut être dans un ordre différent)

• les type définis par l'utilisateur qu'il admet et leur particularités (par exemple: en C++, la seule différence entre une struct et une class tient dans leur accessibilité par défaut, en C#, par contre, une structure a d'office sémantique de valeur et est passée comme telle (avec copie) en argument, alors qu'une classe a d'office sémantique d'entité, et est passée sous une forme équivalente à la référence du C++)
• La manière de présenter le code source d'un "module" (un, ou plusieurs fichiers, définitions incluses dans la déclaration ou séparée, ...)
• La manière de créer des collections
• La manière de gérer les chaines de caractères
• La manière de gérer les flux et ou les fichiers
• La manière de convertir les types primitifs en chaine et inversément
• Les classes, structures, fonctions libres fournies par le langage/le standard qui n'entre dans aucune des catégories sus-citées, mais en fonction de mes besoins (ce qui implique qu'il n'est pas exclu que je ne m'intéresse jamais à une fonction ou à une classe que je n'utilise jamais )

[Cheps]

Pour un néophyte total en prog, je pense que commencer par python est un très bon choix. Pas de C, pas de C++, rien de tout ça car ces derniers sont "trop proches du hardware". Il y a plusieurs années, on aurait commencé par le BASIC ou le logo (hé, vous avez connu ça ?)

Problème: un semestre universitaire c'est 14 semaines, avec en principe 2 heures de cours et 2 heures d'exercices par semaine (en tous cas ici en Suisse, je ne connais pas le système français). Tu ne peux pas te permettre d'enseigner un "langage pour néophytes" avant d'attaquer les "choses sérieuses". Commencer par du procédural comme C c'est parfait, les étudiants comprennent facilement la logique et arrivent à résoudre par eux-même de petits problèmes (en tous cas ceux qui ont un tant soit peu d'esprit logique).

[Lavock]

Je pense qu'il y a aux moins trois sujets distincts mais liés à ne pas confondre :
1 - Est-il nécessaire pour être autonome en C++ de savoir gérer manuellement la mémoire, être capable de réécrire une classe string ou vector...?
2 - Dans quel ordre présenter les différentes parties d'un cours de C++ (ce qui me semblait la question initiale de ce post)
3 - Faut-il utiliser dans la vie courante string, vector et cie plutôt que char*, allocation manuelle...

1 - Totalement d'accord avec toi.

3 - Je dirais qu'il faut utiliser se dont on a besoin... et pas hésiter à refaire des classes stl minimalist si cela correspond plus à nos besoin.

2 - Absolument pas d'accord. Même si je reconnais qu'il faille couper les ponts à un moments, j'ai vue trop de code "java like" avec ce type d'approche. Et le code C++ d'horreur et à mon avis pire que le "C with class".
Comprendre ce que la pile, le tas, les allocations dynamiques enfin bref, la couche C commune au C++, c'est évité des absurdités immondes, des habitudes que l'on crois bien, et qui s'incruste.
Et je pense qu'il est bien plus facile de prendre du C++ java pour une bonne habitude que du C with Class...

[maxim_um]

Et je pense qu'il est bien plus facile de prendre du C++ java pour une bonne habitude que du C with Class...

La faute en incombe peut-être au fameux "hello world", du moins en mode OO.

[metagoto]

En dehors de la syntaxe et de la grammaire propre au langage, je dirais (peut être dans un ordre différent)

• les type définis par l'utilisateur qu'il admet et leur particularités (par exemple: en C++, la seule différence entre une struct et une class tient dans leur accessibilité par défaut, en C#, par contre, une structure a d'office sémantique de valeur et est passée comme telle (avec copie) en argument, alors qu'une classe a d'office sémantique d'entité, et est passée sous une forme équivalente à la référence du C++)
• La manière de présenter le code source d'un "module" (un, ou plusieurs fichiers, définitions incluses dans la déclaration ou séparée, ...)
• La manière de créer des collections
• La manière de gérer les chaines de caractères
• La manière de gérer les flux et ou les fichiers
• La manière de convertir les types primitifs en chaine et inversément
• Les classes, structures, fonctions libres fournies par le langage/le standard qui n'entre dans aucune des catégories sus-citées, mais en fonction de mes besoins (ce qui implique qu'il n'est pas exclu que je ne m'intéresse jamais à une fonction ou à une classe que je n'utilise jamais )

Intéressant, mais quid de l'histoire du langage, de ses ancêtres (ceux dont il dérive) et de sa raison d'être (incluant son domaine d'application) ? Puis-je envoyer un email à son créateur, est-il inscrit sur twitter ?

Non, vraiment, je pense que négliger cette étude historique et fonctionnelle est une erreur.

@Cheps
Je pense que python est un langage sérieux. Neophite-friendly, oui, mais tout à fait adéquat pour sérieusement aborder la programmation.

[koala01]

Intéressant, mais quid de l'histoire du langage, de ces ancêtres (ceux dont il dérive) et de sa raison d'être (incluant son domaine d'application) ? Puis-je envoyer un email à son créateur, est-il inscrit sur twitter ?

Non, vraiment, je pense que négliger cette étude historique et fonctionnelle est une erreur.

Pas en première approche...

En première approche, ce qui t'intéressera vraiment, c'est de savoir comment tu pourra faire ce que tu veux avec le langage que tu a devant les yeux, et s'il est adapté à tes besoins.

Par exemple: je connais Cobol, mais je ne l'utilise pas pour l'instant, vu que je n'en ai pas l'intérêt (il faut dire que, actuellement, c'est plutôt un langage de niche).

Je sais qu'il a été créé à une époque où les programmes tenaient encore sur des petits morceaux de cartons perforés, et je sais dans quels domaines je risque encore bien de le rencontrer à l'heure actuelle.

Mais, en dehors des éléments que j'ai cités plus haut, ai-je vraiment par besoin de savoir qui il a été écrit, comment et dans quel but

Est-ce que ces informations feraient de moi un meilleur programmeur Cobol

Appliqué au C++: Est-ce que le fait de pouvoir contacter stroutroup, alexandrescu ou n'importe quel guru ou membre du comité de standardisation fait de moi un meilleur programmeur C++

Faut il absolument avoir l'adresse électronique de Linus Tovald ou de Bill Gates dans sa liste de contacts pour être en mesure d'utiliser correctement linux ou windows Faut-il seulement connaitre leurs noms (tu me dira, il est difficile d'avoir la moindre discussion sur le sujet sans que ces noms n'apparaissent, ou peu s'en faut )

Au niveau des ancêtres, c'est presque encore pire: c'est parce que le C est l'ancêtre le plus direct du C++ que l'on en arrive à se dire que C++ n'est qu'une "surcouche" de C et à apprendre en réalité du C with class...

A l'extrême limite, je dirais presque que, avant de savoir d'où vient le langage, ce qui m'importe bien plus, c'est de savoir sur quelles plateformes il est disponible et si la licence d'utilisation est compatible avec celle que j'en aurai.

Au final, l'historique ou les "grands noms" des gens qui l'ont développés ou qui ont apporté une contribution au langage vient par la suite, et tu n'en a, à peu de chose près, strictement que faire lorsqu'il s'agit de "faire tourner" ton premier programme dans un langage que tu découvres

[maxim_um]

Au niveau des ancêtres, c'est presque encore pire: c'est parce que le C est l'ancêtre le plus direct du C++ que l'on en arrive à se dire que C++ n'est qu'une "surcouche" de C et à apprendre en réalité du C with class...

Et pourtant, le C++ n'a pas été conçu dans ce sens, si je ne m'abuse.

[koala01]

Et pourtant, le C++ n'a pas été conçu dans ce sens, si je ne m'abuse.

Bien sur que C++ n'a pas été conçu dans ce sens...

Mais, il n'empêche que le gros problème que l'on rencontre, et qui est, finalement noeud de la discussion ici présente, c'est que trop souvent le C++ est appris comme tel (comme du "C évolué", s'entend), pour la simple raison que C++ a veillé à assurer une certaine compatibilité avec C et qu'il en partage la syntaxe.

Mais, dans l'absolu, ce problème pourrait très bien apparaitre avec n'importe quel langage dont on pourrait dire "il descent de tel autre", qui en respecte la même syntaxe et qui veille à assurer une compatibilité ne serait-ce que partielle avec son "ancêtre"

Et c'est pour cela que, bien qu'il ne soit absolument pas question (du moins dans mon chef) de renier les origines du C++, je plaide pour que l'on n'approche ses similitudes avec C que le plus tard possible, lorsque ce que l'on considère généralement comme les "bonne habitudes" propres au C++ auront été correctement prises.

Si on travaille dans l'autre sens (ce qui est trop souvent vrai), nous obtenons des programmeurs fortement ancrés dans des habitudes issues du langage ancêtre (le C, en l'occurrence) et qui auront du mal (même si c'est relatif) à s'en débarasser pour acquérir les habitudes propres au C++.

Il me semble toujours préférable d'apprendre la règle de base avant de vouloir appendre l'exception.

Bien sur, l'exception à une règle est tout aussi importante (et parfois plus) que la règle générale, mais... elle doit rester une exception

Dans le cas qui nous occupe, la règle générale, c'est de manipuler la S(T)L tant qu'on peut, et, lorsque l'on n'a pas le choix (pour des raisons pouvant être multiples et variées), se tourner vers les solutions issues du C (pointeurs et gestion dynamique de la mémoire "à la main" en tête de liste)

[maxim_um]

Si on travaille dans l'autre sens (ce qui est trop souvent vrai), nous obtenons des programmeurs fortement ancrés dans des habitudes issues du langage ancêtre (le C, en l'occurrence) et qui auront du mal (même si c'est relatif) à s'en débarasser pour acquérir les habitudes propres au C++.

C'est le problème des réflexes (conditionnés), le souci, c'est qu'il est très difficile de s'en débarrasser.

Mais pourquoi ressens-tu une gêne à dire SL au lieu de STL, ou plutôt quelque chose qui a l'air de vouloir concilier les deux, comme avec le C et le C++ ?

[metagoto]

Pas en première approche...

En première approche, ce qui t'intéressera vraiment, c'est de savoir comment tu pourra faire ce que tu veux avec le langage que tu a devant les yeux, et s'il est adapté à tes besoins.

Pour savoir ça, il faut avoir étudié un minimum les généralités sur ce langage justement.
Ma question est a placer dans un contexte "professionnel": la personne a une expérience avec au moins un langage. Étudier l'historique (ce qui peut être fait en quelques minutes, je ne dis pas qu'il faut faire une thèse à ce sujet) permet de dégager à la fois les grandes lignes communes avec le langage qu'on connait déjà (ou les langages) et surtout les différences. Ensuite quand on plonge dans la grammaire, la sémantique, le comportement au runtime et tout le reste, on va beaucoup mieux percuter sur ce qui est important: ce qu'on ne connait pas déjà.

Mais, en dehors des éléments que j'ai cités plus haut, ai-je vraiment par besoin de savoir qui il a été écrit, comment et dans quel but

Mon clin d'oeil pour l'email de l'auteur.. c'était un clin d'oeil justement (bien que je trouve fascinant la proximité contemporaine avec les créateurs des langages usuels). On ne peut pas dire ça de la musique ou des mathématiques!

Au niveau des ancêtres, c'est presque encore pire: c'est parce que le C est l'ancêtre le plus direct du C++ que l'on en arrive à se dire que C++ n'est qu'une "surcouche" de C et à apprendre en réalité du C with class...

Là je ne suis pas d'accord. Certes, on peut ignorer tout ça et y aller quand même, mais c'est du temps de perdu. Par exemple, les shells unix (bash, sh etc) : on va beaucoup mieux capter la syntaxe bizarre et les règles de scoping bizarres également si on sait que à la base c'est un interpréteur de lignes stand alone et que, par exemple, /bin/[ est un executable. L'individu est tout de suite mieux conditionné pour progresser dans l'apprentissage.

[koala01]

Mais pourquoi ressens-tu une gêne à dire SL au lieu de STL, ou plutôt quelque chose qui a l'air de vouloir concilier les deux, comme avec le C et le C++ ?

C'est parce que je fais un distingo clair entre ce qui fait partie de la STL et ce qui fait partie de la SL...

Même si, de fait, la STL est en réalité un sous ensemble de la SL

Là je ne suis pas d'accord. Certes, on peut ignorer tout ça et y aller quand même, mais c'est du temps de perdu. Par exemple, les shells unix (bash, sh etc) : on va beaucoup mieux capter la syntaxe bizarre et les règles de scoping bizarres également si on sait que à la base c'est un interpréteur de lignes stand alone et que, par exemple, /bin/[ est un executable. L'individu est tout de suite mieux conditionné pour progresser dans l'apprentissage.

Je ne dis pas que ce n'est pas intéressant à connaitre, je dis que, si tu tombe sur un patron ou sur un client qui te dit "je veux que vous me codiez mon application en <rajouter ici un langage quelconque>" tu n'a pas forcément besoin de savoir tout cela pour autre chose que "ta culture générale".

Si, par la suite, tu "accroche" avec le langage en question, tu pourra effectivement t'y intéresser d'avantage, mais, si tu t'y intéresse dés le début et que tu te dépêchera d'oublier ce langage parce que c'est "vraiment pas ton style", t'aura (au moins l'impression d'avoir) perdu énormément de temps pour rien

De même, je ne dis pas qu'il ne faut pas connaitre les possibilités du C pour apprendre le C++, mais je dis qu'il ne faut les utiliser que lorsque l'on n'a absolument pas d'autres choix.

Et je dis que l'accent prioritaire de l'apprentissage doit être mis sur les capacités propres au langage réellement utilisé, et non sur les capacités des langages ancêtres.

S'il y a effectivement un intérêt à connaitre l'ancêtre pour se faciliter la tache avec le descendant, il est effectivement peut être de s'intéresser à l'ancêtre en priorité (comme pour les shell unixoides).

Mais ce n'est absolument pas le cas entre C et C++ (qui représentent quand même le centre du débat actuel) qui, au final, ne font "que" partager une syntaxe commune, et finalement pas si compliquée

[Kalith]

Par curiosité, je suis allé voir les bouquins de C++ qui sont mis à notre disposition à la BU (bibliothèque universitaire). Comme dans la quasi totalité des étagères, on y trouve en majorité des livres plutôt anciens (jusqu'a un peu avant 1990 pour celle-ci).
J'ai été surpris de voir que, sur les 3 ou 4 que j'ai ouvert, un seul parlait de std::string et std::vector (il datait de 2008 tout de même...).
Pour les autres : dans les premiers chapitres, c'est du C où printf est remplacé par cout. Puis ils abordent les classes, l'héritage, et enfin les flux.
A noter que, dans le bouquin le plus récent, les exceptions étaient placées en annexe, avec les templates (ces deux sujets sont, bien sûr, totalement absent dans les autres livres).

Du coup j'ai fais quelques recherche, et je me suis rendu compte que le C++ tel qu'on le pratique de nos jours est en fait très récent : d'après Wikipedia, la STL a été acceptée dans le standard en 1994 (et j'ai lu sur ces forums que les premières implémentations étaient tout sauf parfaites).
Quand on connait le temps que met l'enseignement (du moins en physique, de ce que je peux juger) pour tenir compte des dernières avancées, on comprend mieux la situation.

Enfin, ça c'est pour les plus jeunes comme moi, qui n'avons pas connu le C++ d'avant 2003

[metagoto]

Du coup j'ai fais quelques recherche, et je me suis rendu compte que le C++ tel qu'on le pratique de nos jours est en fait très récent : d'après Wikipedia, la STL a été acceptée dans le standard en 1994 (et j'ai lu sur ces forums que les premières implémentations étaient tout sauf parfaites).
Quand on connait le temps que met l'enseignement (du moins en physique, de ce que je peux juger) pour tenir compte des dernières avancées, on comprend mieux la situation.

Ca fait quand même 15 ans déjà! Il y a des anecdotes à propos de Stepanov et Lee demandant sans cesse à Stroustrup et Koenig si telle ou telle portion de STL "compilerait" car à l'époque à la fois les propriétés du langage nécessaires et les compilos, de surcroit, n'existaient pas ou n'étaient pas fixées. Rétrospectivement, c'est assez miraculeux que ça ait fonctionné

Pour rebondir sur la (sous) discussion avec koala01 et l'intérêt, à mon sens, de s'intéresser le plus tôt possible à l'aspect historique et philosophique d'un langage quelconque que l'on souhaiterait apprendre, est un Dr Dobb's "Productivity Award" decerné dès 1995 à The Design and Evolution of C++ (ok, avec Dr. Dobb's, c'est un tantinet biaisé ). Un DNE en parallèle d'un AC++ pour commencer, moi je dis, y aura du boulot de fait

[vikki]

Bonjour à tous,

Je reviens un peu sur le problème de l’apprentissage du C/C++, notamment sur l’idée d’apprendre les deux en même temps. Et bien pour avoir appris en même temps le C et C++, je ne conseille ça à personne. Je ne vous dis pas la perte de temps à passer de l’un à l’autre, à hésiter entre tel et tel manière de résoudre mon problème, à se documenter sur les deux langages en même temps… Autant vous dire que j’aurais préférer directement commencer par le C++. L’idée même d’apprendre deux langages en même temps (si on considère le C et le C++ comme parfaitement distincts) me semble un brin foireuse : vous auriez aimé commencer la prog avec un mélange de COBOL et de Java vous ?

Pour moi il ne fait aucun doute que débuter la programmation avec le C++ est une très bonne idée, à deux conditions : avoir préalablement suivi un cours d’algorithmique (on saura plus facilement quel algo de la STL utiliser dans tel cas ou quand implémenter nos propres solutions, quel conteneur privilégier en fonction de la situation, etc.), et suivre une petite formation sur les pointeurs (parce que c’est quand même à la base de tout). On est ensuite paré à tout ce qui va nous tomber sur le coin du crane, et on peut commencer le C++ par n’importe quel bout. A mon sens, entamer la programmation par le C++ offre pas mal d’avantages :

- On se prend une bonne claque au début, c’est sur. Les moins motivés iront voir ailleurs, ca évitera justement les joyeux mixeurs de C/C++ qui donnent une si bonne réputation au C++ dans les entreprises.

- Un développeur qui ne pratique qu’un langage ne va pas loin. Mais une fois maitrisé le C++, on apprend les autres langages en chantant et en dansant.

- Une fois à peu prés maitrisé le C++, il est plus facile de présenter le C : « le C est un langage ayant la même syntaxe que le C++ (une chance pour vous) mais vous ne pouvez pas utiliser ca, et ca, et re-ca, l’allocation/deallocation de mémoire se fait de cette manière étrange, les entrées/sorties de cette manière plus étrange encore, et j’en passe et des meilleurs ».

Un avis que ne partage pas tout le monde, mais j'aurais aimer qu'on me présente les choses de cette manière dans mon cursus

[koala01]

Bonjour à tous,

Je reviens un peu sur le problème de l’apprentissage du C/C++, notamment sur l’idée d’apprendre les deux en même temps. Et bien pour avoir appris en même temps le C et C++, je ne conseille ça à personne. Je ne vous dis pas la perte de temps à passer de l’un à l’autre, à hésiter entre tel et tel manière de résoudre mon problème, à se documenter sur les deux langages en même temps… Autant vous dire que j’aurais préférer directement commencer par le C++. L’idée même d’apprendre deux langages en même temps (si on considère le C et le C++ comme parfaitement distincts) me semble un brin foireuse : vous auriez aimé commencer la prog avec un mélange de COBOL et de Java vous ?

Pour avoir appris différents langages sur une période à peine plus grande qu'un mouchoir de poche, je n'ai pas d'objection à ce que les gens en apprennent plusieurs, à une condition sine qua non: que chaque langage soit appris indépendamment des autres, dans l'idée, et dans la pratique.

Je veux dire par là: en C, on apprend le C, en C++, on apprend le C++, en java, on apprend java et en Cobol on apprend Cobol... Et on ne parle que de cela.

Bien sur, si tu sors de deux heures de cours sur C et que tu passe, dans la classe d'à coté, pour deux heures de C++ ou de cobol, effectivement, tu risque de perdre un bon quart d'heure avant de recommencer à penser non plus en C mais bien en C++ ou en Cobol...

Mais, à coté de cela, ce genre d'horaire aurait presque l'énorme avantage d'aiguiser l'esprit d'adaptation, qui, à mon sens, prend aussi une bonne place dans la conception et la programmation.

Je suis le premier à plaider pour une connaissance théorique minimale adaptée (il ne sert pas à grand chose de connaitre la théorie OO pour programmer en séquentiel, et la connaissance de la seule théorie séquentielle est un peu limite lorsqu'il s'agit de programmer OO) lorsque l'on entame l'apprentissage d'un langage, mais il ne faut pas oublier non plus que la conception et la programmation sont des arts, car nous sommes toujours face à l'obligation de de nous adapter selon les circonstances.