Du C++ dans le noyau Linux ?! Torvalds en PLS ! 

Merci pour le feedback 👌🙏

Merci beaucoup ! Heureux que mes lives plaisent ❤️

Complètement car BeOS était déjà fin des années 90 un OS écrit majoritairement en C++. Par contre pour le noyau même de BeOS à l'époque je ne sais pas

Non, ce n'est pas possible car il faudrait notamment embarquer une VM java et toute l'infrastructure pour la faire fonctionner. Personne n'a envie de ça 😅

Merci 🙏

Je n'ai pas tellement d'avis concernant les IDE, vu que je travaille avec vim. Cela peut être VS code, IntelliJ, RustRover, etc ....

@@ponceto91 ok, merci

Le CP/M était un système plutôt bien conçu et surtout portable 👌

Oui ! Des personnages importants et brillants 👌

Absolument. Tovalds a toujours été très réticent au C++, certaines raisons étant justifiées et d'autres non, comme je l'expliquais dans le live. L'expérience de 2007/08 avait échoué car mal portée par les stakeholders, mais depuis C++11 et surtout C++14 apportent une vraie plus value et utiliser un site ensemble cohérent du langage aurait de vrais bénéfices (vraie généricité avec les templates de fonctions, les classes avec un héritage maîtrisé et plus optimal qu'en C, etc ....). Le message de P. Anvin est plein de bon sens

Le temps de compil peut être contrôlé si on met pas tout son code dans les .h 😜

Ce serait tellement un bon point. Mais les mentalités changent, ce point n'est plus aussi rejeté qu'avant, de nombreuses features font sens et qui sont d'ailleurs reprises dans C23

@@ponceto91 Je dois absolument être honnête ici : Je résiste encore beaucoup au C++ "Moderne" car de mon point de vue là ça devient carrément de la "méta-programmation" - i.e: Programmer le compilateur pour générer du code qui du coup (à la fin) devient du code que t'as jamais écris toi-même! 😟

​@@oldlonecoder5843moi j'ai décidé de faire confiance au compilateur pour générer du code plus efficace que le mien 😉 Mais si tu parles des templates, effectivement faut faire gaffe au nombre de fonctions/méthodes générées qui peuvent vite exploser si on fait pas gaffe.

Merci pour le retour. Oui ton point est très juste et c'est pourquoi depuis quelques replays de mes lives Twitch (puisque ce sont des lives Twitch) je mets un titre et je crée une miniature. Mais en effet je vais rajouter les titres majeurs sur la miniature. Merci beaucoup

Merciiii 🙏

On parle d'un sous ensemble de C++, voire un ensemble qui est déjà plus ou moins prévu dans C23 (templating de fonctions, ....). Pour ma part, le passage de C à C++ est moins douloureux que de C à Rust. Mais c'est un point de vue personnel

​@@ponceto91C'est pas personnel, c'est évident vu que la syntaxe est la même 😉

Le code C++ récent ne sera pas *immédiatement* compris par les développeurs C effectivement, mais ça nécessite peu de travail. Alors que le code Rust lu par des devs C, ça va être coton : syntaxe, gestion mémoire, POO... La gestion mémoire en C++ est beaucoup plus sécurisée justement, grâce au move notamment. La durée de vie des objets est beaucoup plus simple à contrôler qu'en C. Peut-être pas exactement au niveau de Rust, mais on n'est pas si loin...

@@matthieulabas le problème de c++ c'est que tu peux toujours faire les mauvais pratiques de c donc ce n'est pas plus utiliser et un truc tout bête afficher un message sur la sortie standard ne se fait pas généralement pareille en c et en c++ c'est pour ça que je trouve que c++ un bien plus qu'un sous ensembles.

@@R.e.n.e oui, à la limite on pourrait comparer le C++ à du unsafe Rust...

👌

Pour le sujet du support matériel, le problème n'est pas le noyau ou les développeurs eux-mêmes, mais bien les constructeurs qui ne font aucun effort pour fournir des pilotes ou bien ouvrir leurs spécifications matérielles aux développeurs. Il faut comprendre que la plupart des pilotes sont développés par reverse engineering et c'est un vrai ralentisseur

Hein ?? Comment ça ? Quelle vidéo ?

@@ponceto91 Celle en franglais 👀

Pour le moment il n'est pas encore question d'introduire du C++ dans le noyau, même si c'est un sujet qui revient régulièrement. Et c'est juste, comme je le dis, ce serait un sous-ensemble restreint du langage qui permettraient une meilleure sécurité et une programmation plus facile de certain sous systèmes

Hello, merci pour ton commentaire. Je vais essayer de revenir factuellement sur chacun de tes points. Génération d'assembleur prévisible en C : C'est assez inexact. Les compilateurs C (notamment GCC) proposent des un code assembleur généré peu prédictible par un humain d'après le code écrit en C, en tout cas à des niveaux d'optimisation -O1/-O2 et plus. Pour t'en convaincre, je te suggère d'utiliser compiler explorer (godbolt.org) et de faire des tests sur des véritables morceaux de code. Les compilateurs modernes font un travail d'optimisation locale et globale exceptionnel, que ce soit en C, C++ ou n'importe quel autre langage. Durabilité du C++ dans le temps : Le C++ est un langage ancien (1983) et très largement utilisé dans l'industrie et de plus en plus et est supporté par des normes extrêmement précises. J'ai travaillé dans différents domaines industriels, dont des systèmes embarqués (je donne des cours en école d'ingénieur dans cette spécialité) et le C++ y est extrêmement présent. Les compilateurs C++ sont disponibles pour l'intégralité des architectures car il n'est pas nécessaire de réécrire à chaque fois un compilateur pour chaque nouvelle architecture, seul le backend de génération de code machine change et pour viser une nouvelle architecture la cross-compilation est utilisée en phase 1 pour générer un compilateur natif. Maintenabilité et taille du code : L'affirmation selon laquelle un code C++ serait deux fois plus grand que son équivalent en C me semble tout à fait erronée. Le C++ offre des abstractions telles que les classes et les templates qui peuvent aider réduire la redondance et améliorer la modularité du code pouvant conduire à un code plus compact et plus facile à maintenir. Fonctions template et inline en C++ : Les templates en C++ offrent une puissance et une flexibilité bien supérieures aux fonctions inline en C, chaque fonction pouvant être spécialisée de façon automatique ou non en fonction du type visé. Utilisation de l'assembleur inline : le C++ permet toujours l'utilisation d'assembleur inline, de ce côté là, rien ne change. Et tu peux très bien utiliser le C++ de façon procédurale, c'est multi-paradigme. Mais ces usages restent anecdotiques, car même dans le noyau Linux, très peu d'assembleur inline est utilisé pour des raisons évidentes de maintenabilité et ce code est écrit par des experts du domaine. Classes vs structures : Une classe en C++ peut être vue comme une structure en C avec des fonctions, et en vérité c'est le cas. Le langage apporte juste du sucre syntaxique pour en faciliter l'usage et réduire les bugs potentiels. Héritage : L'héritage en C++ est un puissant outil de conception qui va au-delà de la simple inclusion d'une structure dans une autre en C. Il permet la création de hiérarchies d'objets avec des comportements partagés, facilitant la réutilisation et l'extension du code. Fonctionnalités avancées du C++ : Les fonctionnalités avancées du C++, telles que les exceptions, les templates, le polymorphisme, ..., ont leurs propres avantages et inconvénients. Leur utilisation dépend du contexte spécifique et des exigences du projet. Dire qu'elles ont un désavantage dans 90% des cas est une sur-généralisation non étayée. Dans la vidéo, il n'est pas question d'utiliser toutes les fonctionnalités du langage, mais un sous-ensemble distinct adapté à l'écriture d'un noyau. Linux c'est un Kernel, pas un JV : Absolument ! Comme dit plus haut, j'enseigne en école d'ingénieur son architecture et comment écrire des appels systèmes, des modules, etc. et c'est aussi une activité pour laquelle j'ai pratiqué professionnellement pour produire du code noyau spécifique à du matériel en systèmes embarqués critiques en écrivant des pilotes et appels systèmes et autres.

C'est un Turtle Beach Bumblebee II