C ou c++

Pourquoi ces deux-là en particulier ?

mdr

rigolo, j’ai fait exactement la même analogie ce matin. il serait temps que le C soit enseigné comme on enseigne le latin au ⅩⅪᵉ siècle : en cours d’Histoire.

@ Algue‐Rythme, j’espérais des vraies réponses constructives, mais merci pour ta contribution de qualiter.

Oui et non. Le C++ moderne ne t'invite pas à faire réellement la distinction entre la pile et le tas et leurs caractéristiques, ou la définition des symboles dans un exécutable… Du moins ce n'est pas dans le chemin critique de l'apprentissage du C++.

Si le but est d'apprendre un langage moderne, professionnel, complexe mais payant, qui compile en natif et qui permet de descendre très bas dans les niveaux d'abstraction, alors clairement c'est plutôt vers C++ qu'il faut se diriger.

Si au contraire l'idée est d'apprendre le langage natif d'où découlent (une bonne partie de) tous les autres, de comprendre le fonctionnement d'un exécutable, les problématiques de compilation, de traçage, de débogage, les appels système, et le fonctionnement de la mémoire, afin de bénéficier de cette culture lors de l'apprentissage de tous les autres langages (Python, C++, Rust, Go, D…) afin de mesurer leur apport d'un oeil éclairé, ou s'initier au fonctionnement de son OS en passant par la couche pratiquable¹ la plus fine possible, alors un passage par le C est loin d'être déconnant.

Je rappelle que le latin n'est pas une langue morte, mais bien une langue ancienne qui est la langue officielle d'un État : le Vatican. Elle est donc toujours employée de nos jours (bien qu'il ne s'agisse évidemment plus du latin classique). Un langage ne fait partie de l'Histoire qu'une fois qu'il n'est plus employé et n'a plus de locuteurs (le B est par exemple un langage historique) or, de ce côté, ce n'est certainement pas le C qui a le plus de soucis à se faire.

Sinon, afin d'être tout de même constructif, j'abonde dans le sens de nohar.

Si je souhaite apprendre le c ou le c++ est car généralement la connaissance de ces langages est très conseillée(obligatoire ?) dans le domaine de la sécurité ou du moins pour la compréhension des failles applicatives, mais aussi car le c++ et ses qualitées m'intéresse beaucoup, faculté de gestion de la mémoire, rapide, stable, POO etc ..

D'ailleurs si il y a des adeptes de la sécu ici, quelques conseils ne seraient pas de refus sur ce point

D'ailleurs si il y a des adeptes de la sécu ici, quelques conseils ne seraient pas de refus sur ce point

Conseil n°1 : ne pas utiliser des langages dont la compilation ne t'apporte aucune garantie sur l'exécution si tu veux écrire un programme sécurisé.

Si tu souhaites vraiment t'attaquer à la sécurité informatique et plus particulièrement aux failles des logiciels, le C ou le C++ pourront effectivement t'offrir un bon début, mais tu n'échapperas dans ce cas pas à l'Assembleur.

Conseil n°1 : ne pas utiliser des langages dont la compilation ne t'apporte aucune garantie sur l'exécution si tu veux écrire un programme sécurisé.

Si tu souhaites vraiment t'attaquer à la sécurité informatique et plus particulièrement aux failles des logiciels, le C ou le C++ pourront effectivement t'offrir un bon début, mais tu n'échapperas dans ce cas pas à l'Assembleur.

Je ne sais pas très bien ce qu'est une "compilation ne t'apporte aucune garantie sur l'exécution" (un compilateur qui génère du binaire aléatoirement ?), mais au vue des nombreuses failles qui ont persisté pendant des années alors qu'elles étaient bien connues (comme les buffer overflow ou les string injection), j'aurais tendance a dire que pour éviter des fuites de sécurités, il vaut mieux un langage plus haut niveau (qui va proposer des fonctionnalités sécurisées et suffisamment testées/prouvées) qu'un langage bas niveau où il faudra tout réécrire à la main (en partant du principe où celui qui se croit plus fort que les autres est généralement celui qui fait le plus de conneries).

Si c'est pour apprendre la sécurité informatique, alors peut importe entre le C et le C++ (et bof l'assembleur - EDIT: après réflexion, ok pour l'assembleur. Il y a effectivement une grosse partie du boulot de "hacking" qui consiste à analyser les binaires. Mais pas besoin de maîtriser l'assembleur, il faut juste avoir les bases pour décompiler un programme). Apprendre la sécurité, c'est beaucoup de boulot, mais pas forcement de la programmation. Cela ne demande pas des compétences très poussées dans un langage en particulier, cela demande plutôt des connaissances dans des langages très divers (et en fonctionnement des ordinateurs et des systèmes).

Les compilateurs C et C++ sont pour ainsi dire systématiquement tout cassés et produisent des exécutables qui ne sont pas toujours conformes à ce qu'on écrit. En particulier quand ils optimisent. Typiquement, ils peuvent faire des trucs du genre : remplacer une dealloc/alloc par un noop et provoquer des situations un peu tordues. Et avec les modèles concurrents c'est encore pire.

Actuellement, le seul compilateur qui peut vraiment donner des garanties c'est Compcert, et pour le coup il reste des choses du standard C qui ne sont pas supportées et il faut faire confiance sur le fait que la formalisation est correcte (sur ce point, on peut être partagé : les gens qui l'ont faite sont pas des manches, mais C, c'est un beau bordel).

pour ainsi dire systématiquement tout cassés et produisent des exécutables qui ne sont pas toujours conformes à ce qu'on écrit

Dans la phrase initiale, Eusèbe parle des langages "dont la compilation ne t'apporte aucune garantie sur l'exécution" (et donc sous entend qu'il y a des langages qui apportent des garanties de ce côté).

Alors, je sais bien qu'il existe des langages plus fiable que les autres (mais qui serait assez fou pour bosser dans la vérification formelle ? ), mais 99% (au pifomètre) des langages utilisés au quotidien (même dans les domaines critiques) ne remplissent probablement pas ce critère.

Cela fait partie aussi du boulot de faire de la sécurité avec les outils imparfaits que l'on utilise. (Mais bon, ok, je te l'accord : il est possible d'utiliser des langages plus fiables que les autres).

oui, c’était le sens de ma remarque : tout comme le latin, l’intérêt du C est culturel : le latin m’a fait mieux comprendre l’étymologie des langues latines, mais c’était clairement non nécessaire pour parler français¹. et, à l’instar du latin, le C est un bon prétexte à un cours d’Histoire.

ceci dit, c’est vrai que faute de consensus suffisant (le monde de l’informatique pourra‐t‐il seulement se mettre d’accord un jour ?…), le C en est encore au statut de lingua franca.

je ne suis pas convaincu cependant de la nécessité technique du C. libre à nous de créer d’autres abstractions — la machine virtuelle Java en est un exemple. pour tout ce que tu cites, il suffit de comprendre le modèle d’exécution de son langage, qui peut d’ailleurs être tout autre que celui du C.

Je penche plutôt pour de l'ironie (à cause du «  » ). Il ne faut pas voir le mal partout.

Ksass`Peuk prépare un doctorat sur la vérification formelle, donc devine…

(cela étant dit, cela n'exclut pas de l'ignorance et de la suffisance standard )

Voilà, en fait c'était pas difficile : tu as vraisemblablement besoin de comprendre les détails bas niveau auxquels C va te confronter, mais il ne faut pas que ça t'empêche d'apprendre un langage plus évolué (comme C++) pour d'autres applications. Finalement tu peux regarder les deux langages, comme ça tu pourras répondre tout seul à la question que tu te posais.

Waow, ça aurait été tellement plus productif que quelqu'un te pose cette question d'entrée de jeu.

Encore une fois. Ce n'est pas parce que le C impose de manipuler des choses "bas-niveau" (malloc et autres tableaux statiques, plus exclusivement gestion manuelle des bornes pour éviter des débordements) que le C++ ne le permet pas. C'est même ce que les mauvais cours de C++ enseignent aux débutants.

La question de l'ordre d'apprentissage reste entière. Et là, si C++ et C sont des objectifs, la communauté C++ en-ligne te dira C après.