Discussion :

[loufoque]

Tout ce qu'il dit, non. Mais en l'occurence, il parle de développement de kernel là.

Déjà, il y a beaucoup d'éléments critiqués dans la manière dont est organisé le code de linux. Ce n'est pas le noyau ultime et parfait que certains prétendent, c'est pour ça qu'il y a d'autres projets en parallèle.
Ensuite, il n'est a priori pas un expert du C++ (il dit d'ailleurs que C++ c'est de la merde). Il est habitué au bidouillage en C (ce qui laisse ses marques - combien de progammeurs C ne se rendent toujours pas compte de ce qu'est C++ ?) et il a sûrement du suivre un peu l'époque de l'emergence de la programmation objet. Rien que ne lui permette de pouvoir bien juger C++, qui n'a rien à voir avec tout cela.
La programmation objet avec polymorphisme dynamique n'est qu'une des fonctionnalités de C++, et pas celle où il excelle le plus d'ailleurs.

[koala01]

soleuh=> Pourrais tu dater les propos de linus?

J'ai tendance à me méfier des sitations quand je ne sais pas de quand elle date.

En effet, on lit "en 1992" et juste apres, "certains faits fondamentaux n'ont pas changé".

Soit...

Mais, si linus a écrit ces propos en 1993, on peut décemment se poser la question de leur niveau d'actualité, car l'évolution des compilateurs et du langage fait sans doute qu'il serait temps de réévaluer cette affirmation.

Si bien sur, ce propos date d'il y a quelques mois, on est en droit de leur accorder beaucoup plus de crédit.

On devrait cependant demander de quand date sa dernière évalutation objective de la situation (peut etre le répete-t-il depuis treize ans, et cela dénoterait alors un conservatisme de mauvais aloi).

Je rejoins en outre pleinement Jean-Marc.Bourguet sur le fait qu'un développement de ses affirmations aurait été bénéfique (pourquoi pas, en apportant un point de vue pour une évolution future ?)

loufoque=> A tord ou à raison, on peut estimer que le développeur d'un noyau, qui participe d'ailleurs toujours au développement, est quand meme l'une des personnes les mieux qualifiées pour savoir ce qui est bon ou non pour le noyau...

Visiblement... mais je ne vois pas trop l'intérêt du C++ pour un module dans un noyeau écrit pour le reste en C; l'échelle est trop petite pour que les intérêts majeurs du C++ se manifestent, et les inconvénients d'avoir une partie écrite dans un langage non maîtrisé par le reste des mainteneurs sont certains.

J'irais meme plus loin en parlant de "mainteneurs éduqués dans une forte mesure par le projet qu'ils maintiennent"

Qu'il s'agisse de conventions de nomages, de conventions purement typographiques ou d'habitudes de programmation, je suis persuadé qu'un projet aussi dense que le noyau, impliquant autant de personne, occasionne forcément un certain nivellement dans la manière d'implémenter les choses...

Je me souviens d'avoir lu un message de linus défendant l'utilisation de goto et d'étiquettes dans une situation données (les sorties sur erreur, si mes souvenirs sont bons)

Sans juger de la pertinance de ses propos, on peut estimer (car je n'ai jamais pris la peine de relire tout le code du noyau et de ses modules) que c'est devenu une habitude générale au sein de l'équipe de maintenance

[soleuh]

Et? Si on est dans le kernel, qu'est-ce qui gène?

...
Bon ! Quand une exception(C++) se produit, il se passe quoi à ton avis ? Un division par zéro par exemple, l'exception(Système) est lancée, ratrappée par le kernel. Puis il traite l'exception(Système) : envoie d'un message au processus correspondant. Celui ci va chercher la liste des catch correspondant jusqu'à le trouver.
Et on fait quoi si c'est nous même ?
Bon biensur je parle de linux, je ne fais pas de ce kernel une généralité, mais au moins c'est un exemple concret.

À quoi sert la syntaxe de placement new et la possibilité de définir des
opérateurs new par classe si ce n'est à offrir des variantes?

Syntaxe de placement : en détournant un peu, on doit pouvoir effectivement en faire quelque chose, et encore.
Un new par classe : C'est bien et si on a plusieurs façon d'allouer chaque classe ? Enfin j'dis ça dans le vide, peut être qu'on a pas besoin.

Même si on n'utilise que les virtuelles (c'est utiles dans le noyeau, tous les réinvente), les templates et le fait qu'en général on a une meilleure encapsulation qu'on n'est pas obligé de sacrifier à l'autel des performances... on a gagné quelque chose par rapport au C. Il ne faut pas oublier que le C++ s'est d'abord répandu en tant que "better C" et ensuite on a commencé à se servir des possibilités supplémentaires.

Le problème avec les virtuelles ? Rien rien... juste la vtable. Biensur qu'il en faut. Juste qu'il faut vraiment y faire attention c'est tout...
Oki pour l'encapsulation, je suis tout à fait d'accord.

En 1992, je n'aurais pas peut-être pas plus utilisé du C++, le langage
étant alors trop en évolution.

Tout à fait



Là il faudrait argumenter un peu plus. J'aimerais bien savoir ce qui est
cassé.

Quelle construction du C++ fait des allocations mémoires toute seule?

Aucune à mon avis. Je pense qu'il s'agit plus d'une méconnaissance du C++ ... il manque une explication avec ma citation, j'en suis désolé. Je ne suis pas certain que Linus soit parfaitement au point en C++ (pas celui de 92, celui d'aujourd'hui).

Visiblement... mais je ne vois pas trop l'intérêt du C++ pour un module dans un noyeau écrit pour le reste en C; l'échelle est trop petite pour que les intérêts majeurs du C++ se manifestent, et les inconvénients d'avoir une partie écrite dans un langage non maîtrisé par le reste des mainteneurs sont certains.

Bon là dessus tout le monde est d'accord, mais le thread a très vite dérivé...

soleuh=> Pourrais tu dater les propos de linus?

Date: Mon, 19 Jan 2004 22:46:23 -0800 (PST)

Est ce que le C++ a vraiment fait un bon depuis début 2004 ? Je crois pas non...

Je me souviens d'avoir lu un message de linus défendant l'utilisation de goto et d'étiquettes dans une situation données (les sorties sur erreur, si mes souvenirs sont bons)

Tant que c'est pas des goto pour le plaisir d'écrire goto dans le code, ça ne me choque pas. On parle de programation noyau... pas d'une appli de gestion commerciale.


Et mon avis est que le C++ n'est pas forcément le langage le plus adapté pour écrire un kernel. Je ne dénigre pas le C++ en disant ça, il reste de loin mon langage de prédilection. Et comme je l'ai déjà dit, ça ne veut pas dire que ce soit impossible, et j'aimerai beacoup me lancer dans ce genre de projet si j'en avais le temps (et accessoirement les compétences).

[Jean-Marc.Bourguet]

Bon ! Quand une exception(C++) se produit, il se passe quoi à ton avis ? Un division par zéro par exemple,

Mauvais exemple, ce n'est pas une exception, c'est une interruption. Mais ça ne change pas grand chose, la seule différence avec une exception c'est qu'on peut avoir changé de pile.

l'exception(Système) est lancée, ratrappée par le kernel. Puis il traite l'exception(Système) : envoie d'un message au processus correspondant. Celui ci va chercher la liste des catch correspondant jusqu'à le trouver.
Et on fait quoi si c'est nous même ?
Bon biensur je parle de linux, je ne fais pas de ce kernel une généralité, mais au moins c'est un exemple concret.

Bon que ce passe-t'il quand on lance une exception? Le compilateur génère un appel à une fonction du runtime en lui passant la valeur lancée et une indication de son type (cela peut se faire en plusieur appel comme dans le cas de l'ABI développée pour l'IA64 et utilisée par gcc pour les autres architectures, mais c'est du détail). Rien de ce que doit faire cette fonction ne pose un problème à faire dans le cadre du noyau (en gros: première itération sur la pile pour savoir si l'exception est bien récupérée quelque part dans la pile et avant d'arriver à un niveau où on est déjà en train de faire du cleanup, ensuite deuxième itération pour appeler les destructeurs qu'il faut. Cela peut se faire d'au moins trois façons: avec des tables décrivant les frames, en mettant de l'info dans les frames elles mêmes, en utilisant setjmp/longjmp). En fait, je crois bien que dans la plupart des implémentations de C++, le traitement ne fait pas appel au noyau -- sous Linux par exemple j'en suis certain --, celle de MS fait appel au noyau parce qu'ils ont voulu fusionner la notion C++ d'exception avec la notion de l'OS d'exception, mais ce n'est en rien nécessaire, même avec leurs structures de données.

Syntaxe de placement : en détournant un peu, on doit pouvoir effectivement en faire quelque chose, et encore.

On en fait quelque chose. La seule complication, c'est à la libération où il faut soit être capable de retrouver l'origine du pointeur avec sa valeur, soit prévoir un delete_from_pool à utiliser plutôt que l'opérateur delete.

Le problème avec les virtuelles ? Rien rien... juste la vtable

Ce n'est jamais qu'une table de pointeurs...

Tu peux corriger les deux dernières citations? Elles ne sont pas de moi.
Merci.

Et mon avis est que le C++ n'est pas forcément le langage le
plus adapté pour écrire un kernel.

Tu as commencé par écrire qu'il fallait se restreindre à un sous-ensemble, j'ai cherché simplement à délimiter le sous-ensemble. Il me semble comprendre la plus grosse partie du C++.

Mon avis est que le C++ n'est pas techniquement le langage le plus adapté à quoi que ce soit. Mais il reste suffisemment bon pour être envisagé et des considérations non techniques ou semi-techniques le font souvent passer en tête.

[Matthieu Brucher]

Par contre, je peux concevoir que l'utilisation des exceptions STL puisse présenter quelques problemes...

Faudra m'expliquer d'où ces exceptions de la STL sortent...

C'est pas parce qu'il a écrit un noyau à la mode que tout ce qu'il dit c'est forcément bien.

Clair, Tannenbaum, son prof, s'est bien planté alors que c'est une référence, et donc une connerie de sa part ne serait pas étonnante outre mesure.

[Gnux]

Mon avis est que le C++ n'est pas techniquement le langage le plus adapté à quoi que ce soit. Mais il reste suffisemment bon pour être envisagé et des considérations non techniques ou semi-techniques le font souvent passer en tête.

Donc concrètement tu écrirais un kernel en C++ tout en concevant une API correct (pas slt une prog en asm...) ?
J'en avais vu un passé sur comp.os.minix il n'y a pas longtps. Et c'est marrant justement, il l'avait utilisé pour la gestion de la mémoire en particulier. J'arrive pas à retrouver le thread...mais ça avait flamé car le noyau susdit était...monolithique!!!

[soleuh]

Mauvais exemple, ce n'est pas une exception, c'est une interruption. Mais ça ne change pas grand chose, la seule différence avec une exception c'est qu'on peut avoir changé de pile.

Effectivement... et zut, j'suis désolé
Tu parle de lancer toi même une exception, c'est tout à fait différent de ce à quoi je pensais... et tu n'as pas forcément tords... bon j'irai même jusqu'à dire que tu me semble avoir raison !
Bref, n'empêche que je ne les utiliserai toujours pas si je devais écrire un kernel. Je ne crois pas que tu ai un main dans un kernel (dans le sens d'un programme utilisateur)

On en fait quelque chose. La seule complication, c'est à la libération où il faut soit être capable de retrouver l'origine du pointeur avec sa valeur, soit prévoir un delete_from_pool à utiliser plutôt que l'opérateur delete.

On est bien d'accord c'est faisable... mais à quel prix ?

Ce n'est jamais qu'une table de pointeurs...

Oui oui, je disais juste de s'en méfier.

Tu peux corriger les deux dernières citations? Elles ne sont pas de moi.
Merci.

Toutes mes excuses.

Tu as commencé par écrire qu'il fallait se restreindre à un sous-ensemble, j'ai cherché simplement à délimiter le sous-ensemble. Il me semble comprendre la plus grosse partie du C++.

Mon avis est que le C++ n'est pas techniquement le langage le plus adapté à quoi que ce soit. Mais il reste suffisemment bon pour être envisagé et des considérations non techniques ou semi-techniques le font souvent passer en tête.

Je ne pourrais pas donner d'argument très précis sans avoir essayé moi même. Mais je ne crois pas qu'un kernel se code comme un programme en mémoire utilisateur...

Faudra m'expliquer d'où ces exceptions de la STL sortent...

Aucune idée, std::exception ?

[Luc Hermitte]

std::exception n'a jamais fait parti de la STL. (!= SL ; la STL est une appelation historique concernant un sous-ensemble de la SL du C++). Je pense que Miles pinaillait là dessus.

Et combien même il est toujours possible de ne pas payer les exceptions. A ce sujet, je suis tombé là dessus il n'y a pas longtemps.

Perso, je ne vois pas pourquoi le C++ ne pourrait pas être utilisé. Il peut justement être utilisé comme un better C, et libre à nous de ne pas utiliser des fonctionnalités couteuses (exceptions), des fonctionnalités qui n'apportent parfois rien (OO là où cela ne sert pas), des fonctionnalités dont on ne sait pas comment elles seront mises en oeuvre par les compilos (vtable (*), inlining, ...). Il continu à apporter des choses appréciables sans surcoût et surtout sans cabrioles : abstraction/encapsulation, références, algorithmes, ...

(*)

Le problème avec les virtuelles ? Rien rien... juste la vtable

Quand on a besoin de mettre en oeuvre un aiguillage en fonction d'un état, les vtables ne sont pas plus indaptées qu'une série de ifs ...

[soleuh]

Et combien même il est toujours possible de ne pas payer les exceptions. A ce sujet, je suis tombé là dessus il n'y a pas longtemps.

Interressant, merci

Perso, je ne vois pas pourquoi le C++ ne pourrait pas être utilisé. Il peut justement être utilisé comme un better C, et libre à nous de ne pas utiliser des fonctionnalités couteuses (exceptions), des fonctionnalités qui n'apportent parfois rien (OO là où cela ne sert pas), des fonctionnalités dont on ne sait pas comment elles seront mises en oeuvre par les compilos (vtable (*), inlining, ...). Il continu à apporter des choses appréciables sans surcoût et surtout sans cabrioles : abstraction/encapsulation, références, algorithmes, ...

Il peut, et l'est dans certains kernels ! Maintenant, pour ce qui est de l'abstraction qu'il offre, je ne suis pas certain que ce soit un argument pour un kernel, où on travaille au niveau du processeur..

Quand on a besoin de mettre en oeuvre un aiguillage en fonction d'un état, les vtables ne sont pas plus indaptées qu'une série de ifs ...

J'ai plus souvent entendu parlé de l'opposition de la vtable avec les switch/case qu'avec les ifs... Tu y vas un peu fort là


Bref, je pense avoir dit tout ce que je pensais, savais et ne savais pas sur ce sujet en ce qui me concerne. Je pense le C plus adapté à ce type d'usage.

[Jean-Marc.Bourguet]

Et combien même il est toujours possible de ne pas payer les exceptions. A ce sujet, je suis tombé là dessus il n'y a pas longtemps.

On y lit:

Neither Microsoft C++ nor GCC implement zero-overhead exception handling.

qui nécessite d'être qualifié par "sous Windows". À ma connaissance, gcc utilise la méthode des tables sur les autres plateformes. Je ne suis pas très au courant de la manière dont les "structured exceptions" de Windows sont implémentées, mais si elles nécessitent des passages en mode kernel pour fonctionner -- soit à l'établissement des frames, soit quand une exception est jetée -- ça ne m'étonne pas qu'elles soient fortement coûteuses.

[Jean-Marc.Bourguet]

Bref, n'empêche que je ne les utiliserai toujours pas si je devais écrire un kernel. Je ne crois pas que tu ai un main dans un kernel (dans le sens d'un programme utilisateur)

Je ne suis pas sûr non plus que je les utiliserais. Mais pas parce qu'elles posent un problème, parce que je ne vois pas a priori de cas où elles sont utiles dans ce cadre (notre moniteur avait des exceptions mais elles servaient dans des parties applicatives et pas dans ce qui aurait été le noyau si la découpe avait été faite ainsi). Comme dans un programme utilisateur, il faut utiliser l'outil adéquat.

On est bien d'accord c'est faisable... mais à quel prix ?

Détaille moi ce prix et le prix des alternatives. Implémenter un opérateur new ou une fonction kmalloc, je ne vois pas de différence. Et on est sûr que les objets alloués sont initialisés.

Oui oui, je disais juste de s'en méfier.

Pourquoi?

Je ne pourrais pas donner d'argument très précis sans avoir essayé moi même.

Je crois connaître assez bien les techniques d'implémentation du C++, j'ai déjà participé à l'écriture d'un petit moniteur temps réel, je ne vois pas de problèmes fondamentals à utiliser n'importe quelle partie du C++ dans un noyau (ce qui ne veut pas dire que je les trouve toutes utiles dans ce contexte, simplement que si on en a l'utilité la méthode C++ ne me semble pas coûter horriblement plus que les alternatives). Mais je n'ai pas essayé de programmer un noyau en C++; comme toujours les détails comptent et il y a des problèmes dont il est difficile de savoir qu'ils existent avant de les avoir rencontrés. Avec tes positions, j'espérais que tu puisses m'éclairer sur mes manques.

[Jean-Marc.Bourguet]

Clair, Tannenbaum, son prof, s'est bien planté alors que c'est une référence, et donc une connerie de sa part ne serait pas étonnante outre mesure.

Tannenbaum n'a pas enseigné à Linus Torvald à ma connaissance.

En quoi s'est il trompé? À ma connaissance ils ont eu une contreverse sur l'intérêt de deux compromis différents... résultant d'objectifs différents (Tannenbaum étant intéressé par l'enseignement et la recherche à long terme sur les OS). Et l'évolution de Linux vers la possibilité de mettre de plus en plus en user mode me semble plutôt donner des points à postériori à Tannenbaum.

[Jean-Marc.Bourguet]

Donc concrètement tu écrirais un kernel en C++ tout en concevant une API correct (pas slt une prog en asm...) ?

De quelle API parles-tu? Je vois au moins trois niveaux: à l'intérieur du noyau, entre le noyau et la partie de l'OS tournant sans droits particuliers et entre les applications et l'OS.

Pour autant que le choix soit d'utiliser le C++, la première ce serait une interface définie en terme de C++, les deux autres définies de manière indépendante du langage mais facilement interprétable dans les langages que je connais.

[Matthieu Brucher]

J'ai plus souvent entendu parlé de l'opposition de la vtable avec les switch/case qu'avec les ifs... Tu y vas un peu fort là

Ca revient à la fin au même, un tableau de pointeur, autant garder l'abstraction, non ?

Effectivement, pour la STL, je pinaille, mais comme on voit trop souvent cet acronyme mal utilisé...

[Matthieu Brucher]

Tannenbaum n'a pas enseigné à Linus Torvald à ma connaissance.

En quoi s'est il trompé? À ma connaissance ils ont eu une contreverse sur l'intérêt de deux compromis différents... résultant d'objectifs différents (Tannenbaum étant intéressé par l'enseignement et la recherche à long terme sur les OS). Et l'évolution de Linux vers la possibilité de mettre de plus en plus en user mode me semble plutôt donner des points à postériori à Tannenbaum.

La conception du noyau avait déclenché entre les 2 une discution kernel monolithique ou pas. Torvalds lui a montré avec Linux qu'il sétait planté. Maintenant, c'est bien s'ils arrivent à converger dans leurs idées.

[Jean-Marc.Bourguet]

La conception du noyau avait déclenché entre les 2 une discution kernel monolithique ou pas. Torvalds lui a montré avec Linux qu'il sétait planté. Maintenant, c'est bien s'ils arrivent à converger dans leurs idées.

C'est bien ce à quoi je faisais allusion. Je ne vois pas en quoi Linux montre que Tanenbaum s'était trompé; mais bon ce n'est pas le bon forum pour ce débat.

[soleuh]

Détaille moi ce prix et le prix des alternatives. Implémenter un opérateur new ou une fonction kmalloc, je ne vois pas de différence. Et on est sûr que les objets alloués sont initialisés.

Oui mais un même objet peut être alloué de différentes façons, apparement, selon le contexte. Au final, on réfléchit en C (voir en asm) avec du C++ ...

Avec tes positions, j'espérais que tu puisses m'éclairer sur mes manques.

Il faut croire que non. C'est avant tout un problème d'abstraction, je suis pas certain qu'un kernel soit le bon endroit pour s'abstraire de la machine. Et faire du C en C++ ... autant faire du C, c'est pas les mot clefs class, public et private qui y changent grand chose.

Ca revient à la fin au même, un tableau de pointeur, autant garder l'abstraction, non ?

C'est pas plus embêtant ! Juste que le petit mot clef virtual va faire un tas de petites choses, que tu aurais fait explicitement. C'est génial d'habitude, mais j'ai un doute dans un kernel...

[Gnux]

C'est bien ce à quoi je faisais allusion. Je ne vois pas en quoi Linux montre que Tanenbaum s'était trompé; mais bon ce n'est pas le bon forum pour ce débat.

<HS>+1</>
Ou pourrait on débattre de ça?

[loufoque]

Oui mais un même objet peut être alloué de différentes façons, apparement, selon le contexte. Au final, on réfléchit en C (voir en asm) avec du C++ ...

En C++, on permet d'utiliser des allocateurs différents pour gérer la mémoire, celle des types de données standard par exemple. Ce qui est bien plus puissant et flexible que les alternatives en C.
new n'est qu'un outil simplifié, sans grand intérêt pour faire des allocations mémoires avancées. Il est même sans grand intérêt de manière générale, ils devraient remplacer ça par un ramasse-miettes.

Il faut croire que non. C'est avant tout un problème d'abstraction, je suis pas certain qu'un kernel soit le bon endroit pour s'abstraire de la machine. Et faire du C en C++ ... autant faire du C, c'est pas les mot clefs class, public et private qui y changent grand chose.

Peut-être devrais-tu apprendre ce qu'est le C++.
Ses avantages sont son système typé, sa généricité, et sa manière de gérer les ressources.
Je sais pas pourquoi depuis le début tu nous parles de "class" aucunement représentatif des apports de ce langage.

C'est pas plus embêtant ! Juste que le petit mot clef virtual va faire un tas de petites choses, que tu aurais fait explicitement. C'est génial d'habitude, mais j'ai un doute dans un kernel...

Le tas de petites choses est clairement défini et est potentiellement bien plus optimisé qu'une solution manuelle...

[Aurelien.Regat-Barrel]

Je passe vite fait pour donner un lien sur le C++ dans les drivers sous Windows:
http://www.microsoft.com/whdc/driver/kernel/KMcode.mspx