> Dans le liens sur "oopc", rien que dans l'intro on apprend que le gars n'a rien compris au principes objet :
> Pointer to virtual member function handling polymorphism (too complex or slow)
L'auteur n'a pas voulu couvrir ça. Ça le regarde et ça ne montre en rien qu'il n'a rien compris aux principes objet.
> Et au contraire, les principes objet demandent une aide _enorme_ du langage.
Pour que le language soit objet, oui. Tu défonce une porte ouverte...
> Ce que l'on appelle de la programmation objet en C n'est autre que de la programation modulaire (ou legerement plus).
T'aimes ou t'aimes pas, mais ça existe, ça marche et c'est utilisé.
gobject montre que le C ne fait pas naturellement de l'objet.
> Un langage objet n'est pas la même chose que le langage C.
Personne n'a dit que le C était un langage objet. On dit que le C permet de faire de l'objet. Si l'objectif est de faire que de l'objet, le C est un très mauvais langage. Tout le monde est d'accord avec ça. Mais tous les développeurs C te diront qu'ils font parfois de l'objet même si ce n'est pas aussi "riche" et/ou confortable que d'utiliser directement le C++.
> Or maintenant on à réalisé des compilos qui concurence grandement le C (Eiffel, OCaml entres autres). Donc révisez votre jugement sur "l'objet c'est lent".
Trouves un benchmark qui montre ça. L'objet, si tu n'en a pas besoin (et souvent la programmation objet n'est pas nécessaire) est _forcément_ plus lent (il y a des indirections supplémentaires).
Si tu as besoin de programmer en objet, que le programme soit en C ou en C++, ça ira grosso-modo aussi vite.
> Pour revenir sur l'idée d'un OS tout objet: oui ce serrait biens car par exemple cela permettrait de cacher la notion de mémoire à un soft et ca se serait une enorme avancée!
Programmes en C++ ou python ou n'importe quoi qui t'évite d'utiliser malloc.
C'est n'importe quoi ton idée. Si l'objet est encapsulé/connu, tu n'as pas besoin de connaitre la notion de mémoire. Tu fais "new object" ou "object toto" et voilà. Si tu crées un nouvelle objet il faut bien allouer de la place dans la mémoire pour l'object qui par définition n'est pas connu par l'OS. Sinon tu demandes que l'OS connaisse a l'avance une liste d'objets prédéfinis et tu interdis la création de nouveau type d'objet. Très mauvaise idée.
> Un pas moins ambicieux (et non spécifiques aux objets) serait d'ajouter un module de "garbage collector" directement au noyaux. Ainsi le systeme est en charge des objets et chaque applis n'embarque plus son propre garbage collector (explicite ou automatique).
C'est ne pas connaitre l'architecture des OS que de dire ça ...
Linux a son "garbage collector" pour certaines resources (fichiers ouverts, modules, etc). En plus "garbage collector" est limite une connerie en vogue à cause de java. Tout ça car java a un thread séparé pour libérer la mémoire alors que les autres font ça sur le champs (si l'objet n'est plus utilisé, il est libéré tout de suite. Pas la peine d'attendre le "garbage collector").
Le "garbage collector" niveau appli est différent car l'OS pour des raisons de performance fourni des blocks de mémoire à l'appli (qui en fait ce quelle veut, par exemple pour l'utiliser pour 500 malloc de chaine de caractère). L'OS n'est pas au courrant des tous les malloc (fait par la librairie C). Sinon il faut un appel système par malloc et les performances chutes dramatiquement. Les appels systèmes coutent très cher en temps comparé à un simple malloc(10).
[^] # Re: Je me pose une question
Posté par Ayrton . En réponse au journal j'ai un rêve .... Évalué à -1.
> Pointer to virtual member function handling polymorphism (too complex or slow)
L'auteur n'a pas voulu couvrir ça. Ça le regarde et ça ne montre en rien qu'il n'a rien compris aux principes objet.
> Et au contraire, les principes objet demandent une aide _enorme_ du langage.
Pour que le language soit objet, oui. Tu défonce une porte ouverte...
> Ce que l'on appelle de la programmation objet en C n'est autre que de la programation modulaire (ou legerement plus).
Il y a programmation modulaire et objet. C'est deux choses différentes. Gobjet de glib te permet de faire de l'objet en C :
http://le-hacker.org/papers/gobject/index.html(...)
T'aimes ou t'aimes pas, mais ça existe, ça marche et c'est utilisé.
gobject montre que le C ne fait pas naturellement de l'objet.
> Un langage objet n'est pas la même chose que le langage C.
Personne n'a dit que le C était un langage objet. On dit que le C permet de faire de l'objet. Si l'objectif est de faire que de l'objet, le C est un très mauvais langage. Tout le monde est d'accord avec ça. Mais tous les développeurs C te diront qu'ils font parfois de l'objet même si ce n'est pas aussi "riche" et/ou confortable que d'utiliser directement le C++.
> Or maintenant on à réalisé des compilos qui concurence grandement le C (Eiffel, OCaml entres autres). Donc révisez votre jugement sur "l'objet c'est lent".
Trouves un benchmark qui montre ça. L'objet, si tu n'en a pas besoin (et souvent la programmation objet n'est pas nécessaire) est _forcément_ plus lent (il y a des indirections supplémentaires).
Si tu as besoin de programmer en objet, que le programme soit en C ou en C++, ça ira grosso-modo aussi vite.
> Pour revenir sur l'idée d'un OS tout objet: oui ce serrait biens car par exemple cela permettrait de cacher la notion de mémoire à un soft et ca se serait une enorme avancée!
Programmes en C++ ou python ou n'importe quoi qui t'évite d'utiliser malloc.
C'est n'importe quoi ton idée. Si l'objet est encapsulé/connu, tu n'as pas besoin de connaitre la notion de mémoire. Tu fais "new object" ou "object toto" et voilà. Si tu crées un nouvelle objet il faut bien allouer de la place dans la mémoire pour l'object qui par définition n'est pas connu par l'OS. Sinon tu demandes que l'OS connaisse a l'avance une liste d'objets prédéfinis et tu interdis la création de nouveau type d'objet. Très mauvaise idée.
> Un pas moins ambicieux (et non spécifiques aux objets) serait d'ajouter un module de "garbage collector" directement au noyaux. Ainsi le systeme est en charge des objets et chaque applis n'embarque plus son propre garbage collector (explicite ou automatique).
C'est ne pas connaitre l'architecture des OS que de dire ça ...
Linux a son "garbage collector" pour certaines resources (fichiers ouverts, modules, etc). En plus "garbage collector" est limite une connerie en vogue à cause de java. Tout ça car java a un thread séparé pour libérer la mémoire alors que les autres font ça sur le champs (si l'objet n'est plus utilisé, il est libéré tout de suite. Pas la peine d'attendre le "garbage collector").
Le "garbage collector" niveau appli est différent car l'OS pour des raisons de performance fourni des blocks de mémoire à l'appli (qui en fait ce quelle veut, par exemple pour l'utiliser pour 500 malloc de chaine de caractère). L'OS n'est pas au courrant des tous les malloc (fait par la librairie C). Sinon il faut un appel système par malloc et les performances chutes dramatiquement. Les appels systèmes coutent très cher en temps comparé à un simple malloc(10).