[ C++ ] Et pourquoi pas de l'objet dans nos chers kernel Linux ?

Et pourquoi pas de l'objet dans nos chers kernel Linux ? [ C++ ] - Débats - Linux et OS Alternatifs

Marsh Posté le 30-01-2004 à 09:51:08    

oui, pourquoi pas ? :o
on utilise du C depuis des lustres, avec les pb que celà comporte (lenteur de programmation, difficile à maintenir, etc ...)
 
évidemment pour tout ce qui est bas niveau, l'assembleur et le C reste de rigueur.
mais pour tout ce qui est driver, implémentation de protocole réseau etc ... ça permettrait de faire un code bien plus propre, plus facile à maintenir, plus rigoureux (devra repecter les interfaces proposer)
un langage a besoin de temps pour murrir, mais maintenant, le C++ est un langage aboutit, avec norme ISO et tout ce qu'il faut, largement utilisé de par le monde
alors pourquoi pas ? de nombreux développeurs ont l'air de vouloir ça en tout cas, mais ça ne semble pas être au gout de la haute hiérarchie :/


---------------
Non au projet de loi DADVSI ! (droits d'auteurs)
Reply

Marsh Posté le 30-01-2004 à 09:51:08   

Reply

Marsh Posté le 30-01-2004 à 10:03:50    

Super connue, mais je peux pas m'en empêcher ...
 
Interview de Bjarne Stroustrup, créateur du langage C++ :
 

Citation :

Interviewer  : Cela fait quelques années maintenant que vous avez changé le monde de la conception logicielle, qu'est-ce cela vous fait en regardant en arrière ?
 
Stroustrup : En fait, je repensais à cette époque juste avant que vous n'arriviez. Vous vous souvenez ? Tout le monde écrivait en C et le problème était qu'ils était vachement bons. Les universités dispensaient également un bon enseignement du C. Elles produisaient des diplômés compétents - et j'insiste sur le mot compétent. Et c'est ce qui a posé problème.
 
Interviewer : Problème ?
 
Stroustrup : Oui, problème. Vous vous souvenez du temps où tout le monde écrivait en COBOL ?
 
Interviewer : Bien sûr, j'ai moi-même écrit en COBOL.
 
Stroustrup : Et bien au début ces gars étaient des demi-dieu. Leurs salaires étaient élevés et ils étaient traités comme des princes.
 
Interviewer : C'était l'bon temps, hein ?
 
Stroustrup : Hé oui. Et qu'est-ce qu'il s'est passé ? IBM en a eu marre, et a investi des millions dans la formation de programmeurs COBOL, jusqu'à ce qu'ils ne valent qu'une bouchée de pain pour une douzaine.
 
Interviewer : C'est là que j'ai quitté ce métier. Les salaires ont chuté en moins d'un an, au point que cela payait plus d'être journaliste.
 
Stroustrup : Exactement. Et la même chose est arrivé aux programmeurs en 'C'.
 
Interviewer : Je vois, mais où voulez-vous en venir ?
 
Stroustrup : Et bien, un jour j'étais à mon bureau et j'ai conçu un petit stratagème qui pourrait retourner un peu la situation. Je pensais : 'je me demande ce qu'il se passerait s'il existait un langage si compliqué, si difficile à apprendre que personne ne pourrait jamais inonder la marché de programmeurs ?'
En fait, une partie de ces idées viennent de X10, vous savez, XWindows. C'était un système graphique si compliqué que cela ne tournait que sur ces choses Sun3/60. Tous les ingrédients que je voulais étaient présents : une syntaxe ridiculement complexe, des fonctions obscures, et une structure pseudo orientée-objet. Même maintenant, personne n'écrit du code X-Windows. Motif est le seul moyen de coder sans perdre sa raison.
 
Interviewer : Vous n'êtes pas sérieux ?
 
Stroustrup : Bien au contraire. En fait, il y avait un autre problème. Unix était écrit en 'C', ce qui signifie que tout programmeur 'C' pouvait facilement devenir programmeur système. Vous vous souvenez de ce qu'un programmeur de mainframe avait pour habitude de gagner ?
 
Interviewer : Bien sûr, c'était aussi mon type de salaire.
 
Stroustrup : OK, donc ce nouveau langage devait se séparer d'Unix, en masquant tous les appels qui liaient les deux si élégamment. Cela permettrait aux gars qui ne connaissent que le DOS de gagner de nouveau correctement leur vie.
 
Interviewer : Je ne peux pas croire que vous ayez dit cela.
 
Stroustrup : Bah, cela fait longtemps maintenant, et je suppose que la plupart des gens se sont rendus compte par eux-même que le C++ est une perte de temps, mais je dois dire que cela a pris plus de temps que je ne l'aurais cru.
 
Interviewer : Alors, comment exactement vous vous y-êtes pris ?
 
Stroustrup : C'était supposé être une blague, jamais je n'aurais cru que les gens prendrait le bouquin au sérieux. N'importe qui avec 2 grammes de bon sens peut voir que la programmation orientée-objet est contre-intuitive, illogique et inefficace.
 
Interviewer : Quoi ?!
 
Stroustrup : Et concernant le 'code réutilisable'!... Vous avez déjà entendu d'une compagnie qui a jamais réutilisé du code ???
 
Interviewer : En fait,... jamais, mais...
 
Stroustrup : Hé ben voilà. Je ne dis pas que quelques uns n'aient pas essayé au début. Il y avait cette compagnie d'Oregon - je crois qu'elle s'appelait Mentor Graphics - qui s'est vraiment fait une belle frayeur en essayant de tout réécrire en C++ dans les années 1990 ou 1991. J'en suis désolé pour eux, vraiment, mais je pensais que les gens en auraient tiré des leçons.
 
Interviewer : Manifestement, ils ne l'ont pas fait ?
 
Stroustrup : Pas le moins du monde. Le problème, c'est que la plupart des compagnies ont du étouffer leurs échecs majeurs, et que expliquer des pertes de 30millions de $ à leurs actionnaires aurait été difficile. Cependant, rendons leur crédit, c'est eux qui ont permis que cela marche en fin de compte.  
 
Interviewer : Ha oui ? Et bien vous voyez, l'orienté-objet, cela marche !
 
Stroustrup : Moui presque. L'exécutable était si énorme qu'il mettait 5 minutes à se charger sur des HP avec 128Mo de RAM. Il tournait si lentement. En fait, je pensais que cela serait un obstacle rédhibitoire, et je me suis rendu compte en moins d'une semaine que tout le monde s'en foutait. SUN et HP n'étaient que trop content de vendre des ordinateurs d'une puissance énorme, dotées d'immense ressources juste pour faire tourner des programmes triviaux. Vous savez, lorsque l'on a eu notre premier compilateur C++ chez AT&T, j'ai compilé le programme 'Hello World', et je ne pouvais pas croire la taille de l'exécutable : 2.1 Mo.
 
Interviewer : Quoi ? Les compilateurs ont fait du chemin depuis.
 
Stroustrup : Vraiment ? Essayez donc avec la dernière version de g++. La différence n'excédera pas 0.5Mo. De plus, j'ai plusieurs exemples récents pour vous, et ce depuis tout pays. British Telecom s'est retrouvé avec un désastre entre les mains, mais par chance, ils ont pu tout effacer et repartir de zéro. Et ils ont eu plus de chance que Australian Telecom. aujourd'hui, j'apprends que Siemens construit une usine à gaz, et s'inquiète de la taille croissante du matériel afin de pouvoir y faire tourner les exécutables. Est-ce que l'héritage multiple n'est pas merveilleux ?
 
Interviewer : Oui, mais C++ est à la base un langage solide.
 
Stroustrup : Vous en êtes vraiment convaincu, n'est-ce pas ? Avez-vous déjà participé à un projet C++ ? Voilà ce qui se passe : d'abord, j'y ai introduit suffisamment de piège pour être sûr que seuls les projets les plus simples fonctionneront la première fois. Considérez la surcharge des opérateurs. A la fin du projet, tous les modules l'ont utilisé, surtout parce que les gars ont pensé qu'ils devaient le faire, comme pendant leur formation. Le même opérateur qui signifie complètement autre chose d'un module à l'autre. Essayez de rassembler tout cela lorsque vous avez une centaine de module environ. Quant à l'encapsulation de données, mon Dieu, parfois je ne peux m'empêcher de rigoler lorsque j'entends parler des problèmes qu'ont des compagnies pour faire communiquer leurs modules. Je pense que le mot 'synergie' a été inventé pour remuer le couteau dans la plaie des manager de projet.
 
Interviewer : Je dois avouez que tout cela commence à me troubler. Vous dites que vous avez fait tout cela juste pour augmenter le salaire des programmeurs ? C'est choquant !
 
Stroustrup : Pas vraiment. Tout le monde a le choix. Je ne m'attendais pas à ce que cela soit si incontrôlable. De toute façons, j'ai en gros réussi. C++ est en train de passer de mode, et les programmeurs ont toujours des salaires élevés, surtout ces pauvres diables qui doivent maintenir toute cette merde. Vous réalisez bien sûr qu'il est impossible de maintenir un gros programme C++ si  vous ne l'aviez pas vous-même écrit ?
 
Interviewer : Et pourquoi donc ?
 
Stroustrup : Vous êtes vraiment hors du coup, pas vrai ? Vous vous souvenez du typedef ?
 
Interviewer : Oui, bien sûr.
 
Stroustrup : Vous souvenez-vous du temps qu'il vous fallait pour explorer les fichiers de déclaration de fonction avant de vous rendre compte que 'RoofRaised' était un double ? Alors, imaginez le temps que cela prend pour traduire tous les typedef implicites de toutes les classes d'un projet important en C++ !
 
Interviewer : Alors, en quoi reconnaissez-vous avoir réussi ?
 
Stroustrup : Rappelez-vous de la durée moyenne d'un projet en 'C' : environs 6 mois. Pas assez longtemps pour gagner correctement sa vie pour un gars marié avec enfants. Prenez le même projet, concevez-le en C++ et qu'est-ce que vous obtenez ? Je vais vous le dire : un à deux ans. C'est pas super, ça ? Toute cette sécurité de l'emploi à cause d'une erreur de jugement. Et autre chose : les universités n'ont pas enseigné le 'C' depuis si longtemps qu'il y a maintenant pénurie de programmeurs valables en 'C'. Surtout concernant ceux qui y connaisse quelque chose sur la programmation système Unix. Combien de gars saurait quoi faire avec un 'malloc', alors qu'ils utilisent 'new' ces dernières années, et ce sans jamais vérifier le code de retour ? En réalité, la plupart des programmeurs C++ ignorent complètement leur code de retour. Qu'est-ce qui est arrivé au bon vieux '-1' ? Au moins, vous saviez que vous aviez une erreur, sans tout emberlificoter dans des 'throw' et 'try'.
 
Interviewer : Mais à l'évidence, l'héritage fait gagner du temps ?
 
Stroustrup : Vraiment ? Avez-vous remarqué la différence entre un planning de projet 'C' et 'C++' ? La phase de planning d'un projet C++ est trois fois plus longue. Et justement pour s'assurer que tout ce doit être dérivé l'est, et ce qui ne doit pas l'être ne l'est pas. Et en plus, ils se gourent. Qui a entendu parler de 'fuites mémoire' en 'C' ? Maintenant, on les trouve dans les plus grandes industries. La plupart des compagnies abandonnent et commercialisent leurs produits en sachant qu'ils fuient comme des passoires, simplement pour éviter le coût de débuguer toutes ces fuites.
 
Interviewer : Il y a des outils...
 
Stroustrup : La plupart d'entre eux ont été écrit en C++ !
 
Interviewer : Si on publie cela, vous serez probablement lynché, vous le savez, non ?
 
Stroustrup : Ca m'étonnerait. Comme je vous l'ai dit, C++ est maintenant sur son déclin, et aucune compagnie sensée ne commencerait un projet sans un prototype. Cela devrait suffire à les convaincre de la nature désastreuse de cette voie. Sinon, ils mériteront ce qu'il leur arrivera. Vous savez, j'ai essayé de convaincre Dennis Ritchie de réécrire Unix en C++.
 
Interviewer : Oh mon Dieu, et qu'est-ce qu'il a dit ?
 
Stroustrup : Ben heureusement, il a un bon sens de l'humour. Je pense que lui et Brian se sont aperçu très tôt de ce que je faisais, mais ne l'ont jamais fait savoir. Il m'a dit qu'il m'aiderait à écrire une version C++ de DOS, si j'étais intéressé.
 
Interviewer : Et vous l'étiez ?
 
Stroustrup : En fait, j'ai écrit DOS en C++. Je vous donnerai une démo après. Je le fais tourner sur un Sparc20 dans la salle des ordinateurs. Ca tourne comme une flèche sur 4 CPU, et cela ne prends que 70Mo sur le disque.
 
Interviewer : Et-ce que cela tourne comme sur un PC ?
 
Stroustrup : Là vous blaguez. Avez-vous déjà vu Windows95 ? Je le considère comme un de mes plus gros succès. Ca a même failli tout arrêter avant que je ne sois prêt.
 
Interviewer : Vous savez, cette idée de Unix++ m'avait vraiment fait réfléchir. Il y a des gars quelque part qui sont en train d'essayer de le faire. [en fait, le µ-kernel L4 en est un bon exemple...]
 
Stroustrup : Non, pas après cette interview !
 
Interviewer : Je suis désolé, mais je ne nous vois pas capable de publier quoique ce soit de cela.
 
Stroustrup : Mais c'est l'histoire du siècle ! Je veux juste être considéré par mes collègues programmeurs pour ce que je leur ai apporté. Savez-vous combien peut toucher un programmeur C++ ces jours-ci ?
 
Interviewer : D'après ce que j'ai entendu, un vrai pro peut valoir 70 à 80 $ de l'heure.
 
Stroustrup : Vous voyez ? Et je parie qu'il les mérite. Tenir compte de tous les pièges à con que j'ai introduit dans le C++ n'est pas un job facile. Et comme je vous l'ai dit, tous les programmeurs C++ sont comme lié par un serment mystique pour employer toutes les fonctionnalités du langage dans tous les projets. En fait, cela finit même par m'ennuyer parfois, même si cela sert mon but original. J'en finis presque par aimer ce langage.
 
Interviewer : Vous voulez dire que ne l'aimiez pas avant ?
 
Stroustrup : Je le détestais. Il n'est même pas élégant, vous ne trouvez pas ? Mais quand les royalties du bouquins ont commencé à arriver... vous voyez l'idée.
 
Interviewer : Attendez une minute... et les références ? Vous devez reconnaître que cela représente une amélioration sur le pointeurs 'C'.
 
Stroustrup : Hmmm, je me suis toujours posé des questions à ce sujet. Au début, je pensais que s'en était une. Et puis un jour, j'ai discuté avec un gars qui avait programmé depuis ses débuts en C++. Il me disait qu'il ne pouvait jamais se souvenir si ses variables étaient référencées ou déréférencées, alors il utilisait toujours les pointeurs. Il disait que le petit '*' astérix l'aidait à se souvenir.
 
Interviewer : Et bien, à ce stade je dis généralement 'Merci beaucoup', mais cela ne semble pas très approprié.
 
Stroustrup : Promettez-moi que vous allez publier cela. Ma conscience prend le dessus ces derniers temps.
 
Interviewer : Je vous le ferai savoir, mais je pense deviner ce que mes éditeurs vont dire.
 
Stroustrup : Qui le croirait de toutes façon ? Toutefois, pourriez-vous m'envoyer une copie de cette bande ?
 
Interviewer : Je peux faire ça.


 
NB: c'est une fausse interview ...


Message édité par [Albator] le 30-01-2004 à 10:04:18
Reply

Marsh Posté le 30-01-2004 à 10:07:17    

non, ce n'est pas ridicule :o
on en parle ici :
http://lkml.org/lkml/2003/10/11/3


---------------
Non au projet de loi DADVSI ! (droits d'auteurs)
Reply

Marsh Posté le 30-01-2004 à 11:56:39    

jvois pas trop l'interet de refaire linux en objet, a la rigueur un autre kernel qui serait compatible.
de plus (et surtout) je trouve perso que g++ a encore trop de prob avec le c++ pour faire une truc vraiment propre (template et héritage multiple notament) sans compter les problèmes de perfs et de mémoire prise.
Kit a refaire le kernel dans un autre langage, il y a peut etre d'autres langages objets plus interessant.
 
D'un autre coté c'est vrai que ca simplifierait surement l'écriture, mais bon linux propose déjà de nombreuses couches d'abstraction pour simplifier le travail.

Reply

Marsh Posté le 30-01-2004 à 12:17:05    

J'ai pas le recul pour juger de quoi que ce soit, mais y'a eu une news sur kernel trap qui en parlait, ici : http://kerneltrap.org/node/view/2067
 
Il y a une citation de Linus Torvalds :
 


During the recent discussion, when it was suggested that perhaps the kernel is written in C simply because "we've always done it that way...", Linux creator Linus Torvalds joined in to explain:
 
    "In fact, in Linux we did try C++ once already, back in 1992. It sucks. Trust me - writing kernel code in C++ is a BLOODY STUPID IDEA.
 
    "The fact is, C++ compilers are not trustworthy. They were even worse in 1992, but some fundamental facts haven't changed: 1) the whole C++ exception handling thing is fundamentally broken. It's _especially_ broken for kernels. 2) any compiler or language that likes to hide things like memory allocations behind your back just isn't a good choice for a kernel. 3) you can write object-oriented code (useful for filesystems etc) in C, _without_ the crap that is C++."


 
@++

Reply

Marsh Posté le 30-01-2004 à 12:24:16    

ganjo a écrit :

jvois pas trop l'interet de refaire linux en objet, a la rigueur un autre kernel qui serait compatible.
de plus (et surtout) je trouve perso que g++ a encore trop de prob avec le c++ pour faire une truc vraiment propre (template et héritage multiple notament) sans compter les problèmes de perfs et de mémoire prise.
Kit a refaire le kernel dans un autre langage, il y a peut etre d'autres langages objets plus interessant.
 
D'un autre coté c'est vrai que ca simplifierait surement l'écriture, mais bon linux propose déjà de nombreuses couches d'abstraction pour simplifier le travail.


 
tu parles de perf et tu t'inquiètes même pas du temps que ça peut prendre de traverser toutes ces couches d'abstraction ? On a l'impression quand on voit toute ces couches que les devel ont essayé de faire de l'objet avec du C :/
pb : il n'en a pas les avantages, c'est pénible à maintenir, etc ...
et je vois pas en quoi écrire les drivers en c++ poserait un pb de performance, je ne parle pas ici de réécrire tout le kernel
 
en plus on parle depuis un moment de faire une interface pour que les drivers proprio puissent se greffer plus facilement, chose à laquelle linus est opposé, mais ça serait plus simple à implémenter en objet, en créant une interface qui serait implémenter par les drivers proprio :o

Reply

Marsh Posté le 30-01-2004 à 12:28:09    

Evadream -jbd- a écrit :

J'ai pas le recul pour juger de quoi que ce soit, mais y'a eu une news sur kernel trap qui en parlait, ici : http://kerneltrap.org/node/view/2067
 
Il y a une citation de Linus Torvalds :
 


During the recent discussion, when it was suggested that perhaps the kernel is written in C simply because "we've always done it that way...", Linux creator Linus Torvalds joined in to explain:
 
    "In fact, in Linux we did try C++ once already, back in 1992. It sucks. Trust me - writing kernel code in C++ is a BLOODY STUPID IDEA.
 
    "The fact is, C++ compilers are not trustworthy. They were even worse in 1992, but some fundamental facts haven't changed: 1) the whole C++ exception handling thing is fundamentally broken. It's _especially_ broken for kernels. 2) any compiler or language that likes to hide things like memory allocations behind your back just isn't a good choice for a kernel. 3) you can write object-oriented code (useful for filesystems etc) in C, _without_ the crap that is C++."


 
@++


 
la gestion des exceptions est cassée en c++ ?  :heink:


---------------
Non au projet de loi DADVSI ! (droits d'auteurs)
Reply

Marsh Posté le 30-01-2004 à 12:31:30    

udok a écrit :

oui, pourquoi pas ? :o
on utilise du C depuis des lustres, avec les pb que celà comporte (lenteur de programmation, difficile à maintenir, etc ...)
 
évidemment pour tout ce qui est bas niveau, l'assembleur et le C reste de rigueur.
mais pour tout ce qui est driver, implémentation de protocole réseau etc ... ça permettrait de faire un code bien plus propre, plus facile à maintenir, plus rigoureux (devra repecter les interfaces proposer)
un langage a besoin de temps pour murrir, mais maintenant, le C++ est un langage aboutit, avec norme ISO et tout ce qu'il faut, largement utilisé de par le monde
alors pourquoi pas ? de nombreux développeurs ont l'air de vouloir ça en tout cas, mais ça ne semble pas être au gout de la haute hiérarchie :/


[:rofl]
dis moi t as deja codé en C ??
 
t as deja ouvert un kernel Linux ou Unix ??
 
 
[:meganne]


Message édité par Tomate le 30-01-2004 à 12:31:51

---------------
:: Light is Right ::
Reply

Marsh Posté le 30-01-2004 à 12:36:21    

j'attends que taz passe sur ce sujet qu'on rigole 2 minutes  :D

Reply

Marsh Posté le 30-01-2004 à 12:37:17    

ça sent le troll de compet' donc [:drapo]


---------------
-~- Libérez Datoune ! -~- Camarade, toi aussi rejoins le FLD pour que la flamme de la Révolution ne s'éteigne pas ! -~- A VENDRE
Reply

Marsh Posté le 30-01-2004 à 12:37:17   

Reply

Marsh Posté le 30-01-2004 à 12:38:19    

ouais je pense niveau perf cest pas comparable, je parle pas des choses basiques, mais des trucs specifique c++ comme les template, ou encore l'héritage ou les exceptions.
 
Les couches d'abstraction ne prennent tant de temps que ça, après tout c'est juste des fcts qui regroupent a peine plus que se qu'on aurait été obligé d'écrire, la baisse de perf est plutot minime. De plus meme en c++, les 2 desavantages seraient cumulés : c++ et couche d'abstraction.

Reply

Marsh Posté le 30-01-2004 à 12:47:53    

black_lord a écrit :

j'attends que taz passe sur ce sujet qu'on rigole 2 minutes  :D  


 
[:fight]

Reply

Marsh Posté le 30-01-2004 à 12:48:33    

tomate77 a écrit :


[:rofl]
dis moi t as deja codé en C ??
 
t as deja ouvert un kernel Linux ou Unix ??
 
 
[:meganne]


 
oui, justement ... tu as déjà fait de l'objet ? tu sais à quoi ça sert ?  :heink:


---------------
Non au projet de loi DADVSI ! (droits d'auteurs)
Reply

Marsh Posté le 30-01-2004 à 12:49:12    

ah non, pas taz, on a jamais vu un intégriste pareil !  :o


---------------
Non au projet de loi DADVSI ! (droits d'auteurs)
Reply

Marsh Posté le 30-01-2004 à 12:52:40    

ganjo a écrit :

ouais je pense niveau perf cest pas comparable, je parle pas des choses basiques, mais des trucs specifique c++ comme les template, ou encore l'héritage ou les exceptions.
 
Les couches d'abstraction ne prennent tant de temps que ça, après tout c'est juste des fcts qui regroupent a peine plus que se qu'on aurait été obligé d'écrire, la baisse de perf est plutot minime. De plus meme en c++, les 2 desavantages seraient cumulés : c++ et couche d'abstraction.


 
[:mouais]
mais l'un des grand intéret de l'objet c'est justement de pouvoir poser simplement une couche d'abstraction hein  [:alexandre_cmcom]  
les exceptions sont justement bien plus propre et surement aussi rapide que les messages d'erreurs, et si on a besoin de communiquer par envoie de message, rien n'empeche de le faire : c++ apporte des trucs, mais n'en enleve pas (à par les défauts)
reste les templates, mais je suis pas sur de leur utiliter ici [:kc] (pas obliger d'utiliser ce qui sert pas)


---------------
Non au projet de loi DADVSI ! (droits d'auteurs)
Reply

Marsh Posté le 30-01-2004 à 13:03:59    

black_lord a écrit :

j'attends que taz passe sur ce sujet qu'on rigole 2 minutes  :D  


 
[:++taz]
 
 


---------------
brisez les rêves des gens, il en restera toujours quelque chose...  -- laissez moi troller sur discu !
Reply

Marsh Posté le 30-01-2004 à 13:04:41    

tomate77 a écrit :


[:rofl]
dis moi t as deja codé en C ??


 
mOI OUI? ET LARGEMENT PLUS QUE TOI? ET JE CONFIRMS; sORS UN PEU DE TA GROTTE /O


---------------
brisez les rêves des gens, il en restera toujours quelque chose...  -- laissez moi troller sur discu !
Reply

Marsh Posté le 30-01-2004 à 13:05:57    

udok a écrit :


en plus on parle depuis un moment de faire une interface pour que les drivers proprio puissent se greffer plus facilement, chose à laquelle linus est opposé, mais ça serait plus simple à implémenter en objet, en créant une interface qui serait implémenter par les drivers proprio :o


 
Ca marche pas, l'ABI C++ est cassée a chaque nouvelle version de gcc, tu introduirais encrore plus d'incompatibilité qu'aujourd'hui.


---------------
brisez les rêves des gens, il en restera toujours quelque chose...  -- laissez moi troller sur discu !
Reply

Marsh Posté le 30-01-2004 à 13:06:28    

udok a écrit :


 
oui, justement ... tu as déjà fait de l'objet ? tu sais à quoi ça sert ?  :heink:  

oue j ai meme refais un compilo si tu veux tout savoir :o


---------------
:: Light is Right ::
Reply

Marsh Posté le 30-01-2004 à 13:07:10    

kadreg a écrit :


 
mOI OUI? ET LARGEMENT PLUS QUE TOI? ET JE CONFIRMS; sORS UN PEU DE TA GROTTE /O

les caps cai mal :o


---------------
:: Light is Right ::
Reply

Marsh Posté le 30-01-2004 à 13:07:54    

je crois que le prolème c'est qu'à la création de linux, le c++ était encore en mouvement, et qu'écrire un compilateur c++ est infiniment plus compliqué que d'écrire un compilateur C, ce qui fait qu'on a des compilateurs C à peu près partout. enfin, c'est un choix


Message édité par Taz le 30-01-2004 à 13:08:03
Reply

Marsh Posté le 30-01-2004 à 13:08:19    

kadreg a écrit :


 
mOI OUI? ET LARGEMENT PLUS QUE TOI? ET JE CONFIRMS; sORS UN PEU DE TA GROTTE /O


 
ils essaient de simuler, avec toutes ces couches, le comportement natif d'un langage objet et tu maintiens que, dans ces circonstances, le C est plus facile à maintenir que du C++ ?  [:mouais]


---------------
Non au projet de loi DADVSI ! (droits d'auteurs)
Reply

Marsh Posté le 30-01-2004 à 13:08:24    

tomate77 a écrit :

les caps cai mal :o


 
j'ai des problèmes de cla


---------------
brisez les rêves des gens, il en restera toujours quelque chose...  -- laissez moi troller sur discu !
Reply

Marsh Posté le 30-01-2004 à 13:08:47    

kadreg a écrit :


 
j'ai des problèmes de cla

argument pipo :o


---------------
:: Light is Right ::
Reply

Marsh Posté le 30-01-2004 à 13:09:59    

udok a écrit :


 
ils essaient de simuler, avec toutes ces couches, le comportement natif d'un langage objet et tu maintiens que, dans ces circonstances, le C est plus facile à maintenir que du C++ ?  [:mouais]


 
Non, je suis d'accord avec toi. C'est plus simple d'utiliser un langage supportant directement les paradigmes objets que d'essayer de se les émuler à la mano. De la même façon que faire du C++ reflexif, ça fait mal au cul lorsque l'on a utilisé des langages l'intégrant directement.


---------------
brisez les rêves des gens, il en restera toujours quelque chose...  -- laissez moi troller sur discu !
Reply

Marsh Posté le 30-01-2004 à 13:13:23    

pour les couches d'abstraction d'accord, mais il faut bien les ecrires, faire des interfaces... se qui rajoute toujours du code. Pour les exceptions, je ne suis pas daccord avec toi, perso je trouve ça laid (mais tout est question de gout) et de part le macanisme meme, je ne vois pas comment ça pourrait etre plus rapide, bien sur ca permet de tester tout un bout de code plutot que de verifier le retour de chaque fct.  
Bon comme tu dis on peut bien melanger le meilleur des 2 mondes, mais pour moi cest se qui est de plus laid en c++, c'est davoir du C au milieu, jpense que ca ne peut que brouiller les developpeurs tiers.
 
En effet on peut trouver des moyens de se passer des templates, mais bon ca obligerait de se passer des conteneurs, string et cie (quoique ca ne serait pas plus mal, vu la lenteur de certains d'entre eux).
 
De plus je pense vraiment qu'auncun compilo est au point la dessus, leur gestion mémoire est souvent douteuse et rend le debug souvent hardu.
Bref vous l'aurez compris je suis pas fan du C++, meme si jaime pourtant beaucoup certains langages objets : ocaml, squeak(samlltalk), ruby...
 
D'un autre coté certains kernel sont codés en c++ et fonctionne très bien (BeOS notament je crois)


Message édité par ganjo le 30-01-2004 à 13:17:19
Reply

Marsh Posté le 30-01-2004 à 13:16:06    

kadreg a écrit :


 
Ca marche pas, l'ABI C++ est cassée a chaque nouvelle version de gcc, tu introduirais encrore plus d'incompatibilité qu'aujourd'hui.


 
et c'est typique au compilateur g++ ou c'est l'abi qui n'est pas bonne ?


---------------
Non au projet de loi DADVSI ! (droits d'auteurs)
Reply

Marsh Posté le 30-01-2004 à 13:39:39    

udok a écrit :


 
et c'est typique au compilateur g++ ou c'est l'abi qui n'est pas bonne ?


 
Non, c'est g++ qui fait la nouille


---------------
brisez les rêves des gens, il en restera toujours quelque chose...  -- laissez moi troller sur discu !
Reply

Marsh Posté le 30-01-2004 à 13:42:20    

Les vrais OS sont codés en assembleur, le seul langage proche de la machine, donc vraiment optimisé.
 
Coder un OS en C/C++, c'est comme faire une page Web avec Dreamweaver.

Reply

Marsh Posté le 30-01-2004 à 13:43:58    

Docteur_Canard a écrit :

Les vrais OS sont codés en assembleur, le seul langage proche de la machine, donc vraiment optimisé.
 
Coder un OS en C/C++, c'est comme faire une page Web avec Dreamweaver.


 
T'es un champion toi [:rofl]

Reply

Marsh Posté le 30-01-2004 à 13:44:25    

Et puis c'est un tel plaisir de coder de l'assembleur !

Reply

Marsh Posté le 30-01-2004 à 13:47:37    

Docteur_Canard a écrit :

Les vrais OS sont codés en assembleur


 
Linux n'est pas un vrai OS :o
Windows 95 est un vrai OS
 
[:gratgrat]


---------------
brisez les rêves des gens, il en restera toujours quelque chose...  -- laissez moi troller sur discu !
Reply

Marsh Posté le 30-01-2004 à 13:51:13    

tsss, l'assembleur trop loin de la machine encore, les vrais de vrai ils ecrivent directement en hexa leur binaire

Reply

Marsh Posté le 30-01-2004 à 13:51:50    

ganjo a écrit :

tsss, l'assembleur trop loin de la machine encore, les vrais de vrai ils ecrivent directement en hexa leur binaire

moi j code en binaire [:zytrayaisse]


---------------
:: Light is Right ::
Reply

Marsh Posté le 30-01-2004 à 14:03:26    

1) Performances: à condition d'éviter les fonctions vraiment objet (= virtual), je ne vois pas le problème.
 
2) Utilité: ça permet d'utiliser les objets (encapsulation des données privées), les exceptions (utile ?), les templates (très utile !), les const, les références, etc.
 
3) Portabilité: à part pour Linux-Embeded, je ne vois pas le problème
 
4) Probabilité que ça arrive: = 0, mais je ne sais pas pourquoi.

Reply

Marsh Posté le 30-01-2004 à 14:13:39    

De l'objet en pétant le mécanisme de redéfinition, je vois pas l'intêret. Déjà que ce mot clef virtual est une merde sans nom :o
 


---------------
brisez les rêves des gens, il en restera toujours quelque chose...  -- laissez moi troller sur discu !
Reply

Marsh Posté le 30-01-2004 à 14:32:00    

kadreg a écrit :

De l'objet en pétant le mécanisme de redéfinition, je vois pas l'intêret. Déjà que ce mot clef virtual est une merde sans nom :o


 
1) Pour avoir des struct avec des champs "private", et cacher les détails de telle ou telle implémentation de l'interface publique. Particulière utile pour le support multi-architectures.
 
2) Pour avoir des valeurs par défaut
 
3) Pour faire "io->write()" sur une instance de "BlockIO" dont on sait qu'elle contient en privé ce dont elle a besoin, sans être obligé de faire "write(&io, &myStructQuiVaBien, &MonVoidEtoile, ...)"
 
4) Pour surcharger le "=" en rajoutant les tests qui vont bien:  

Code :
  1. typedef struct size {
  2.    u8 s_;
  3.    inline struct size& operator= (const u8 v) {
  4.      if (debug && (s_ < 0) )
  5.        throw new BadValue("negative size" );
  6.    }
  7. };


 
5) Pour utiliser les templates
 
6) Pour faire du typage fort sur les fonctions qu'on passe en "void *" (cf la page de Bjarne Sroustrup)
 
7) Etc.

Reply

Marsh Posté le 30-01-2004 à 14:33:48    

Docteur_Canard a écrit :

Les vrais OS sont codés en assembleur, le seul langage proche de la machine, donc vraiment optimisé.
 
Coder un OS en C/C++, c'est comme faire une page Web avec Dreamweaver.

Harko :o

Reply

Marsh Posté le 30-01-2004 à 14:40:02    

glacote a écrit :


4) Probabilité que ça arrive: = 0, mais je ne sais pas pourquoi.

ben faudrait un compilo qui fonctionne déjà ! :D

Reply

Marsh Posté le 30-01-2004 à 15:55:49    

glacote a écrit :


1)
2)
3)
4)
5)
6)
7) Etc.


 
Ce sont exclusivements de paradigmes non Objets, puisque Ada83, pourtant bien procédural, avait toutes ces notions (sauf la surcharges  des opérateurs, mais c'est pas lié à l'objet non plus).


Message édité par kadreg le 30-01-2004 à 15:56:20

---------------
brisez les rêves des gens, il en restera toujours quelque chose...  -- laissez moi troller sur discu !
Reply

Marsh Posté le    

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed