Discussion :

[wil31]

Salut a tous.

Alors voila cela fait maintenant quelques jours que j’apprends le C en suivant un tutoriel, j'ai aussi acquit deux bouquin pour apprendre C et C ++
seulement voila, on me déconseille d'apprendre le C et de passer directement a C++, de plus on me conseille de fuir le tutoriel de cet autre site.

Est ce vraiment une erreur d'apprendre le C puis le C++ ?

merci a tous

[smartties]

j'aurai aimer savoir si ils etaits si mauvais que ca?

Je n'ai jamais fait ce tutoriel, mais en le feuilletant un peu, il semblerait qu'il se contente seulement d'enseigner la syntaxe du C++.
Il ne t'enseignera pas de design pattern et tu n'y apprendras pas les concepts des normes C++11, ou C++14.
C'est la raison pour laquelle de nombreuse personnes déconseillent ce tutoriel, par tu risque d'assimiler le C++ aux C avec des classes.

[Matt_Houston]

Le C et le C++ sont deux langages très différents (d'autant plus depuis les normes C++11 et suivantes). Je te conseille de te focaliser sur un seul d'entre eux et de fuir les cours et tutoriels qui les amalgament.

Si c'est plutôt la programmation système qui t'intéresse, regarde également du côté de Rust a.k.a. C++ done right (je plaisante.. à moitié ).

[wil31]

ok merci de vos eclaircissement

[Obsidian]

Bonjour,

Le C et le C++ sont deux langages très différents (d'autant plus depuis les normes C++11 et suivantes). Je te conseille de te focaliser sur un seul d'entre eux et de fuir les cours et tutoriels qui les amalgament.

Je vais modérer cela un peu car c'est effectivement la tendance dominante de ces dernières années. C'était justifié à un moment où on voyait vraiment beaucoup trop de programmes mélangeant les deux langages au sein d'un même code source (ce qui veut dire que c'est possible, ce qui n'est pas anodin quand on ne sait pas encore précisément de quoi il s'agit) mais laisser croire qu'ils ont toujours été fondamentalement distincts comme peuvent l'être le PHP et le Javascript, par exemple, n'est pas totalement exact non plus.

À titre personnel, je suis heureux aujourd'hui, d'avoir appris les deux langages, et d'avoir vu le C puis le C++.

Donc, fuir les tutoriels qui confondent vraiment les deux, je suis d'accord. Par contre, je soutiens toujours les cours qui commencent par présenter ce qui est commun aux deux et qui font clairement le distingo ensuite, quitte à se focaliser après sur des cours propres à chaque langage. Ensuite, « commencer directement par le C++ » laisse à penser que le C++ est l'évolution logique du C et que celui-ci serait donc aujourd'hui « une branche en fin de vie ». On sait tous qu'il n'en est rien.

D'une manière générale, je suis opposé à toute approche qui impliquerait forcément l'exclusion d'un langage.

[wil31]

ok donc je peu apprendre le c et ensuite le c ++.
je veux dire par la qu'apparament le plus gros souci serait que quand je passerai au c++ je risque de prendre les habitudes du c ce qui apparement n'est pas top en c++,tout du moins au debut?
mais aprrendre les deux languages ne serait donc pas une erreur ?.
donc apparement open class room ne serais pas top,pourtant chaque language est aborder dans deux tutoriel bien distinct.

[Obsidian]

ok donc je peu apprendre le c et ensuite le c ++.
je veux dire par la qu'apparament le plus gros souci serait que quand je passerai au c++ je risque de prendre les habitudes du c ce qui apparement n'est pas top en c++,tout du moins au debut?

C'est surtout à cela qu'il faut veiller. Étant donné que tu es prévenu dès le départ, ce sera beaucoup plus facile.

Si tu choisis d'apprendre le C puis le C++, le mieux est de reprendre ensuite le cours de C++ depuis le début, en faisant éventuellement les exercices proposés, dans l'ordre. Tu reconnaîtras facilement ce qui est commun aux deux langages, par exemple le format et le traitement des nombres, ainsi que la syntaxe des opérateurs (tant qu'ils ne sont pas redéfinis).

mais aprrendre les deux languages ne serait donc pas une erreur ?.

Le C est encore extrêmement répandu, pour plusieurs raisons : d'abord il est extrêmement proche du fonctionnement réel de la machine et à ce titre, il est adapté à la production de code exécutable autonome en langage machine autonome, libre de tout framework ou dépendance si c'est nécessaire. Ensuite, sa grammaire est « relativement » simple, si bien qu'un compilateur C peut être développé à coût raisonnable pour pratiquement n'importe quelle architecture, que ce soit un micro-contrôleur exotique ou une machine grand public.

Ensuite, le C est intimement lié aux systèmes UNIX car il a été développé par les mêmes auteurs. Toute l'API système UNIX et POSIX est en C et par extension, la majorité des applications écrites pour les unixoïdes le sont également, notamment les projets GNU et Linux.

Windows a également une très large API C même si, chez Microsoft, on rencontre beaucoup de langages différents dans les différents composants proposés avec le système d'exploitation. Beaucoup de C++, mais également C# .Net, qu'ils ont développés.

Ensuite, il faut savoir qu'un certain nombre de personnes sont également revenues du C++. Non pas parce que le C++ est un mauvais langage, au contraire, mais parce que la complexité induite sur des grands projets devenait telle qu'elles préféraient gérer de façon théorique la relation objet entre les différentes instances de ce qu'elles déclaraient en C. Et cette approche est beaucoup plus fréquente qu'on le croit. Par exemple, ce célèbre troll débat concernant l'usage éventuel du C++ au sein du noyau Linux. Linus a vertement rembarré le primo-postant (qui l'avait bien cherché) avec sa verve habituelle. Pas besoin d'être aussi extrémiste, bien sûr, mais exclure l'examen du C est généralement révélateur d'une méconnaissance du sujet.

donc apparement open class room ne serais pas top,pourtant chaque language est aborder dans deux tutoriel bien distinct.

C'est le cas ici également, avec des forums distincts et des ressources pour chacun d'eux. La rubrique les regroupe car il s'agit bien de la même famille, quoi qu'on en pense, mais elle se subdivise immédiatement en deux sections distinctes, avec chacune leurs cours, leur forums, leurs collections de programmes sources, et leur guerres de clochers.

La chose qui m'ennuie fondamentalement avec les approches type Think in C++ qui sont largement reprises par les gens qui ont choisi de s'adonner à 100 % au C++ est qu'elle implique souvent d'étudier ses composants de façon totalement théorique en faisant une abstraction totale des coûts qu'ils impliquent.

L'exemple le plus criant à mon goût est celui qui recommande de ne jamais utiliser les tableaux « [ ] » trop « à la C », mais de toujours recourir à std::vector<> à la place. Moi, ça me fait bondir. Ça peut avoir de l'intérêt si on espère que cette classe va gérer intelligemment un tas pour faire ses allocations, mais on ne peut pas comparer un tableau, qui est simplement une manière élégante de déclarer plusieurs instances d'un même type de façon consécutive pour pouvoir les indexer, à une classe comme std::vector qui est un objet managé, qui s'appuie sur beaucoup de code sous-jacent, entièrement stateful, dépendant du contexte à l'exécution et qui consomme des ressources.

Ça reste justifié quand on sait pleinement de quoi il s'agit et que l'on choisit délibérément de s'appuyer sur un framework donné et de rester dans un certain périmètre. Le problème est qu'on ne sait jamais si son interlocuteur est pleinement conscient de ses choses-là ou si, au contraire, cela ne lui est jamais venu à l'esprit.