C++ vs C

Citation:

---

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.

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...

Citation:

---

Envoy� par Jean-Marc.Bourguet

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

Citation:

---

Envoy� par Jean-Marc.Bourguet

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.

Citation:

---

Envoy� par Jean-Marc.Bourguet

� 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.

Citation:

---

Envoy� par Jean-Marc.Bourguet

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.

Citation:

---

Envoy� par Jean-Marc.Bourguet

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

---

Tout � fait :roll:



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

Citation:

---

Envoy� par Jean-Marc.Bourguet

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).

Citation:

---

Envoy� par Jean-Marc.Bourguet

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�...

Citation:

---

Envoy� par koala01

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...

Citation:

---

Envoy� par koala01

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).

Citation:

---

Envoy� par soleuh

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.

Citation:

---

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.

Citation:

---

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.

Citation:

---

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.

Citation:

---

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.

Citation:

---

Envoy� par koala01

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...

Citation:

---

Envoy� par loufoque

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.

Citation:

---

Envoy� par Jean-Marc.Bourguet

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!!!

Citation:

---

Envoy� par Jean-Marc.Bourguet

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)

Citation:

---

Envoy� par Jean-Marc.Bourguet

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 ?

Citation:

---

Envoy� par Jean-Marc.Bourguet

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

---

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

Citation:

---

Envoy� par Jean-Marc.Bourguet

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

---

Toutes mes excuses.

Citation:

---

Envoy� par Jean-Marc.Bourguet

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... :roll:

Citation:

---

Envoy� par Miles

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

---

Aucune id�e, std::exception ?

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, ...

(*)

Citation:

---

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 ...

Citation:

---

Envoy� par Luc Hermitte

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 :)

Citation:

---

Envoy� par Luc Hermitte

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..

Citation:

---

Envoy� par Luc Hermitte

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� 8O


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.

Citation:

---

Envoy� par Luc Hermitte

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:

Citation:

---

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.

Citation:

---

Envoy� par soleuh

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.

Citation:

---

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.

Citation:

---

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

---

Pourquoi?

Citation:

---

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.

Citation:

---

Envoy� par Miles

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.

Citation:

---

Envoy� par Gnux

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.

Citation:

---

Envoy� par soleuh

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� 8O

---

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�...

Citation:

---

Envoy� par Jean-Marc.Bourguet

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.

Citation:

---

Envoy� par Miles

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.

Citation:

---

Envoy� par Jean-Marc.Bourguet

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++ ...

Citation:

---

Envoy� par Jean-Marc.Bourguet

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.

Citation:

---

Envoy� par Miles

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...

Citation:

---

Envoy� par Jean-Marc.Bourguet

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?

Citation:

---

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.

Citation:

---

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.

Citation:

---

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...

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