Articles précédents : Debian
- [2] Les nouvelles hebdomadaires de debian - 10 septembre 2001
- [8] Les nouvelles hebdomadaires de debian - 3 septembre 2001
- [8] Packages Berlin réalisés pour Debian
- [72] Debian GNU/Linux pour les réfugiés de Be
- [9] Les nouvelles hebdomadaires Debian - 14 août 2001
- [117] Une distribution Debian orientée multimédia
- [33] Debian porté sur plateforme OpenBSD ?
- [13] Debian Weekly News, 25 juin 2001 et 1er juillet 2001
- [29] Woody passe en frozen!
- [0] Nouvelles Neuves de Debian
Liens connexes
- Debian GNU/Hurd (1610 hits)
- G1, infos pour l'installation (685 hits)
- FTP principal (423 hits)
- FTP miroir (384 hits)
- Source : OSNews (367 hits)
Dépêche modérée par
C'est pour l'instant plus une curiosité qu'un système utilisable, mais avec cette distribution, l'installation de Hurd devient (enfin!) relativement accessible.
![[fr]](../../../images/fr.png)
Debian GNU/Hurd (1610 hits)![[en]](../../../images/en.png)
G1, infos pour l'installation (685 hits)-
FTP principal (423 hits)
-
FTP miroir (384 hits)
-
Source : OSNews (367 hits)
> Lire la dépêche (80 commentaires, moyenne: 2,7).
[+] essai...
ARF ARF... On va enfin pouvoir la tester !
-
[+] [^]Re: essai...
Posté par Anonyme () le 19/10/2001 à 08:34. (lien). Évalué à -16.Heeuuu, peux-tu préciser le fond de la pensée profonde de ton commentaire, parce que là, je ne capte pas grand chose: des CD d'install sont disponible, on nous dit que c'est plutôt pour tester, et toi tu nous apprends qu'on va enfin pouvoir tester!! Ouaaaa, mazette...
-
[+] [^]Re: essai...
Posté par istyar () le 19/10/2001 à 08:54. (lien). Évalué à -11.Depuis le temps qu'ils en parlent !
-
[+] [^]Re: essai...
Posté par Anonyme () le 19/10/2001 à 09:43. (lien). Évalué à -9.Les commentaires inutils sont réservés à la tribune libre... si tout le monde dit 'Ouais, c'est cool' à chaque fois que quelque chose de cool est annoncé sur linuxfr, on risque d'avoir de plus en plus de mal à trouver les commentaires intéressants!
-
[+] [^]Re: essai...
Posté par Ramón Perez (page perso, ) le 19/10/2001 à 10:00. (lien). Évalué à -7.>si tout le monde dit 'Ouais, c'est cool' à chaque fois que quelque chose de cool est annoncé sur linuxfr, on risque d'avoir de plus en plus de mal à trouver les commentaires intéressants!
Ouais, t'as raison, c'est cool.
-
-
-
-
[^]Re: essai...
Posté par Yannick Thebault (page perso, ) le 19/10/2001 à 10:19. (lien). Évalué à 1.En effet moi j'avais essayé il y a quelques mois la H1 et j'avais pas reussi.
Bon d'accord je n'y avais passé que quelques heures.
La "Task List " est plustôt impressionnante
http://www.debian.org/ports/hurd/hurd-devel-tasks(...)
Je ne pensais pas qu'il manquait autant de choses : pas de character device (donc pas de X), pas de ppp, pas de POSIX Thread... la liste est bien longue.
Mais le moins qu'on puisse dire c'est que les développeurs semblent très bien organisés et méthodiques.
J'ai vraiment hâte que ce projet avance un peu pour voir ce que donne le noyau Gnu Mach en terme de performances.
-
[^]Re: La "Task List " est plustôt impressionnante
Posté par Frédéric RISS () le 19/10/2001 à 08:34. (lien). Évalué à 28.Je me suis intéressé dernièrement au Hurd, et contrairment à ce que tu dis, il semble que X fonctionne (je sais plus trop où je l'ai lu, qq part sur http://www.gnu.org/software/hurd/(...)). Par contre effectivement, le support pthread n'est pas au point et donc pas question de faire tourner Gnome ou KDE. Par contre Windowmaker, fvwm ou encore Blackbox fonctionnent très bien.
-
[^]Re: La "Task List " est plustôt impressionnante
-
[^]Re: La "Task List " est plustôt impressionnante
Posté par Wi][ish () le 19/10/2001 à 08:45. (lien). Évalué à 8."X fonctionne"
Effectivement, il semble qu'il y ait un support "experimental" des characters device.
ftp://alpha.gnu.org/gnu/hurd/contrib/marcus/gnumach-char/(...)
Quelqu'un a-t-il essayé X sur Hurd ?
Est-ce du framebuffer ?
-
[^]Re: La "Task List " est plustôt impressionnante
Posté par manu manu sauvage (page perso, ) le 19/10/2001 à 12:22. (lien). Évalué à 11.> Par contre effectivement, le support pthread
> n'est pas au point et donc pas question de faire
> tourner Gnome ou KDE.
Pour information, KDE n'utilise pas les threads,
mais est base sur une approche processus (donc
fork()). Pour Gnome je ne sais pas, donc je ne
me risque pas a dire de betise.
mms.-
[^]Re: La "Task List " est plustôt impressionnante
Posté par Nicolas Roard (page perso, ) le 19/10/2001 à 14:08. (lien). Évalué à 8.Sauf que la Qt 3.0 utilise les threads et
si je me souviens bien, la politique de KDE
en ce moment c'est "utilisez les threads" pour
la prochaine version de KDE ...-
[^]Re: La "Task List " est plustôt impressionnante
Posté par Sebastien (page perso, ) le 19/10/2001 à 20:23. (lien). Évalué à 2.Qt 2 aussi pemret de faire de threads, mais KDE ne n'utilise pas. Par contre, des appli pour KDE en de hors du projet KDE utlise les threads Qt.
ps : compiler KDE 3 alpha1 avec QT 3, ça se fait pas tout seul, il faut bien bidouiller, mais c'est bon quand même :p
-
-
-
-
[^]Re: La "Task List " est plustôt impressionnante
Posté par Wawet76 (page perso, ) le 19/10/2001 à 08:48. (lien). Évalué à 29.Si j'ai bien tout comprit, les performances ne seront pas le point fort du Hurd. (d'ailleurs ce n'est pas dans la liste d'avantage qu'il y a sur leur site : free, compatible, built to survive, scalable, extensible, stable, exists)
En gros le but est de faire un noyau extrement modulable, avec la possibilité pour les utilisateurs de charger des "modules" (server) qui pourrons crouter sans embêter les autres.
Ce qui parrait très sympatique par contre, c'est la mécanique de "translator" qui doit permettre de très simplement monter un site ftp sur le filesystem ou bien crypter ou compresser des fichiers à la volée.
De la lecture sur le Hurd pour les transports en communs :
http://www.gnu.org/software/hurd/hurd-paper.html(...)
http://www.gnu.org/software/hurd/hurd-talk.html(...)
(le premier m'a fait rater une gare de RER il y a deux ans vers 1h30 du matin. Resultat : 2 heures d'attente dehors en hivers avant d'en avoir un autre dans l'autre sens. Heureusement que j'avais de la lecture)
-
[^]Re: La "Task List " est plustôt impressionnante
Posté par Jerome Demeyer () le 19/10/2001 à 08:49. (lien). Évalué à 9.Effectivement, j'ai l'impression que Hurd, c'est un noyau pas fini et des translators*... c'est tout ?
Ce qui m'étonne, c'est que des distrib comme mkLinux étaient basées sur un noyau Mach, mais bon c'était un noyau mach qui ne lance qu'un seul serveur : un noyau linux... mais MacOS-X lui-même n'est t'il pas basé sur un noyau Mach ? J'aimerais savoir : comment se fait t'il qu'il soit si peu avancé ? (le noyau Mach, pas MacOSX...)
Sinon, pour ceux qui veulent tester, les packages Debian sont juste à recompiler : apt-get source -b <pkg> à la place de apt-get install <pkg>.
*Translator : (fr. traducteur) un daemon qui permet d'avoir un interface type file-system est un translator. Les translators permettent d'accéder aux partitions, CD, nfs et meme de transformer une connexion ftp en partition locale, par exemple.-
[^]Re: La "Task List " est plustôt impressionnante
Posté par Wawet76 (page perso, ) le 19/10/2001 à 08:55. (lien). Évalué à 7.Il n'y a pas un noyau Mach, mais tout plein.
The Hurd est passé sur un noyau GNUMach qui n'est pas forcement au même état d'avancement que ceux de MacOSX ou mkLinux.-
[^]Re: La "Task List " est plustôt impressionnante
Posté par Jerome Demeyer () le 19/10/2001 à 09:09. (lien). Évalué à 15.ok, je comprend mieux... je ne pensait pas qu'ils avaient refait leur implémentation Mach. Ca fait assez longtemps qu'ils sont dessus, quand meme.
Hurd m'intrigue... j'ai l'impression que c'est un fantasme d'ingénieurs informaticiens (interdiction de rire, le terme à été pourri il y a peu) : Hurd propose une plateforme qui ne reboote jamais...un micronoyau ne s'occupant pas de grand chose, seuls les services sont à gerer ?
Si Hurd arrive à ses fins, il fera plus mal aux Unix que linux, mais bon ca sera d'ici 4 à 6 ans, le temps qu'il soit terminé, stabilisé, emancipé et surtout promu.
--
Vivement demain !-
[^]Re: La "Task List " est plustôt impressionnante
Posté par zen () le 19/10/2001 à 09:27. (lien). Évalué à 9.Si je ne me trompe pas le hurd tourne sous 2 micro kernel gnu mach et os-kit mach. Le second étant une implémentation de mach avec os-kit ( cf http://www.cs.utah.edu/flux/oskit/(...) ). gnumach doit fonctionner avec les drivers linux 2.0.x os-kit driver linux 2.2.x.
Des personnes veulent aussi porter le hurd sur L4 ( cf http://mail.gnu.org/mailman/listinfo/l4-hurd(...) et http://www.l4ka.org/(...) ).
Le noyau L4 aurait pour avantage d'être plus activement développer que mach. Et L4 est déjà porté sur plusieurs plateformes.-
[^]Re: La "Task List " est plustôt impressionnante
Posté par Yann Droneaud (page perso, ) le 19/10/2001 à 14:10. (lien). Évalué à 7.Bon on vas clarifier un les choses,
il y a un projet, ou plutot une idee de porte Hurd sur d'autre micro noyaux et en particulier L4.
Mais Hurd a ete depuis le debut developper pour Mach, il n'est pas vraiment portable.
GNUmach, c'est Mach 4 du CMU (en gros) adopté par le projet GNU.
Le probleme de GNUmach c'est qu'il est out of date
depuis le debut. Il est uniquement utilisable sur plateforme x86 (bien que le noyau Mach original a été porté sur la pluparts des architectures). Il ne supporte quasiment aucun materiel recent
(bien qu'une implementation de GNUmach utilisant
l'oskit existe, ce n'est pas encore la panacé mais c'est une voie a suivre),
et ce qui me parait le plus grave pour un
micro noyau (pour ma definition personnelle, et je ne parle pas de sa taille mais des fonctionnalités) c'est qu'il embarque en dur tout
ses drivers, pas de kernel module, ni la possibilité d'avoir des drivers tournant comme une tache en mode pseudo utilisateur (comme les autres serveurs de Hurd).
Le principe du micro noyau est excellent (quoiqu'en pense Linus), associé au principe du multi serveurs (comme Hurd, pas comme les systemes qui utilisaient un unique serveur emulateur d'unix), ca me parait etre la solution la plus pertinente, souple, fiable, etc..., mais cette solution demande beaucoup de reflexion et une rigueur extreme.
Le seul projet presque de ce type est a ma connaissance Amoeba.
Si avec les ISOs de la Debian Hurd, le systeme GNU
peut gagner plus de developpeur ce seras parfait
mais il ne faut pas que ca devienne l'anarchie comme Linux ...-
[^]Re: La "Task List " est plustôt impressionnante
Posté par Silence (page perso, ) le 19/10/2001 à 14:57. (lien). Évalué à 6._quoiqu'en pense Linus_
AMHA aussi d'ailleurs, toutes c'est figures de style bouffe BEAUCOUP de CPU, c'est un peu le probleme. Mon noyeau j'aime k'il bosse, pas k'il fasse de politesse...
Je me trompe probablement mais perdre tout ce temps, pour les quelques fonctionnalite apportees c'est vraiment cher paye le mount -t FTP...
_mais il ne faut pas que ca devienne l'anarchie comme Linux_
peut tu detailler ce point parce que la, je ne te suis pas (sans mechancete aucune)--
^d^c-
[^]Re: La "Task List " est plustôt impressionnante
Posté par Etienne () le 19/10/2001 à 15:59. (lien). Évalué à 2.pour le mount -t ftp , il y a un projet sur linux.
Il me semble que c'est http://sourceforge.net/projects/ftpfs/(...)
ca permet de faire un
$ mount -t ftpfs ...
-
[^]Re: La "Task List " est plustôt impressionnante
Posté par Yann Droneaud (page perso, ) le 19/10/2001 à 20:35. (lien). Évalué à 7.Quand je parle d'anarchie, je parle du manque
de continuité, de stabilité dans le developpement:
o changements d'api,
o tout les drivers integré dans la meme arboresence
o les differentes branches
Au niveau performance, c'est sur que l'on peu se poser des questions,
voici encore la mon point de vue:
- un kernel monolithique super optimiseé (voire meme ecrit en assembleur ;)
Il sera forcement rapide (le code), mais pas gerable a long terme, presque immodifiable
et a terme les performances seront diminué car
le systeme deviendra un gros melange de tache intercroise pour pouvoir assuer toutes les nouvelles fonction.
- micro noyau et des serveurs: lenteur du a la commutation des taches, mais les elements sont
mieux concus, mieux reparti, le systeme peut etre plus scalable. Il sera plus facilement evolutif
et meme plus simple a comprendre
De plus je pense que le parametre vitesse, est un peu obsolete, compte tenu des architectures modernes.-
[^]Re: La "Task List " est plustôt impressionnante
Posté par Anonyme () le 19/10/2001 à 21:05. (lien). Évalué à 3.(voire meme ecrit en assembleur ;)
Ah bah bravo la portabilité ;)
Bon, plus sérieusement, il y a quand même un avantage non négligeable au micro-noyau, c'est qu'on peut remplacer à chaud les serveurs qui tournent dessus. Ce qui fait qu'on peut patcher un OS sans avoir à rebooter... (tant que ce n'est pas le micro-noyau qu'il faut patcher)
Sur des gros serveurs qui peuvent mettre plusieurs dizaines de minutes pour booter (si, si, ça existe), ça peut être très pratique...
-
[^]Re: La "Task List " est plustôt impressionnante
-
-
-
-
-
[^]Re: La "Task List " est plustôt impressionnante
Posté par Jak () le 19/10/2001 à 10:07. (lien). Évalué à 1.j'ai l'impression que c'est un fantasme d'ingénieurs informaticiens
Non, plutôt orienté recherche universitaire.--
« Le savoir, n'est-ce pas, est un bien précieux. Trop précieux pour ne pas être partagé. »
- Battologio d'Epanalepse, in De Cape et de Crocs, Acte VII (Ayroles & Masbou)
-
-
[^]Re: La "Task List " est plustôt impressionnante
Posté par Paerro Trime () le 19/10/2001 à 10:57. (lien). Évalué à 1.On dirait que c'est surtout les serveurs et les libs qui sont pas trop finis.
En gros (simplifions, simplifions, ...) MkLinux avait un seul serveur qui émulait un linux. MacOS X a un seul serveur qui émule un FreeBSD. Et Hurd a tout plein de serveurs qui font , euh, tient ça se complique là, je crois que je vais aller relire la doc...
-
-
Une FAQ sur Hurd en fr
Voici une petite faq en français sur Hurd pour savoir de quoi il retourne exactement...
http://www.multimania.com/nek/os/hurd.htm(...)
-1 parce que ca fait pas avancer le schmilblik :)
-
[^]Re: Une FAQ sur Hurd en fr
Posté par zen () le 19/10/2001 à 08:47. (lien). Évalué à 16.Pour une doc sur le HURD en francais on peut voir aussi :
http://www.hurd-fr.org/docfr.php(...)
-
[^]Re: Une FAQ sur Hurd en fr
Posté par Wi][ish () le 19/10/2001 à 08:53. (lien). Évalué à 3."ca fait pas avancer le schmilblik"
Non, au contraire la page est très instructive.
La section 4 (le net est à vous) laisse rêveur :
"Les noeuds du reseau apparaissent comme des sous-repertoires dans votre arborescence..."
"Vous savez creer un lien sur un fichier? Vous pouvez creer de la meme maniere un lien sur le serveur du Centre National de Mycologie Appliquee du Djibouti."
-
[^]Re: Une FAQ sur Hurd en fr
Posté par Yusei (page perso, ) le 19/10/2001 à 09:02. (lien). Évalué à 6.Lu sur cette FAQ: "En gros, c'est l'Emacs des systemes d'exploitation."
Vous avez frissoné en regardant Emacs, vous trrrremblerrrez en essayant Stallman II, le Retour (dit The Hurd)
Euh, le vi des systèmes d'exploitation c'est quoi ?
(oui bon ok, -1)
[+] C'EST PAS LA MANDRAKE
[+] Et sinon?
Moi j'aimerais bien savoir sur quel genre de matos on peut l'installer ?
J'ai un 486 avec 200Mo de dd (ram ?, cpu ? ), est ce que ça passe?
Parce que c'est bien beau de vouloir le faire tester, mais a la fin je suis en panne de machines moi.
-
[+] [^]Re: Et sinon?
Posté par Ramón Perez (page perso, ) le 19/10/2001 à 10:03. (lien). Évalué à -3.et sinon, je peux repasser le prendre vers quelle heure ?
-
[^]Re: Et sinon?
Posté par Benjamin Drieu (page perso, ) le 19/10/2001 à 10:27. (lien). Évalué à 3.Non, cf le changelog : la fpe ne fonctionne pas encore.
Ceci-dit, ils cherchent des contributeurs pour porter celle de Linux. ;-)
POO ?
Y'a un truc que je ne saisie pas, HURD est Orienté Objet, et je viens de mater les sources en C.
Le C n'est pas orienté objet ? à moins que j'ai raté une étape ?
-
[^]Re: POO ?
Posté par Wawet76 (page perso, ) le 19/10/2001 à 08:52. (lien). Évalué à 14.Tu peux faire de la "conception objet" dans à peu près n'importe quel langage.
Les langages dit "objets" ou "à objets" apportent une syntaxe et des mécaniques qui favorisent la conception objet.
Voili voilou.
-
[^]Re: POO ?
Posté par Annah C. Hue (page perso, ) le 19/10/2001 à 08:54. (lien). Évalué à 7.Tu n'as pas besoin d'un langage objet pour programmer en objet. Ca aide, mais c'est pas strictemement nécessaire. Quand tu compiles un programme OO en C++, ça te génère de l'ASM, qui n'est pas à proprement parler un langage objet, et pourtant ton programme est orienté objet.
-
[+] [^]prem's
-
[+] [^]Re: prem's
Posté par Annah C. Hue (page perso, ) le 19/10/2001 à 09:42. (lien). Évalué à -2.A 2 minutes prêt... Rahhh je suis trop lent le vendredi :-)
-
-
[^]Re: POO ?
Posté par Bruno Adele (page perso, ) le 19/10/2001 à 09:02. (lien). Évalué à 2.Pourrais tu me montrer un petit exemple en C ou autre, car ca m'interesse de savoir comment il font. Si j'ai bien compris, c'est eux meme qui gerent les pointeurs des fonctions herité, etc ... ?
-
[^]Re: POO ?
Posté par G. R. (page perso, ) le 19/10/2001 à 09:29. (lien). Évalué à 8.Pour programmer en OO en C, voici un point de départ :
http://ldeniau.home.cern.ch/ldeniau/html/oopc/oopc.html(...)
Il s'agit d'une bibliothèque qui permet de programmer OO en C.
L'intérêt est de le faire sur des plateformes qui ne peuvent supporter un compilateur C++
HTH
-
[^]Re: POO ?
Posté par gui_ () le 19/10/2001 à 10:06. (lien). Évalué à 2.Tu peux aussi regarder le code de gtk+ ( http://www.gtk.org(...) ) qui utilise son propre mécanisme objet en C.
-
[^]Re: POO ?
Posté par Gaël Le Mignot (page perso, ) le 19/10/2001 à 10:13. (lien). Évalué à 5.Regarde du coté de gtk ( http://www.gtk.org(...) ). C'est totalement objet, mais en C. Si tu veux une implémentation d'un système d'objets en C qui ne soit pas lié à un toolkit, regarde: http://developer.gnome.org/doc/API/2.0/gobject/index.html(...)
En gros, pour l'héritage, en Gtk/GObject c'est fait ainsi:
struct _bar_t
{
struct _foo_t foo;
...
}
Et tu as 'bar' qui hérite de 'foo'...
Et après tu peux utiliser les fonctions de plus bas niveau (par exemple en Gtk tu peux faire un
gtk_widget_show() sur tous les widget, que ce soit un GtkButton ou un GtkFileSelectionDialog)-
[^]Re: POO ?
Posté par Gnurou (page perso, ) le 19/10/2001 à 10:48. (lien). Évalué à 1.Pour compléter un peu l'explication de Kilobug:
Bien evidemment, il faut faire du forcage de type quand tu appelle les functions s'appliquant à _foo_t avec _bar_t. Et en cas d'héritage multiple, tu n'as pas d'autre choix que de faire un peu d'arithmétique de pointeur... Mais ça marche très bien. A moins que quelqu'un ne connaisse une autre solution?
-
[^]Re: POO ?
Posté par Bruno Adele (page perso, ) le 19/10/2001 à 12:16. (lien). Évalué à 1.Si j'ai bien compris, tu aura ceci.
struct Object2
{
struct Object1 // qui lui meme contient ObjectAbstract ?;
...
}
et
struct Object1
{
struct ObjectAbstract;
...
}
Ca veux donc dire que les structures peuvent avoir des fonctions ou procedures (Méthode) ? Si ce le cas, je ne le savais pas, d'autant plus qu'en C++ il conseille d'utiliser des Classes (Object) par raport aux structures.
Et par exemple si ObjectAbstract à une procedure (méthode) "Run", comment tu l'appelle depuis Object1 ?-
[^]Re: POO ?
Posté par Gnurou (page perso, ) le 19/10/2001 à 13:08. (lien). Évalué à 5.C'est relativement simple. Object1 est le premier élément de Object2, et ObjectAbstract le premier élément de Object1. Ce qui veut dire qu'en mémoire, si tu prends un pointeur vers un Object1 ou un Object2, il pointera vers les données de l'ObjectAbstract.
En ce qui concerne les classes, elles n'existent bien sûr pas en C, mais on peut facilement contourner le problème. En fait ce qui suit n'est que la manière donc le code C++ est interprété par le compilateur.
Disons que tu as une classe A (de mercedes):
class A
{
public:
A();
~A();
Run (int n);
private:
int i;
};
Comment le compilo peut-il traduire cela en C? Tout d'abord on regroupe les données de la classe en une struct (dont le données privées ne sont bien sûr pas accessible, mais ça en C c'est dur à controller):
struct A_struct
{
int i;
}
Et ensuite on écrit l'interface de la classe avec des fonctions C, dont le premier paramètre sera TOUJOURS un pointeur vers la structure dont elles sont l'interface:
/* constructeur et destructeur */
void A_init (struct A_struct * a);
void A_cleanup (struct A_struct * a);
/* Méthodes */
void A_Run (struct A_struct * a, int n);
Evidemment tu dois toi même appeler le constructeur et destructeur manuellement, et toujours passer ta structure aux méthodes de l'interface. Mais j'insiste sur le fait que c'est ainsi que cela se passe en interne. Si tu lances gdb sur un programme C++, tu verras que ça se passe en fait comme cela.
Ensuite, l'héritage... Soit la classe B:
class B : public A
{
....
};
En C on traduira comme Kilobug l'a dit par:
struct B
{
struct A struct_a;
}
Et comme les données en mémoire au début du pointeur de B sont les données de A (car elle a été déclarée au début de B), tu peux appeler A_Run comme ceci:
struct B monB;
A_Run ((A*)&monB, 2);
En faisant un simple forcage de type. Pour l'héritage multiple, comme je l'ai dit plus haut tu peux t'en sortir avec un peu d'arithmétique de pointeurs. C'est bien sûr moins pratique qu'un compilo C++ qui fera le boulot à ta place, mais ca peut être grandement utile et c'est bon à savoir.
Voila, j'espère avoir été clair :)-
[^]Re: POO ?
Posté par Bruno Adele (page perso, ) le 19/10/2001 à 14:27. (lien). Évalué à 1.>> struct B monB;
>>A_Run ((A*)&monB, 2);
Pas mal cette finte, d'utiliser le meme emplacement pour les pointeurs, ca ressemble un peux au UNION en C++, je supose que c'est ca qu'il utilise d'ailleur.
gnurou, merci pour ton exemple, il me permet de mieux comprendre.
-
-
[^]Re: POO ?
Posté par Pat _ () le 19/10/2001 à 13:10. (lien). Évalué à 1.tu utilises des pointeurs de fonctions.
et il n'y a pas de différence fondamentale entre object et struct, ce n'est qu'une différence de protection par défaut des proprietes et methodes.-
[^]Re: POO ?
Posté par Gnurou (page perso, ) le 19/10/2001 à 13:16. (lien). Évalué à 1.Tu peux utiliser des pointeurs de fonction pour émuler les méthodes, mais ça a le gros désavantage de te bouffer 4 octets (sur une machine 32 bits) par méthode que tu as déclaré dans ta classe pour chaque objet alloué, et surtout ce n'espt pas la manière de faire du C++ en interne, l'astuce consistant, comme je l'ai décrit plus haut, à faire passer un pointeur vers la structure en premier paramètre (caché, mais visible avec un débugger par exemple) aux méthodes de l'interface.
-
[^]Re: POO ?
Posté par Gaël Le Mignot (page perso, ) le 19/10/2001 à 13:24. (lien). Évalué à 1.L'utilisation des pointeurs de fonctions est nécessaire pour émuler les méthodes "virtuelles" du C++. Les compilo C++ en utilisent aussi. Sinon, comment fait-il lorsqu'il ne peut pas connaitre le type à l'exécution?
Si je définis une méthode foo virtuelle dans la classe a, et deux méthodes réelles différentes dans les classes b et c (héritant toutes les deux de a) et une fonction du type:
void bar(class_a *a)
{
a->foo();
}
Le compilo est bien obligé d'avoir des pointers de fonctions pour savoir quelle méthode appeler.
Il y a aussi une autre solution (utilisée dans GObject je crois) qui consiste a avoir une structure 'classe' contenant les pointeurs de fonctions, de l'instancier une fois lors de la création du premier objet d'un type donné. On a ainsi un pointeur vers la classe (donc 4 octets) par objet et non par coupe (méthode, objet).
Cependant, il faut voir que le principal problème des pointeurs de fonctions n'est pas les 4 octets de mémoire, mais le coût CPU. En effet, pour la plupart des processeurs, un 'indirect call' (appel à un pointeur de fonction) est beaucoup plus lent qu'un 'call' avec une adresse constant.-
[^]Re: POO ?
Posté par Gnurou (page perso, ) le 19/10/2001 à 14:14. (lien). Évalué à 1.Peu de compilateurs se servent de pointeurs de fonction dans les objets eux mêmes. Le mécanisme le plus utilisé est celui de la vtable, qui est une table contenant les pointeurs des fonctions virtuelles pour chaque CLASSE (et non objet). Pour les détails, voir l'excellent livre de Bruce Eckel "Thinking in C++" qui est disponible gratuitement en ligne, une vraie bible. En revanche, faire une implémentation du type vtable en C est relativement embêtant, étant donné que les appels de fonction virtuelles sont alors "spéciaux" et qu'il faut les gérer manuellement... On retrouve le même problème avec les pointeurs de fonction (amoindri certes) puisqu'il faut l'assigner manuellement... Enfin bref dans tous les cas c'est un beau bordel quand même, et quand on en vient à utiliser ces fonctionnalités (corrigez moi si je dis des conneries mais il me semble que les fonctions virtuelles ne sont pas spécifiquement de la POO) il vaut mieux changer pour un compilo C++ :)
Pour les appels à des pointeurs de fonction, je ne pense pas qu'il y ait le moindre surcoût. Après tout en assembleur x86, les fonctions sont appelés par leur adresse, non? Il ne s'agirait donc que du mécanisme naturel.
Ca devient Da Programmers French Page ici... ;)-
[^]Re: POO ?
Posté par Gaël Le Mignot (page perso, ) le 19/10/2001 à 14:26. (lien). Évalué à 4.* Pour les vtable et le fait que les pointers sont mémorisés par classe et non par objets, j'en ai parlé. Ce n'est ni compliqué, ni embètant de gérer tout ça en C, et ça évite d'avoir la lourdeur et les problèmes du C++ (comme la non-compatibilité entre les libs compilées avec g++ 3.0 et celles compilées 2.95)
* Pour les pointers de fonctions, si c'est beaucoup plus coûteux parce que les plupart des processeurs n'arrivent pas à prédire le branchement si l'adresse n'est pas constante, et donc il fait une 'misprediction' qui se solde par un flush du pipeline et un risque de cache-miss... Et tout ça ça coûte TRES cher en terme de perf.
Maintenant je n'ai plus fait d'assembleurs depuis les PII/K6 et donc je ne sais pas trop comment se comportent les processeurs + récents.-
[^]Re: POO ?
Posté par Gnurou (page perso, ) le 19/10/2001 à 14:50. (lien). Évalué à 0.Uhhh exact pour les pointeurs de fonctions. Je n'avais pas pensé au pipeline.
Pour le système de vtable en C, tu t'y prendrait comment? Ne faudrait-il pas rajouter des macros plein le code pour déterminer si une fonction est virtuelle ou non? Car comme durant la compilation le compilo C++ examine chaque appel de fonction pour savoir s'il doit être virtuel ou pas, il faut mettre un système similaire en place, et je ne vois pas trop comment faire sans noyauter chaque appel de fonction d'un objet avec une macro. Non pas que ce soit inefficace ou très lourd, mais je suis curieux de savoir s'il y a moyen de faire autrement.
-
[^]Re: POO ?
Posté par Paerro Trime () le 19/10/2001 à 23:45. (lien). Évalué à 2.Les processeur récents ont des pipelines plus longs (le ponpon, c'est le P4 et son pipeline à 20 étages) donc ça doit sans doute couter de plus en plus de cycles...
-
-
-
-
-
-
-
-
-
-
[^]Re: POO ?
Posté par Jean-Georges Pinna () le 19/10/2001 à 08:58. (lien). Évalué à 4.Ce qui fait qu'un programme est orienté objet c'est la conception et pas le langage, je me souviens avoir fait un petit programme "oriente objet" avec turbo pascal 4 qui n'etait pas du tout objet
-
[^]Re: POO ?
-
[^]Re: POO ?
Posté par bleh () le 19/10/2001 à 11:15. (lien). Évalué à 2.On peut faire de l'objet dans pratiquement tout les langages. La question est : quel est l'intérêt ?
Personnellement, il me semble que le choix d'un langage comme le C++ ou le Java serait plus adapté pour faire de la POO. Qui essaierait de faire du café avec une machine à laver ? Pour moi c'est un peu l'équivalent de faire de l'objet en C.
Je ne comprend pas l'acharnement de certain à utiliser le C coute que coute. Chaque langage a ses spécifictés, ses avantages, ses domaines de prédilection autant les utiliser.
Faire du calcul mathématique en POO n'est, par exemple, pas une super bonne idée. A titre d'exemple je rapporte une discussion entre 2 objets.
Dialogue entre l'objet "2" et l'objet "3" :
2> Salut 3 tu veux t'additionner avec moi ?
3> wi pourquoi pas
2> ok on y va
3> oula attends ... c'est quoi pour toi l'addition ?
...
Pas très efficace. Maintenant, je suppose qu'il y'a une raison au niveau du choix du C comme langage pour Hurd. Moi je la connais pas mais quelqu'un pourrait m'éclairer :-)-
[^]Re: POO ?
Posté par Anonyme () le 19/10/2001 à 11:57. (lien). Évalué à 1.deja pas mal de personnes ont appris le C et n'ont pas envie de passer au C++ (y'en a qui codent encore en fortran)
enfin, surtout, le C est plus 'universel'. tu vas toujours tomber sur un compilateur C++ qui ne va pas supporter les namespace/template/RTTI, etc...-
[^]Re: POO ?
Posté par Anonyme () le 20/10/2001 à 01:00. (lien). Évalué à 1.>deja pas mal de personnes ont appris le C et n'ont pas envie de passer au C++ (y'en a qui codent encore en fortran)
Ca fait toujours plaisir de voir les gens qui melangent les torchons et les serviettes. Le Fortran est un langage pour faire de l'analyse numerique, et non pas pour ecrire un systeme d'exploitation.
-
-
[^]Re: POO ?
Posté par Pat _ () le 19/10/2001 à 13:21. (lien). Évalué à 2.l'interet, c'est que tu peux utiliser le style et les methodes objets quand cela t'apporte quelque chose au niveau des algo ou de la simplicite de programmation, mais que quand tu veux optimiser, tu obtiens des perf correctes bien plus facilement (à ce sujet il y avait un article edifiant dans le dernier ou avant dernier LMF) ; et effectivement la portabilite joue.
-
HURD, successeur de linux?
L'architecture du HURD a été etudiée pour étre trés facilement évolutive, donc s'il faut changer tel ou tel partie du systéme la tache sera grave plus facile qu'avec un noyau monolithique.
Dans 6/8 ans, hurd remplacera peut étre linux...
-
[^]Re: HURD, successeur de linux?
Posté par Frederic Logier () le 19/10/2001 à 12:09. (lien). Évalué à 2.arrête ta psychohistoire Seldon...
La Fondation serait en marche ? :)
-1
La G1 n'est pas la premiere...
Petite rectification : la G1 n'est pas la<<premiere>> distribution de Debian/Hurd, loin de la.
Les CDs de la serie F permettaient aussi d'installer Hurd et de l'utiliser. Et je n'ai pas vu d'annonce sur un changement si significatif entre la serie F et la serie G (me trompe-je ?) -
Ronan
-
[^]Re: La G1 n'est pas la premiere...
-
[^]Re: La G1 n'est pas la premiere...
Posté par Anonyme () le 19/10/2001 à 09:24. (lien). Évalué à 4.C'est la première de la série G, considérée accessible. Elle n'est pas seulement destinée aux développeurs Hurd et passionnés d'OS, mais accessible aux utilisateurs de Linux qui s'y connaissent un minimum.
Ca reste du développement, donc la première sera la 1.0, mais celle-ci est la première à "sortir" du cercle des développeurs et passionnés.
[+] Hurd
yeaaaaaaaaaaaaaaah Debian et Hurd roulaize a donf !!!!
-
[^]Re: Hurd
Cette page a été générée par Templeet en 0.2478s (dont 0.0366 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.