Salut , hyper intéressant !! Etant entrain de me former au c++ actuellement, je confirme que la cap a franchir entre le C et le C++ pour apprendre et assimiler le langage est vrmt minime , apres avoir beaucoup codé en C j’ai juste l’impression d’apprendre de nouvelles fonctionnalités du c
Merci pour votre Travail. Je découvre votre chaîne avec plaisir. Étant un utilisateur relativement récent, votre chaîne est excellente. Je m'abonne direct. 🐧🦎🐧
Bonjour, votre vidéo est très intéressante. Je suis même d'accord avec les arguments que vous donnez dans la partie "Du C++ dans le noyau Linux", alors que je ne suis vraiment pas adepte du C++ 🙂
Depuis longtemps j'ai utilisé du c++ en embedded, je l'ai même fait en bare metal. Je ne comprends pas pourquoi ça a été rejeté dans le noyau. C'est clair qu'il faut pas tout prendre du c++, mais rien que les templates, c'est très utile. Par contre un gros défaut est le temps de compilation qui peut vite grimper.
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
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 😅
je viens de découvrir la chaîne ( par cette vidéo ) j'aime les points de vues apportés, l'ambiance est sympa aussi - petite remarque concernant la chaîne - je trouve en navigant la chaîne que les apéros tech pourraient être plus attractifs si il y avait - un titre compact des sujets abordés - exemple: AT#10 : C++, Linux, Pingouin - une miniature qui indique juste les sujets majeurs abordés dans la vidéo, que ce soit avec une image ou un texte ( pas besoin de dépenser 2H dessus, 3 min devraient suffit avec photoshop ou même gimp ) juste la date ne donne pas spécialement envie de regarder, on aimerait regarder celles avec des sujets qui nous intéressent
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
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.
Intéressant - mais partagé entre les deux avis. D'un côté le C++ a effectivement ses avantages, notamment la surcharge ou l'héritage. D'un autre côté, le C force à ne pas utiliser de "raccourcis", ce qui est peut-être plus long, mais plus sécurisé... Quant au Rust, j'ai pas encore eu de projets dessus, donc je ne me prononcerai pas. Quoi qu'il en soit, je viens encore de voir que la webcam d'un acer A317 moderne est reconnue au niveau USB mais pas prise en charge sur un noyau 6+. Et toujours les mêmes problèmes de devoir chercher les logiciels chez epson quand on veut intégrer une XP-2105. Quand epson va t'elle enfin arrêter d'emmerder le monde, et fournir des deb prêts à l'emploi directement sur les serveurs officiels de Debian ? Bref, loin de nos querelles d'experts, les usagers attendent du out of the box, et même si la situation s'est améliorée à 99%, il reste toujours ce putain de 1% qui casse les pieds. Un peu dommage que les fabricants n'aient toujours pas compris l'impérieuse nécessité de fournir TOUS les pilotes de leurs matériels sous OS libre. Mais moyennant quelques compromis, force est de constater que même des utilisateurs basique de chez basiques parviennent enfin à utiliser GNU/Linux, et ça, on ne peut que remercier tous les devs sur 20 ans qui ont rendu ce miracle possible !
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
Pour moi je vois très peu d'avantage à intégré c++ dans le noyau Linux car - le code c++ récent ne sera pas compris par tous les contributeur car il y a certains syntaxe exotique. - beaucoup des avantages de c++ sont aussi dans rust. - Connecter de c et rust est plus simple que connecter c++ et rust. - Je pense que Linus Torvalds veux pas beaucoup de language dans sa codebase et qu'il a accepte le rust pour réduire les bugs du à la gestion de mémoire et donc avoir des modules plus sécurisée
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
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.
Finalement il serait plus correct de dire que le code du noyau va rester en C mais en se permettant 2/3 features (notamment de metaprogrammation) pertinentes du C++
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
C > C++, le C rien qu'au code on peut savoir l'assembleur generé derrière, C++ c'est beaucoup plus compliquer. Le C++ ne va pas durer dans le temps car ecrire un compilateur C et C++ ce n'est pas la même chose, pour des architechture tres peu connu avec uniquement un compilateur C dispo on ne pourra plus mettre linux. Un code C est plus facilement tenable dans le temps, les 20 millions de ligne de linux serait un calvaire en C++ et en serait probablement le double d'ailleurs, il aurait fallu une norme très très solide. Je n'ai pas saisie l'idée des fonction template inline, les fonction inline existent aussi en C, je n'ai pas assez de connaissance en C++ pour cela, cependant ça m'etonnerai qu'il y ait un tant gros avantage que ça à l'utiliser. Le C marche très bien avec de l'inline assembly ce qui peut être très largement requis dans un kernel, le C++ n'étant pas procédural j'y verrai mal de l'inline assembly. Une class en C++ et une structure en C c'est la meme chose, je met 2-3 pointeurs sur fonction dans ma structure C ça revient à une class C++. Pour l'heritage, je vois pas en quoi mettre une structure dans une structure en C serait different. Toutes les autre fonctionnalités ont un desavantage à être utilisé, c'est à dire 90% du langague, donc quel interet ? Linux c'est un kernel pas un jeu video, on est plus bas niveau, à celui du C sans libc.
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 facile de critiqué une technologie quand on en a pas inventé. Les gens comprenne pas que on et aller sur la lune avec moins de puissance que la puce d’un joycoin de la switch.
Salut , hyper intéressant !! Etant entrain de me former au c++ actuellement, je confirme que la cap a franchir entre le C et le C++ pour apprendre et assimiler le langage est vrmt minime , apres avoir beaucoup codé en C j’ai juste l’impression d’apprendre de nouvelles fonctionnalités du c
Merci pour le feedback 👌🙏
Effectivement la Critique est aisée, mais l’art est difficile Merci à David Mills, et paix à son Ame.
Haiku OS est écrit entièrement en C++; Tout l'API Graphique est en C++ ;) Et le WM ( hérité de BeOS) est tellement intelligent!
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
03:47 - début de la vidéo
Merci pour votre Travail.
Je découvre votre chaîne avec plaisir.
Étant un utilisateur relativement récent, votre chaîne est excellente. Je m'abonne direct. 🐧🦎🐧
Merci beaucoup ! Heureux que mes lives plaisent ❤️
Merci, je viens enfin de comprendre pourquoi on lançait certains jeux avec |cpm sur les amstrad cpc au lieu de run à l’époque
Le CP/M était un système plutôt bien conçu et surtout portable 👌
Bonjour,
votre vidéo est très intéressante. Je suis même d'accord avec les arguments que vous donnez dans la partie "Du C++ dans le noyau Linux", alors que je ne suis vraiment pas adepte du C++ 🙂
Merci 🙏
Respect a Mills pour son travail,
Et merci a tout ceux qui ont permis a l'informatique d’être ce qu'elle est aujourd'hui, une science a part entière.
Oui ! Des personnages importants et brillants 👌
Depuis longtemps j'ai utilisé du c++ en embedded, je l'ai même fait en bare metal. Je ne comprends pas pourquoi ça a été rejeté dans le noyau. C'est clair qu'il faut pas tout prendre du c++, mais rien que les templates, c'est très utile.
Par contre un gros défaut est le temps de compilation qui peut vite grimper.
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 😜
Bonjour je viens de découvrir votre chaine et j'aimerais savoir si c'est techniquement possible d'avoir du Java dans le noyau Linux?
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 😅
je viens de découvrir la chaîne ( par cette vidéo )
j'aime les points de vues apportés, l'ambiance est sympa aussi
- petite remarque concernant la chaîne -
je trouve en navigant la chaîne que les apéros tech pourraient être plus attractifs si il y avait
- un titre compact des sujets abordés
- exemple: AT#10 : C++, Linux, Pingouin
- une miniature qui indique juste les sujets majeurs abordés dans la vidéo, que ce soit avec une image ou un texte ( pas besoin de dépenser 2H dessus, 3 min devraient suffit avec photoshop ou même gimp )
juste la date ne donne pas spécialement envie de regarder, on aimerait regarder celles avec des sujets qui nous intéressent
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
Question, sous Linux Mint pour dev en Rust, vous conseillez quel IDE ?
Je vois qu'Eclipse le gère et étant en pleine découverte...
Thx
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
Dommage que la vidéo ne soit pas disponible en version française
Hein ?? Comment ça ? Quelle vidéo ?
@@ponceto91 Celle en franglais 👀
Du C++ dans le noyaux ??? Wow! Quelle belle nouvelle! \O/ !🤣😎
C'est l'Apocalypse pour Linus!! ha-ha-ha-ha!
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.
Intéressant - mais partagé entre les deux avis. D'un côté le C++ a effectivement ses avantages, notamment la surcharge ou l'héritage. D'un autre côté, le C force à ne pas utiliser de "raccourcis", ce qui est peut-être plus long, mais plus sécurisé... Quant au Rust, j'ai pas encore eu de projets dessus, donc je ne me prononcerai pas. Quoi qu'il en soit, je viens encore de voir que la webcam d'un acer A317 moderne est reconnue au niveau USB mais pas prise en charge sur un noyau 6+. Et toujours les mêmes problèmes de devoir chercher les logiciels chez epson quand on veut intégrer une XP-2105. Quand epson va t'elle enfin arrêter d'emmerder le monde, et fournir des deb prêts à l'emploi directement sur les serveurs officiels de Debian ? Bref, loin de nos querelles d'experts, les usagers attendent du out of the box, et même si la situation s'est améliorée à 99%, il reste toujours ce putain de 1% qui casse les pieds. Un peu dommage que les fabricants n'aient toujours pas compris l'impérieuse nécessité de fournir TOUS les pilotes de leurs matériels sous OS libre. Mais moyennant quelques compromis, force est de constater que même des utilisateurs basique de chez basiques parviennent enfin à utiliser GNU/Linux, et ça, on ne peut que remercier tous les devs sur 20 ans qui ont rendu ce miracle possible !
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
Pour moi je vois très peu d'avantage à intégré c++ dans le noyau Linux car
- le code c++ récent ne sera pas compris par tous les contributeur car il y a certains syntaxe exotique.
- beaucoup des avantages de c++ sont aussi dans rust.
- Connecter de c et rust est plus simple que connecter c++ et rust.
- Je pense que Linus Torvalds veux pas beaucoup de language dans sa codebase et qu'il a accepte le rust pour réduire les bugs du à la gestion de mémoire et donc avoir des modules plus sécurisée
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...
FTP, cela fait 20 ans que j'utilise, et encore aujourd'hui, lol...
RIP à ce monsieur.
👌
Finalement il serait plus correct de dire que le code du noyau va rester en C mais en se permettant 2/3 features (notamment de metaprogrammation) pertinentes du C++
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
C > C++, le C rien qu'au code on peut savoir l'assembleur generé derrière, C++ c'est beaucoup plus compliquer.
Le C++ ne va pas durer dans le temps car ecrire un compilateur C et C++ ce n'est pas la même chose, pour des architechture tres peu connu avec uniquement un compilateur C dispo on ne pourra plus mettre linux.
Un code C est plus facilement tenable dans le temps, les 20 millions de ligne de linux serait un calvaire en C++ et en serait probablement le double d'ailleurs, il aurait fallu une norme très très solide.
Je n'ai pas saisie l'idée des fonction template inline, les fonction inline existent aussi en C, je n'ai pas assez de connaissance en C++ pour cela, cependant ça m'etonnerai qu'il y ait un tant gros avantage que ça à l'utiliser.
Le C marche très bien avec de l'inline assembly ce qui peut être très largement requis dans un kernel, le C++ n'étant pas procédural j'y verrai mal de l'inline assembly.
Une class en C++ et une structure en C c'est la meme chose, je met 2-3 pointeurs sur fonction dans ma structure C ça revient à une class C++.
Pour l'heritage, je vois pas en quoi mettre une structure dans une structure en C serait different.
Toutes les autre fonctionnalités ont un desavantage à être utilisé, c'est à dire 90% du langague, donc quel interet ?
Linux c'est un kernel pas un jeu video, on est plus bas niveau, à celui du C sans libc.
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.
wow, vraiment une video passionante impossible d'arreter merci beaucoup
Merciiii 🙏
Quel est ton microphone :o ???
C'est un Turtle Beach Bumblebee II
Cpp un tres bon langage je la considère comme l évolution du c le j ai fais du C comme du cpp je trouve le cpp plus fun bon c'est juste mon avis 😂
C’est facile de critiqué une technologie quand on en a pas inventé. Les gens comprenne pas que on et aller sur la lune avec moins de puissance que la puce d’un joycoin de la switch.