Bonsoir,
Je voudrais me lancer dans un apprentissage sérieux du C et du C++ , me conseillerez-vous plutot de commencer par le C ou le C++??
Merci bien..

Question posé tellement de fois...

Enfin bon, le début de l'apprentissage du C++ c'est en gros du C, donc je te laisse te faire ton propre avis.

Je suis un livre intitulé Langage C, de Claude Delannoy, des éditions Eyrolles. Il te présente le langage C, et au final parle des différences avec C++, etc...

Cela dépends de ce que tu veux faire.

Et perso, j'ai vu le C++ avant puis après le C. D'abords le système objet etc... pour retourner avoir le C.
C'est mon prof qui me la enseigner ainsi, et c'est franchement pas plus mal. A toi de voir!

Quel intérêt d'apprendre les 2 ?
Si tu veux n'en apprendre qu'un apprends directement le C++.

Mais ça sert à rien le C sauf pour le système ou le secteur industriel. Donc si tu en est capable le C++ directement.
Si tu arrive à comprendre le C++ tu aura pas de mal à passer à Java ou C# si tu en à envie plus tard.

"Mais ça sert à rien le C sauf pour le système ou le secteur industriel. ".

Donc une part assez importante de l'industrie informatique francaise. Le C c'est important de le connaitre car c'est la base de nombreux langages, et ca a une amplitude de niveau tres importante. On peut faire des jeux videos et des serveurs comme des systemes embarques et de l'assembleur.

En pratique il y a peu de partie qui sont ecrite en C directement. Les gens qui sont forme en C++ passeront au C facilement en pratique. La programmation embarque est une autre bete (lire the blog de nigel jones est assez convaincant qu'il y a programmeur C et programmeur de systeme embarque http://embeddedgurus.com/stack-overflow/ ).

Quant a l'assembleur, je dois dire que je reste assez septique. C'est vraiment tres peu utiliser de programmer directement en assembleur. Ca m'est arrive recement de lire de l'assembleur pour comprendre ce que fait mon compilateur, mais en pratique c'est assez rare. Regarder la sortie d'un compilo en -O3 -xSSE4_2 (ou whatever) donne assez rapidement l'impression qu'optimiser ce bousin a la main va etre difficile voire impossible. En pratique, il vaut mieux se concrentrer sur exprimer toutes les contraintes du probleme au compilateur (a travers les pragma qu'il expose) et regarder l'assembleur qu'il pond ou eventuellement ecrire exactement ce que tu veux faire en C et compiler en -O1.

bezarius:
« Si tu veux n'en apprendre qu'un apprends directement le C++. » bof. Le C est très très nettement plus simple à apprendre, et on peut faire la même chose qu'en C++ (je sous-entends ici que la programmation orienté objet n'apporte fondamentalement rien dans la majorité des codes que l'OP va écrire).

De toute façon, la vraie question de l'OP c'est "sur quoi je dois me concentrer ?". Et la réponse est "concentre-toi sur les fondamentaux, c'est à dire sur le C."

Après, "C vs C++" c'est pas la vraie question de façon générale. La vraie question sous-jacente, c'est "impératif/modulaires VS objet". Et elle dépasse complètement le cadre de ce thread (sans parler du fait que la plupart des gens ont une vision complètement fausse de l'OO).

On n'est pas obligé d'apprendre "tout" le C++ pour s'en servir.
On n'est pas obligé d'utiliser l'OOP en C++.
Du coup quel est l'intérêt d'apprendre le C à part se compliquer la vie ? Surtout pour les randoms trucs que va faire l'OP.

Personnellement j'aurais tendance à conseiller le C++ plutôt que le C quand on débute. Si on n'exploite pas toutes les possibilités du langage C++ alors celui est quand même plus simple à manier. Par exemple, pour moi il est beaucoup plus agréable et intuitif d'utiliser la classe string plutôt que les fonctions de string.h avec des char*.

Globalement l'apprentissage de l'algorithmique de base est le même (boucles for, while, tableau, fonctions, etc.), que l'on commence par C ou C++. Ce qui va changer fondamentalement au départ, c'est un peu de sucre syntaxique (comme la classe string) qui ne va pas imposer au futur développeur de savoir exactement comment ça fonctionne concrètement. Pour une première approche de la programmation il y a certains détails qu'on peut passer sous silence. Il pourra plus tard recoder la classe string s'il veut en comprendre clairement le fonctionnement.

"On n'est pas obligé d'apprendre tout le C++ pour s'en servir." heureusement, sinon pratiquement personne ne coderait en C++.

"On n'est pas obligé d'utiliser l'OOP en C++."
Sauf que quand il n'y a pas du tout d'OO, on n'appelle plus ça du C++, mais du C.

"Du coup quel est l'intérêt d'apprendre le C à part se compliquer la vie ?" là, il faut m'expliquer ta logique, parce qu'elle me parait inconsistante.

Outre le fait que se battre sur quel langage apprendre est un peu stupide (ce qu'il faut apprendre, ce sont des concepts de programmations et des algorithmes, la pratique étant de l'ordre du détail), je vais te donner quelques intérêts au C :

1) c'est un langage limité à un style de programmation bien délimité : la programmation impérative/modulaire.

2) la syntaxe du C a servi de base à de nombreux langages, donc apprendre sa syntaxe apporte beaucoup en pratique.

3) c'est un langage où la composante "gestion mémoire" est la plus simple (oui, quand c'est explicite, c'est plus simple !). Je me vois mal illustrer un cours sur la gestion de la mémoire avec un autre langage que le C.

Le C++ a quant à lui deux réels intérêt au début :

1) cin/cout sont nettement plus agréables à utiliser que printf

2) la notion de passage d'arguments par référence est plus naturelle que le passage par pointeur (celui-ci étant utilisé dans deux contextes radicalement différents, que les gens confondent trop souvent).

WTF, chacun son délire...
De toutes façons le "débat" revient toutes les 2 semaines.

elite_2009:
- les namespaces ça sert à rien à l'échelle de ce thread.
- les templates c'est à peine plus propre que le #define du C (et d'ailleus ça a été conçu en ce sens).
- les exceptions, je n'en vois pas l'intérêt (on peut d'ailleurs montrer qu'on code tout aussi bien sans).
- la surcharge ne fait qu'alléger légèrement le code, mais ce n'est pas la mort d'écrire les appels de fonctions en infixe.

Bref, mettez vous dans le crâne que l'OP va coder des petits programmes (au mieux un petit jeu ou une petite appli). Donc le petit confort qu'on peut avoir dans des langages plus avancés, on s'en fiche complètement.

Pour le 4ème tiret :
+ et de donner (si besoin) des noms différents aux opérateurs

"Donc le petit confort qu'on peut avoir dans des langages plus avancés, on s'en fiche complètement."

Pas sûr. Par exemple, std::cin, std::cout, std::string, etc. c'est du petit confort de C++ et quand on débute et qu'on fait juste des petits programmes, c'est quand même bien sympathique. Rien ne l'empêche par la suite de faire du "C" tout en profitant également de quelques unes des petites fonctionnalités bien sympathiques du C++. En gros, utiliser la bibliothèque standard C++, mais sans nécessairement construire ses propres programmes en orienté objet.

Aldebran: oui, c'est moi qui ai amené le confort de cout/cin sur le tapis. Je suis convaincu que c'est un vrai soulagement au début, seulement des cours de C++ qui se concentrent vraiment sur les bases (prog impérative, modularités, modèle mémoire), je n'en connais pas.

elite_2009: ha, excuse-moi champion.
Dans ma grande naïveté de gens qui compile son .c en .o ou/et en exécutable, j'avais oublié que l'intérêt principal du #define du C était de faire passer le code au préprocesseur seulement afin de baver devant le magnifique nouveau fichier .c généré.
Maintenant que tu le soulignes, ça me parait effectivement évident qu'il y a une différence, et que c'est même complètement stupide de vouloir obtenir du binaire à partir d'un #define. Franchement, tu as trop raison.

Pour le reste, je ne vais pas commenter outre mesure. Tu confonds tout, et c'est juste navrant. Pour le reste, je te donne trois mots clés : signaux, callbacks, et continuations. (sachant que dans ce que tu présentes, dans un cas réel, c'est probablement signe d'un mauvais découpage en fonctions.)

N'essaie pas d'étaler ta non-science avec moi, je vois tout de suite que tu as zéro recul sur ce que tu racontes, et je te soupçonne d'essayer de noyer le poisson sous des arguments techniques (ce qui ne marchera pas avec moi).

L'argument du débogage ne tient pas la route. Je ne vois pas de différence entre avec ou sans exceptions. Un vrai débogueur te permet de remonter les frames dans tous les cas.

PS: je sais bien que les signaux unix sont des signaux unix (et pas linux, mais unix). C'est pour ça que j'ai donné deux autres pistes.

Les exceptions permettent significativement de clarifier la gestion d'erreur au runtime. Ca rends le debuggage beaucoup plus simple en pratique puisque tu as moins de code de gestion d'erreur a t'assurer qu'il fonctionne convenablement.

Les templates sont dans le fond plus propre que les macros et ils evitent plein d'erreur assez fatiguante a trouver. Cependant les compilos pondent des messages d'erreur sur les templates tellement incomprehensible que je ne suis pas sur que ca soit bien meilleur pour un debuttant en pratique.

godrik: ne me fais pas dire ce que je n'ai pas dit. Le concept d'exécpetion est utile dans certains cas de figure. Tout ce que moi j'ai dit, c'est que je ne vois pas l'intérêt du support fourni par le langage C++. Je sais gérer ma sauce moi-même en C sans ce support.

Quant aux templates, c'est très très vicieux. Encore un exemple de choses qui paraissant triviales et qui sont en réalité très complexes. Je préfère déboguer un code basé sur des #define qu'un code avec des templates, personnellement.