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.

[wil31]

merci de toutes ces precisions donc je vais continuer sur ma lancer et apprendre ces deux languages

[sambia39]

Bonjour

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

Le langage C est un langage de programmation système destiné à concevoir des logiciels système ou programmes de base qui sont destinés à faire partie du système d’exploitation d’un ordinateur ou qui en réalisent les fonctions. On dit de lui, un langage de programmation système pour cette raison.

Le rust, pour moi, est le langage obscur à syntaxe louche (python, java, c++) dit langage de programmation système par abus de langage (si je peux le dire sans frustrer les adeptes de ce langage) dont l’origine est de remplacer le C++ grâce à une meilleure gestion de mémoire dite plus sûre.

Personnellement, mon conseil serait d’apprendre le langage C puis ensuite passer en langage C++ et non les deux à la fois et d'oublier le rust comme suggéré par Matt_Houston (c'est mon avis) .
Pour faire de la programmation système pure et dure, le langage C est largement suffisant et pour finir j’appuie les remarques de Obsidian.

À bientôt.

[wil31]

merci.
c'est ce que j'ai decider de faire.

[Matt_Houston]

J'apprécie toujours de lire la prose très argumentée d'Obsidian sur ce genre de sujet.

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

Il est évidemment toujours préférable de savoir plutôt que de ne pas savoir - bien qu'à en choisir un, mieux vaut connaître le C et le fonctionnement de la machine. Ce que j'essayais d'exprimer c'est qu'il faut bien, comme tu l'as précisé, garder en tête que ces deux langages ont des applications différentes. On a trop longtemps entendu que le C++ était l'évolution naturelle du C, il faut faire la pédagogie inverse.


Le rust, pour moi, est le langage obscur à syntaxe louche (python, java, c++) dit langage de programmation système par abus de langage (si je peux le dire sans frustrer les adeptes de ce langage) dont l’origine est de remplacer le C++ grâce à une meilleure gestion de mémoire dite plus sûre.

Je n'ai absolument rien compris à cette phrase. Que viennent ici faire Python et Java qui sont des technologies managées ? As-tu déjà écrit un programme Rust ? Ne serait-ce qu'un hello world ? En quoi serait-il impossible d'utiliser Rust pour écrire un morceau de noyau ? Un allocateur ? Un driver ?

[sambia39]

Bonsoir

Je n'ai absolument rien compris à cette phrase. Que viennent ici faire Python et Java qui sont des technologies managées ? As-tu déjà écrit un programme Rust ? Ne serait-ce qu'un hello world ? En quoi serait-il impossible d'utiliser Rust pour écrire un morceau de noyau ? Un allocateur ? Un driver ?

Je pense que je n’ai pas été clair. 

Je ne parle pas de technologie managée mais de langage et de syntaxe. J’ai écris "langage obscur à syntaxe louche (python, java, c++) " c'est-à-dire que certaines de ces syntaxes, tout comme la façon dont la structure de code est présentée, s’apparente de loin ou de près aux syntaxes des langages comme le python, java ou le C++.

A la question suivante: "As-tu déjà écrit un programme Rust ?", je vous réponds que oui, j’ai déjà eu l’occasion d’écrire certains programmes rudimentaires en RUST dans sa version 0.8 et sur l’expérience que j’ai eue de ce langage, je peux affirmer que j’ai du mal à me familiariser avec les syntaxes de ce langage et je n'est jamais dit qu'avec rust, on ne peut pas écrire un noyau ou des drivers. Mais que pour moi, c'est un abus de langage de dire que c'est un langage de programmations système à part entière (sachant que c'est un langage multiparadigme de base) et qu'à ma connaissance, je ne connais aucun noyau ou drivers écris en rust (désolée).

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

Ce qui est sûr, on ne va pas se mettre à apprendre un langage de programmation comme RUST pour faire que de la programmation système sachant qu’avec le langage C, on peut très bien faire de la programmation système tout comme le python à titre d'exemple.

à bientôt

[Luc Hermitte]

Salut,

Je viens rajouter le son de cloche qu'il est difficile de trouver dans un forum C, celui de la communauté C++.

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

Comme d'autres : choisis en un, et pousse loin sa pratique avant de passer à l'autre. Il est important de maitriser les différences.
Si le cours du sdzoc est critiqué par les gens sur les forums, c'est pour plusieurs raisons : ils montrent des choses qui ne servent pas vraiment et qui sont bancales (typiquement copier des objets qui de par leur nature n'ont aucun besoin à être copié, ça complexifie le cours pour rien, et ça montre des pratiques à fuir), une absence criante de présentation du C++11 qui simplifie beaucoup de choses sur le plan pédagogique, mais aussi en utilisation industrielle quotidienne, le RAII (idiome majeur du C++ à cause de ses exceptions ; idiome qui fait que l'on radote à dire qu'il vaut mieux voir le C après) qui n'est pas abordé comme il se devrait, et d'autres trucs.

Ce que l'on dit dans les forums de C++, c'est qu'il y a un ordre qui est pédagogiquement parlant plus simple pour l'apprenant. Dans cet ordre que l'on préconise, la gestion de la mémoire est reléguée vers la fin de l'apprentissage, ou au pire au milieu -- et la partie pure C vers la fin aussi. On va jusqu'à dire que ce n'est pas un sujet pour débutants. Un cours de C lui devra obligatoirement aborder la mémoire dès les premiers chapitres pour : les tableaux, les chaines de caractères, toutes les fonctions qui ont des paramètres sortants (le décrié scanf(), et bien d'autres).

Je rappelle à ce sujet qu'un code correct en C devrait pratiquer un test après toute fonction qui pourrait échouer (à commencer par malloc). Grosso modo, il y a pratiquement un if toutes les deux lignes. Cf le critère de détection rapide des codes pourris par Raymon Chen. I.e. un code C correct ressemblera à ce qui est tout en bas à gauche de cette page : http://alexandre-laurent.developpez....ou-exceptions/

Est-ce le genre de code que l'on montre aux débutants ? Bien sûr que non. C'est trop complexe. Du coup, l'apprentissage du C pour les débutants tend à simplifier les choses et à montrer des mauvaises pratiques. C'est là que la communauté C++ fait de la pub en disant "he, mais chez nous, on peut enseigner des codes simples et corrects aux débutants, et ce sans avoir à rentrer dans des détails abscons de gestion de la mémoire qui ne concernent pas ces débutants qui ont déjà bien assez à faire avec la découverte de l'algorithmie". Bref, la communauté C++ dit que le C++ est pédagogiquement plus adapté aux débutants que le C. Ce n'est pas encore Ada, Pascal ou Python, mais c'est déjà mieux.

A noter un autre détail d'importance qui fait que la communauté C++ critique les ressources communes C & C++ pour débutants. Même si le débutant à appris à coder correctement en C (on n'y croit pas un seul instant, mais faisons semblant), et qu'il fait des codes parfaits sans fuites ni dangling ressources, ce code ne sera malheureusement pas bon en C++ à cause des exceptions qui vont changer toute la donne.
TD;LR les bonnes pratiques du C (relativement à la gestion des ressources) ne sont pas applicables au C++.
Et vice-versa vu que le RAII n'existe pas en C, au mieux, c'est une extension de gcc.

C'est pour ça que l'on recommande de se concentrer sur l'un. Et de voir l'autre bien après et en oubliant pratiquement tout ce que l'on a vu dans l'autre. Autant dire que s'il y a un objectif avoué de faire du C++ au final parce que l'on pense/croit que c'est une évolution du C, autant être efficace et sauter la case C.

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

b- 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- Il faut chercher d'autres raisons dans le troll de Torvald.

Des conceptions OO ou procédurale, on peut en faire en C comme en C++. On peut faire n'importe quoi, comme s'y prendre correctement.

J'ai croisé exactement le problème inverse il n'y a pas si longtemps : un code C avec une vague tentative d'abstraction qui est compliquée au possible parce que les structs sont visibles de tous (et donc altérables par tous), et de fait il y avait de la programmation défensive à tous les étages. Soit un truc in-maintenable qui plombait les performances au passage.
Ce genre de choses:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
enum class Code { OK, NOK };
 
struct Image
{
    double *    pixels;
    std::size_t nb_pixels;
};
 
Code get_size(Image const* im, std::size_t * size)
{
    if (!im || !size)
        return Code::NOK;
    *size = im->nb_pixels;
    return Code::OK;
}
 
Code get_pixel(Image const* im, std::size_t idx, double * pixel)
{
    if (!im || !im->pixels || !pixel)  return Code::NOK;
    std::size_t size;
    Code c = get_size(im, &size);
    if (c != Code::OK)                 return c;
    else if (idx >= size)              return Code::NOK;
    else {
        *pixel = im->pixels[idx];
        return Code::OK;
    }
}

Avec une bonne gestion des invariants (truc pour lequel le C++ offre des sucres syntaxiques avec ses classes -- sinon, cf struct FILE en C), le code se simplifie de suite, et on récupère des performances.
Cf à ce sujet une présentation récente: https://www.youtube.com/watch?v=PDSvjwJ2M80

b- Pas vraiment, toute la SL est définie en termes de complexité algorithmique. Dans les cours que je donne, c'est un des éléments que je montre.
Après, entre un vecteur et un tableau dynamique à la C, le seul surcoût, c'est la 0-intialisation avec resize(). Franchement, ce n'est pas grand chose -- c'est le même coût que calloc(). En termes de vitesse et parfois même de code assembleur, il n'y a pas de différence sur les opérations d'accès. A propos de différence sur les abstractions, cf les premières planches/minutes de la video dont je viens de donner le lien au dessus. Comme quoi.
(Je vais aussi passer sur realloc que je n'ai jamais vu un débutant savoir utiliser correctement -- quand ce n'est pas dans des vrais codes qu'on le trouve mal employé)

Si on ne veut pas payer la 0-initialisation, on a std::array<> (en place de []), et std::unique_ptr<> dans lequel on peut mettre un tableau dynamique. Le débutant n'a pas besoin de ça. std::vector est une bonne approximation qui offre des performances plus que correctes. On peut aussi lui parler des abstractions mathématiques pour vecteurs et matrices disponibles dans des bibliothèques tierces. Si après benchmark on mesure que la 0-intialisation a un coût intolérable, on pourra alors se rabattre sur autre chose que std::vector.
Dans tous les cas, un T* qui se ballade dans les signatures de fonctions ou dans les variables locales ou membres, c'est une fuite qui attend de se produire en C++ (à cause des exceptions, je me répète), donc clairement oui, montrons d'abord std::vector<> et std::string aux débutants. En fin de cours, on pourra leur montrer comment c'est foutu dedans. Si tant est qu'ils aient vraiment besoin de l'info...

Bref. c'est de nouveau un faux argument. Toutes les abstractions ne coutent pas (voire, cela peut s'avérer être le contraire), et de plus, ce n'est pas un sujet pour un débutant. Laissez le d'abord faire un peu d'algo.

[jlliagre]


Le rust, pour moi, est le langage obscur à syntaxe louche (python, java, c++) dit langage de programmation système par abus de langage (si je peux le dire sans frustrer les adeptes de ce langage) dont l’origine est de remplacer le C++ grâce à une meilleure gestion de mémoire dite plus sûre.

Python, java et C++ sont des langages de programmation système ??

L'origine du C++ est de remplacer le C++ ??

[Sve@r]

L'origine du C++ est de remplacer le C++ ??

Exactement. Tout comme php inclus "php" dans son acronyme (acronyme récursif, qu'on observe aussi dans "GNU" ou "BING" ou beaucoup d'autres), C++ remplace C++. On parlera alors ici d'un remplacement récursif. Peut-être est-ce la naissance d'un nouveau modèle...