Discussion :

[Yukiho]

Bonjour,

Je suis étudiante et l'on code en vb.net lors de mes cours.

Par rapport à mes futures études et aussi le monde du travail, je souhaiterais apprendre le C++, mais est il nécessaire d'apprendre le langage C avant d'attaquer le C++ ? Surtout que j'ai déjà la logique algorithmique et objet.

Si c'est le cas auriez vous un nom de livre qui permettrait l'apprentissage des deux à la fois ?

merci.

[Goten]

La réponse est simple ... non .
Il faut bien voir le C et le C++ comme deux langages totalement différent .



(aie je sens le topic à débat..)

[JolyLoic]

La réponse à mon sens est non (même si d'autres pensent le contraire). Il peut par contre être utile d'apprendre le C aussi, si on envisage de travailler dans des domaines où C et C++ sont utilisés en conjonction étroite, et il est certainement nécessaire d'apprendre un minimum de C à la fin de l'apprentissage du C++ afin de :
- Pouvoir comprendre du code sur lequel on aurait travaillé qui en C++ utiliserait les idiomes et bibliothèques standard du C
- Pouvoir interfacer une bibliothèque écrite en C.

Personnellement, j'estime ne pas connaitre le C (dans le sens où je serait bien en peine d'écrire un programme de plus d'une page avec), mais ça ne me gêne pas du tout pour faire du C++.

En terme de livres, je te conseilles d'abord de lire http://alp.developpez.com/tutoriels/debuter-cpp/ puis les cours et tutoriels C++.

[Invité]

Il n'est pas nécessaire d'apprendre le C avant, c'était la façon traditionnelle d'enseigner le C++ il y a quelques années (en particulier à l'époque où l'orienté objet était encore une nouveauté), mais c'est de moins en moins le cas.

Il n'est pas non plus nécessaire de savoir écrire du C pour écrire du bon C++ (certains ici diront "bien au contraire", je pense).

Mais si tu veux faire du C++ dans le monde professionnel, il est utile de savoir lire le C, ou des programmes C++ écrits "à la C". Un très grand nombre (la majorité je pense) de programmes C++ du monde réel s'appuient sur des librairies C, ou contiennent du code écrit dans un style voisin du C (la plupart des "anciens" programmeurs C++ viennent du C). Ne connaître que "le C++ moderne" (voire mépriser tout ce qui ne l'est pas), dans le monde réel, c'est plutôt un handicap.

A mon avis, la meilleure facon, c'est d'apprendre le C++ d'abord, et de lire un peu sur le C après...

Francois

[3DArchi]

Salut,
Comme mes petits camarades, je dirais que tu peux directement commencer par du C++. Ensuite, il est clair qu'en milieu professionnel tu seras quand même confronté à du code C avec du C++. Mais l'apprentissage C++ puis C présente probablement moins de risque de faire du C en C++... Enfin, pour apprendre le C++, je conseille quand même de travailler en amont ou en parallèle l'objet.

[Yakuzan]

J'ai appris Java avant d'embarquer en C++ et la transition ce fait quand même bien.

D'après ce que j'ai entendu par rapport au langage C, il n'est pas a confondre avec le C++ et qu'il n'est certainement pas la même chose.

Il est toujours mieux d'avoir un background mais je te suggère n'importe quelle langage qui supporte la POO.

[Mathelec]

Je te conseil le bouquin Comment programmer en C++ (Auteur : Deteil et Deteil). Mais il y a plusieurs versions, fais attention à avoir la dernière
[COLOR=#000000 ! important][/COLOR]

[Luc Hermitte]

(AC++ ou le dernier bouquin de Stroustrup (en cours de traduction) restent préférables ... ; cf message de Loic, tout ça)

[koala01]

Salut,

Comme tous ceux qui ont répondu, je trouve qu'il est inutile (oserais-je aller jusqu'à dire dangereux ) d'apprendre C avant d'apprendre C++.

Ne serait-ce que parce que C++ fournit, justement, une quantité non négligeable de possibilités qui tendent à nous éviter certains pièges issus de C, et qu'il est d'autre part beaucoup trop facile, une fois que l'on a pris les habitudes du C, de vouloir les replacer dans un contexte de C++, alors qu'à l'usage il apparait clairement qu'elles sont mauvaises et dangereuses.

Si on voulait faire une comparaison, nous pourrions dire que vouloir passer par l'apprentissage du C avant "d'attaquer" C++ revient à vouloir absolument apprendre à rouler à moto avant d'apprendre à rouler en voiture, ou vice versa.

Bien sur, il y a certains points communs (le code de la route, par exemple), mais ce sont deux types de véhicules qui se maitrisent de manière fondamentalement différente (pensez que, pour tourner rapidement à gauche à moto, il faut... braquer à droite )

Maintenant, en sortant du seul contexte de l'apprentissage et en s'intéressant à ce qui te sera nécessaire dans ta "vie de tous les jours" en tant que programmeur C++, il est clair qu'une connaissance (au minimum basique) de C te sera très certainement utile voire indispensable dans certains domaines, principalement parce que l'on traine encore souvent des tentatives historiques de portage de code C en C++ ayant donné l'horrible mélange souvent nommé C with classes, quand on n'a pas, purement et simplement, affaire à une partie de module écrite dans un C++ de qualité variable et une autre partie écrite... en C.

[Médinoc]

Je ne dirais pas spécifiquement "inutile", mais "dangereux", c'est sûr: Trop d'idiomes C sont considérés comme horriblement sales en C++.

[miltone]

moi j'ai fait ce cheminement là :

algorithme --> C --> C++

Je confirme que C++ après le C peut être dangereux et je suis très bien placé pour le savoir car j'apprend le C++ en ce moment et je connaissais un peu le C

Par contre suivant le niveau je conseillerais d'apprendre d'abord un langage procédurale pure avant un langage objet...

[eyquem]

une mine d'observations et d'informations pour nourrir ta réflexion

http://www.developpez.net/forums/d82...semble-separe/

[Lavock]

Héhé, je suis le seul de pas vraiment d'accord sur le forum, tu parles d'un débat >< !

En fait, comme toute chose, il y a 2 sortes d'approches. Celle défendu majoritairement par ici, c'est une approche descendante. On commence par du code bateau avec utilisation de STL, pour descendre petit à petit et finir par les fondamentaux de gestion mémoire.
Il existe aussi une approche montante, en certain point dangereuse, si on n'arrive pas "passer" brutalement à une autre idéologie. On commence par apprendre les fondamentaux, pour ensuite monter petit à petit et finir par la STL. En fait, avec cette approche, on est censé (pour les plus doués ?) savoir écrire la STL avant de savoir l'utiliser.

Personnellement, j'ai eu droit à la deuxième approche. Je ne sais pas quel est la meilleurs dans l'absolue, et je ne suis pas persuadé que la mono-approche soit une solution. La principale critique que je fais à l'approche descendante et l'étroitesse d'esprit et la mauvaise connaissance des mécanismes de bases. Plus ou moins le genre de personne qui se font chier à taper 20 lignes de codes pour ne pas avoir à utiliser des pointeurs >< !

Je serais plutôt d'avis de cumuler les deux approches. D'un côté du C pour les fondamentaux, en ayant bien en tête la finalité. En parallèle, on commence le C++ par le haut, est surtout par le paradigme, histoire de comprendre pourquoi certaine chose ne devrait être faite qu'en C, et pas en C++.

Mais bon, c'est juste un avis.

[Médinoc]

Ma critique de l'approche montante, c'est que tu prends trop facilement le réflexe "tableau de char". Pour faire des entrées fiables, std::string et std::getline() sont beaucoup plus sûrs!

En C, si tu veux saisir une ligne avec une longueur maximale, tu dois déjà faire le fclean() du forum, et si tu veux saisir une ligne de longueur arbitraire, tu dois jouer avec realloc()!

[JolyLoic]

Je serais plutôt d'avis de cumuler les deux approches. D'un côté du C pour les fondamentaux, en ayant bien en tête la finalité. En parallèle, on commence le C++ par le haut, est surtout par le paradigme, histoire de comprendre pourquoi certaine chose ne devrait être faite qu'en C, et pas en C++.

Sans revenir sur le débat entre ces deux approches, je tiens juste à signaler qu'on peut faire l'approche montante tout en restant en permanence dans le cadre du C++, sans avoir recours au C.

[3DArchi]

Pour moi, ça tient difficilement la route. Pour apprendre le Java, dois-je apprendre le C avant ? Non. Ben en C++, c'est pareil. Il est clair qu'ensuite une connaissance du C sera rapidement indispensable car beaucoup de bibliothèques n'ont qu'une interface en C et comme dit par françois (je crois), le monde pro demande en général les 2 compétences mélangées. Mais pour l'apprentissage, je pense qu'on peut les séparer. D'ailleurs pour moi, le plus important quand on apprend le C++ n'est pas le langage mais la démarche objet. Le langage ne vient qu'à côté ou juste après.

[koala01]

Je ne dirais pas spécifiquement "inutile", mais "dangereux", c'est sûr: Trop d'idiomes C sont considérés comme horriblement sales en C++.

Sans revenir sur le débat entre ces deux approches, je tiens juste à signaler qu'on peut faire l'approche montante tout en restant en permanence dans le cadre du C++, sans avoir recours au C.

C'est en fait exactement ce que j'entendais par inutile.

Finalement, quand on y pense, que va-t-on utiliser de C en C++ durant l'apprentissage

La syntaxe Pourquoi ne pas l'apprendre dans le cadre de C++

Certains mots clés pareil

Les fonctions relatives à la gestion des entrées / sorties elles sont au minimum peu recommandées en C++.

Les fonctions de conversion les *stringstream peuvent parfaitement être utilisés dans une approche purement procédurale.

L'approche procédurale, justement on peut parfaitement aborder C++ sur l'angle de ce paradigme, sans s'inquiéter outre mesure des deux autres qui font toute la force de C++

La gestion dynamique de la mémoire et le recours au pointeurs on n'en aura réellement besoin qu'au moment d'aborder le polymorphisme et / ou les relations contenu -> contenant et / ou la problématique de la gestion de la durée de vie d'un objet créé en dehors de l'objet créateur... Et cela ne se fera pas "à la manière C", mais "à la manière C++".

Autrement dit, il n'y a réellement aucun prérequis propre au C que l'on ne pourrait pas envisager d'étudier lors de l'apprentissage de C++.

Après tout, même si l'étudiant n'a aucune notion OO, qu'est-ce qui pourrait nous empêcher de gérer une collection de Machin avec une std::list ou un std::vector dans une approche purement procédurale, pour autant qu'on lui explique la manière de s'en servir, même s'il n'a qu'une idée très approximative de ce qu'implique le fait que insert ou push_back (ou les autres) soient des fonctions membre de la classe vector ou list

[Médinoc]

Après tout, même si l'étudiant n'a aucune notion OO, qu'est-ce qui pourrait nous empêcher de gérer une collection de Machin avec une std::list ou un std::vector dans une approche purement procédurale, pour autant qu'on lui explique la manière de s'en servir, même s'il n'a qu'une idée très approximative de ce qu'implique le fait que insert ou push_back (ou les autres) soient des fonctions membre de la classe vector ou list

Tutafé.
D'ailleurs, selon une école de pensée qui m'a pas mal influencé, l'utilisation des conteneurs sans les itérateurs n'est même pas "de l'Orienté Objet" (parce qu'il n'y a pas de polymorphisme de je-ne-sais-plus-quel-type). Donc, on n'a pas besoin d'avoir des notions OO pour apprendre à s'en servir.

[Ksempac]

Pour moi, ça tient difficilement la route. Pour apprendre le Java, dois-je apprendre le C avant ? Non. Ben en C++, c'est pareil.

Grosse difference : En java, tu n'as, en general, pas besoin d'apprendre a gerer la memoire/la destruction de tes objets, et tu ne manipules jamais d'adresses. Alors que les "malloc/free" c'est aussi important en C que le sont les "new/delete (+destructeurs)" en C++.
Corollaire : les 2 langages passent leur temps a manipuler des pointeurs. Certes ya les references en C++, mais ca demande un minimum de reflexion/action de la part du developpeur, alors qu'en Java tout ca est invisible (pour le meilleur et pour le pire).

[koala01]

Tutafé.
D'ailleurs, selon une école de pensée qui m'a pas mal influencé, l'utilisation des conteneurs sans les itérateurs n'est même pas "de l'Orienté Objet" (parce qu'il n'y a pas de polymorphisme de je-ne-sais-plus-quel-type). Donc, on n'a pas besoin d'avoir des notions OO pour apprendre à s'en servir.

Et même au delà...

Dés que l'on aura abordé la notion de variables statiques pour les structures, ou le passage de l'information entre différents espaces de noms, l'étudiant saura que :: est un opérateur de portée.

Je ne verrais personnellement aucun problème à expliquer que std::list<UnType>::iterator est "un truc", un "machin" ou "quelque chose" (n'importe quoi pour éviter le recours au terme objet ) permettant de parcourir les différents élément de la collection, en "laissant pour plus tard" l'étude du "comment ils font"