Discussion :

[foetus]

Quand le mec dit que le C est mieux que le C++ pour son kernel pour ensuite nous répondre que le C++ est un langage casse-gueule niveau sécurité, c'est l’hôpital qui se moque de la charité. J'ai juste l'impression que Linus a une dent contre le C++, sans jamais donner un seul argument autre qu'un bon "C'est de la merde" kaamelottien ou Coffien.

Effectivement, Linus Torvalds : "C++ est un langage horrible", 2011 lien developpez.net

[walfrat]

Disons que si on lit a travers les insultes, moi je comprend ça :

• Ca critique concerne le C++ dans le cas de problème pointu de très bas niveau.
• Cette critique affirme que ce langage ne résout pas des problèmes qui existent déjà en C DANS le cadre de ce besoin mais en rajoutent même.
• L'usage des librairies STL/Boost dans le cadre de ce que fait Linus n'est pas nécessairement approprié quand tu vises un très haut niveau de performance sur des problématiques de bas niveau. Hors il y a beaucoup de développeurs qui se contentent d'utiliser les fonctions des librairies sans vraiment en comprendre les limites, ce qui est gênant quand tu veux faire quelque chose de vraiment pointu. En soi ce n'est pas la faute du C++ mais pour Linus c'était une façon de filtrer plus facilement des développeurs.

C'est ce qu'il affirme, les aficionados savent mieux que moi ce qu'il en est.

[freesket]

C++ est "crap" car il ajoute de la complexité au C car/parce que un certain nombre de développeur C++ l'utilise comme du C "with classes" (Linus critique cela et il a bien raison...).

Pour Linus, si nous lisons son commentaire de 2011, il semble même avoir une dent contre l'orienté objet... Du coup Rust/C++ même combat, sauf que Rust garantit la sécurité (c'est suffisant pour Linus ?)...

Jusqu'à maintenant, C++ n'a été pensé que pour la performance, laissant la sécurité aux développeurs...
Ce qui est en train de changer (propos tenus dans la CppCon 2019 je crois). Du coup depuis quelques temps, les outils d'analyses statiques se sont multipliés et sérieusement améliorés.
Je pense honnêtement que Rust pousse le C++ à devenir meilleur et plus sécurisé.

Si l'on regarde côté MS, les outils de vérifications dans VS prennent en charge de plus en plus de cas (cppcorecheck, dangling pointer, use after free, use after move, lifetime...).
Clang propose à peut prêt la même chose via Clang-Tidy (utilisable dans VS ou avec gcc).
CppCheck est aussi intéressant...

Le plus gros problème c'est que ce n'est pas obligatoire... et que les outils sont complémentaires...Il en faut plusieurs pour "tout" couvrir (pour le moment) là ou Rust le propose en standard et couvre tous les cas dans du code "safe".

[bizulk]

Jusqu'à maintenant, C++ n'a été pensé que pour la performance, laissant la sécurité aux développeurs...

La performance...
Je pense surtout que l'on voulait ajouter le concept d'objet au C, ainsi que la généricité (template), sans trop y perdre en performance.
Mais tu casses facilement les perfs avec des itérateurs, comparé au C, sans y gagner sur d'autres critères.

L'objectif est toujours d'avoir une complexité maîtrisée, et je pense qu'avec quelques bonnes règles on aurait pu avoir du C++ dans le noyau. Mais aurait on eu une complexité mieux maîtrisée qu'avec la conception actuelle du noyau j'en sais rien. Linus paraît savoir

J'ai besoin de me rafraîchir avec un nouveau langage adapté pour l'embarqué introduisant des concepts plus moderne, et pour cela Oui le RUST semble définir un bon compromis, vu de loin comme ça...

[Invité]

La performance...
Je pense surtout que l'on voulait ajouter le concept d'objet au C, ainsi que la généricité (template), sans trop y perdre en performance.
Mais tu casses facilement les perfs avec des itérateurs, comparé au C, sans y gagner sur d'autres critères.

Il y a des tests sérieux qui montrent cela ?
Perso, j'ai entendu le contraire : que C++ faisait des zero-cost abstraction et était généralement aussi rapide que C voire plus rapide, grâce aux templates.
http://theory.stanford.edu/~amitp/rants/c++-vs-c/
https://stackoverflow.com/questions/...ort-vs-stdsort

[walfrat]

As I expected, STL’s sort ran faster than C’s qsort, because C++’s templates generate optimized code for a particular data type and a particular comparison function. STL’s sort also ran faster than the hand-coded quicksort routine, and it ran faster than the special-case library routine. (However, this may simply be unique to sorting, and may not extend to other algorithms.)

Il semblerait que certaines partis soit définitivement plus optimisées, mais ce n'est pas celle là qui intéresse Linus je pense.

En outre vu que le compilo fait des cas optimisés pour chaque type, cela doit nécessairement coûté quelque part, genre la taille de l'exécutable et donc le minimum de RAM qu'il prend, potentiellement gênant pour du système.

[Invité]

Il semblerait que certaines partis soit définitivement plus optimisées, mais ce n'est pas celle là qui intéresse Linus je pense.

Le sujet c'était les performances de C vs C++. Désolé mais tout ne tourne pas autour de l'avis de Linus...

En outre vu que le compilo fait des cas optimisés pour chaque type, cela doit nécessairement coûté quelque part, genre la taille de l'exécutable et donc le minimum de RAM qu'il prend, potentiellement gênant pour du système.

Oui, le template est instancié pour chaque type utilisé; les generics de rust fonctionnent probablement de la même façon. Le principal inconvénient c'est le temps de compilation. Pour la taille de l'exécutable, je doute que le surcout soit génant, à moins de programmer des microcontrolleurs des années 70.

[walfrat]

Le sujet c'était les performances de C vs C++. Désolé mais tout ne tourne pas autour de l'avis de Linus...

Mon post était toujours dans le contexte où l'on parlait de Linus disait que le C++ était "crap".

Oui, le template est instancié pour chaque type utilisé; les generics de rust fonctionnent probablement de la même façon. Le principal inconvénient c'est le temps de compilation. Pour la taille de l'exécutable, je doute que le surcout soit génant, à moins de programmer des microcontrolleurs des années 70.

Dans le cadre d'une application je suis d'accord, dans le cadre du noyau Linux ou un module système, je n'en ai franchement aucune idée.

[Invité]

Mon post était toujours dans le contexte où l'on parlait de Linus disait que le C++ était "crap".

C'est bien.

Mais moi je répondais à ce post, sur le C++ :

La performance...
Je pense surtout que l'on voulait ajouter le concept d'objet au C, ainsi que la généricité (template), sans trop y perdre en performance.
Mais tu casses facilement les perfs avec des itérateurs, comparé au C, sans y gagner sur d'autres critères..

[LittleWhite]

Pour la taille de l'exécutable, je doute que le surcout soit génant, à moins de programmer des microcontrolleurs des années 70.

Sachant que le noyau Linux est utilisé dans de l'embarqué, la taille peut avoir une importance.

[walfrat]

Je plussoie, mais cette phrase que tu cites n'étais pas de moi

[Invité]

Sachant que le noyau Linux est utilisé dans de l'embarqué, la taille peut avoir une importance.

Tout à fait. Le C++ est vraiment un langage de merde mais heureusement Rust va nous sauver de tous ces problèmes, Linux va enfin percer sur le desktop, le covid disparaitre et le réchauffement climatique s'arrêter. Merci Rust, merci Linus.

[L33tige]

OooooooF

[moldavi]

Jusqu'à maintenant, C++ n'a été pensé que pour la performance, laissant la sécurité aux développeurs...

Le C++ a introduit le try/catch, donc dire que que le C++ n'a été pensé que pour la performance, est une complète méconnaissance de ce langage.

Pour les failles de sécurité, dont celle SSL, peut-être que beaucoup de développeurs C++ n'auraient pas fait la même bêtise que d'utiliser des Goto en C...

Tout à fait. Le C++ est vraiment un langage de merde mais heureusement Rust va nous sauver de tous ces problèmes, Linux va enfin percer sur le desktop, le covid disparaitre et le réchauffement climatique s'arrêter. Merci Rust, merci Linus.

J'adore cette dose d'ironie.

Et pour en rajouter une couche, j'imagine que Linus Torvalds touche des subventions de Mozilla Rust, et pas de C++.


Du coup, il dit que Rust, bien, et C++, pas bien.

Le jour où C++ donnera du pognon à Linus Torvalds, il dira que C++, c'est bien. Mais bon cela n'arrivera jamais, le C++ est un vrai projet opensource altruiste.

Ce mec n'a aucune objectivité, et ses arguments contre le C++ sont du niveau maternel.

[air-dex]

Je dirais qu'il n'y a rien d'interdit en Rust ou en C++.
Rust a clairement des atouts côté analyse statique de code et outils ( ownership, lifetime, module, cargo, rustc... )
Mais C++ a un nombre de libraires (opensource ou pas) hallucinante et Rust mettra des années à rattraper ça. Quasiment TOUT les logiciels ont des API soit C ou C++. Alors oui on peut binder mais C++ le fait en toute transparence comme si c'était le même langage.
Ensuite C++ a les templates et Rust est très loin de pouvoir faire autant de chose que C++ à la compilation. Il vient tout juste d'avoir des const generics en "minimal viable product".
C++ évolue aussi, plus lentement car c'est une TRÈS grosse machine implanté partout dans le monde et ils ont le problème de la rétrocompatibilité, mais ça fait son chemin, C++ 20 apporte les modules, les concepts,...

Personnellement j’attends quelque chose qui est loin d'être accepté encore c'est la "Uniform Function Call Syntax" qui permet a terme de faire comme les traits Rust... mais c'est pas gagné avec les boomers du C++ qui n'ont pas compris qu'il n’était pas QUE objet

Rust a aussi compris l'importance du SDK standard dans un langage moderne. Aujourd'hui un langage ne vient plus seul. Il a déjà un compilateur ou un interpréteur (encore heureux ), mais aussi tout une kyrielle d'outils pour le développeur : générateur de documentation, débogueur, aide au formatage des sources, gestion des dépendances tierces via des gestionnaires de paquets, extensions pour être supporté dans les EDI populaires (VS Code, IntelliJ...), outil de gestion d'un projet avec le langage... Rust ne serait pas ce qu'il est sans Cargo (et rustup), tout comme Node n'en serait pas là sans NPM. Même Python a fini par y venir avec PIP, à l'instar de PHP avec Pear puis Composer.

C++ n'a pas tout ça. Certes il existe des suites d'outils complètes, mais dans le fond aucune d'entre elle n'est profondément rattaché au C++ standard. "Visual C++" de Microsoft (peut-on encore utiliser ce terme pour désigner les outils développeurs de MS pour C++ ?) n'est pas rattaché au C++ standard comme Cargo l'est avec le "Rust standard". Le développeur C++ va se bricoler une stack, probablement à base de Doxygen, CMake et Make qui aussi talentueux soient-ils n'ont pas été conçus pour travailler en parfaite synergie, là où Rust en fournit directement une bien synergisée quand on "télécharge le langage". Je pense qu'en tant que développeur cela peut faire la différence, surtout en 2021.

[Invité]

Rust a aussi compris l'importance du SDK standard dans un langage moderne. Aujourd'hui un langage ne vient plus seul. Il a déjà un compilateur ou un interpréteur (encore heureux ), mais aussi tout une kyrielle d'outils pour le développeur : générateur de documentation, débogueur, aide au formatage des sources, gestion des dépendances tierces via des gestionnaires de paquets, extensions pour être supporté dans les EDI populaires (VS Code, IntelliJ...), outil de gestion d'un projet avec le langage... Rust ne serait pas ce qu'il est sans Cargo (et rustup),...

Rust a un compilateur, un débogueur, un générateur de doc, etc... ça alors mais quel exploit ! C'est vraiment le seul langage du monde à faire ça...
Et du coup c'est quoi la commande cargo pour intégrer et réutiliser une lib C ou fortran ?

[Jiji66]

Le C++ a introduit le try/catch, donc dire que que le C++ n'a été pensé que pour la performance, est une complète méconnaissance de ce langage.
................

Le problème vient du fait que faire de la programmation Object sur cible matérielle n'est pas forcément adapté.

[moldavi]

Le problème vient du fait que faire de la programmation Object sur cible matérielle n'est pas forcément adapté.

Cela fait un bail qu'il est possible de coder dans un pseudo C++ des microcontrôleurs (par exemple MBED).

[Uther]

Et pour en rajouter une couche, j'imagine que Linus Torvalds touche des subventions de Mozilla Rust, et pas de C++.

Magnifique accusation gratuite d'un truc absolument improbable. Mozilla n'a rien a gagner a l'utilisation de Rust dans Linux, en tout cas certainement pas au point de payer Linus qui a l'air de tout sauf d'une personne facile a acheter, sachant qu'au contraire, il s'est désengagé financièrement de Rust, dont il n'est plus du tout le plus gros sponsor.
Linus Torvalds n'a pas attendu Rust pour dire du mal de C++ et il ne dit pas non plus que Rust destiné a prendre la place du C. Il dit juste qu'il résout des problèmes intéressants au niveau sécurité que le C++ ne résout pas aussi efficacement et qu'il est d'accord pour l'expérimenter.

Rust a un compilateur, un débogueur, un générateur de doc, etc... ça alors mais quel exploit ! C'est vraiment le seul langage du monde à faire ça...

C'est pas le seul a faire ça, loin de là, mais le fait qu'ils soient bien intégré rend leur usage bien plus naturel. C'est particulièrement important pour cargo car l'absence de dépôt de référence complique vraiment leur adoption en C++.

Et du coup c'est quoi la commande cargo pour intégrer et réutiliser une lib C ou fortran ?

Pour la plupart des bibliothèques C qui n'ont pas un équivalent Rust, il y a un wrapper disponible dans crates.io (le dépôt standard de cargo), donc ont les ajoute comme n'importe qu'elle dépendance Rust, en une ligne dans le fichier de config du projet.

C'est vrai que si le wrapper n'existe pas encore, c'est plus compliqué, mais il y a des outils pour les générer automatiquement.

De nos jours, crates.io est vraiment bien fourni et il est de plus en plus rare que je ne trouve pas ce que je cherche dedans.

[Jiji66]

Cela fait un bail qu'il est possible de coder dans un pseudo C++ des microcontrôleurs (par exemple MBED).

Il est possible de programmer en pseudo "languages-trucs" beaucoup de choses; cela ne justifie pas pour autant d'affirmer que l'ajout d'une couche d'abstraction "object" améliore l’efficacité ou la compréhension intime de ce qu'il se passe au niveau du matériel.