Ce dont 99% du code ecris se moque royalement.
Y'a pas que pour le programmeur qu'il y a un intérêt, mais aussi pour l'utilisateur : la couche d'abstraction vis à vis de matos est le meilleur moyen d'avoir une compatibilité binaire. On le voit facilement par exemple avec le passage au 64bits : le matos et l'OS est obligé de se coltiner un mode "legacy" 32 bits juste pour faire marcher de vieilles applis. Les appli .NET/Java tournent out of the box sur une machine 64 bits.
De toute facon c'est au systeme d'exploitation de fournir le confinement/sandboxing; le faire dans le langage c'est un palliatif, pas une solution.
Et ben c'est pareil que pour le problème de matos : les instructions machines du proc sont limitées et le code associé y est fortement lié : le modèle de sécu de .NET par exemple est bien plus avancé en terme de gestion de droits que ce que propose l'OS. Les 2 sont complémentaires, l'OS gère tout ce qui concerne les droits au niveau processus, le framework .NET travaille plutôt au niveau des assemblies.
Et puis y'a des choses que l'OS ne peut pas faire : un débordement de tampon qui se fini par une appli avec du code injecté, ben l'OS aura beau limiter ses droits, si l'appli avait ne serais-ce que les droits utilisateurs, paf, accès à des données sensibles, toussa. Et ca l'OS ne peut pas le faire car un débordement de tampon, ce n'est que finalement une fonctionnalité offerte par le langage C qui t'autorise à taper n'importe où dans l'espace mémoire du processus.
De plus la granularité est beaucoup plus fine : je peux faire du sandboxing interne : pleins d'applis sont développées avec un mécanisme de plugin, tu trouverais ca normal qu'un plugin "tiers" fasse planter une appli critique ? Non, ben tu l'isoles, dans le doute, c'est pas ton code, il peut être une sour ce de bug supplémentaire, je sandbox, et l'OS ne peut rien y faire.
il te suffit de coller un tag dans toutes tes structures; tu peux meme faire ca en C si tu veux.
Sauf que là c'est proposé out of the box, ca marche avec tous les types, c'est un modèle complètement objet this.GetType().GetBaseClass().FindMethod("trucmuch"), tu vas t'arracher en C.
Aller petit exercice : je te files une classe C++, et tu me génères dynamiquement un proxy sur une instance de cet objet, et bien sûr tu rajoutes au milieu une connection TCP.
Donc la machine virtuelle ne sert toujours a rien
T'as pas bien compris ce qu'est une machine virtuelle. La machine est "virtuelle". Dans le cas de .NET/Java, une partie de la vue virtuelle c'est la représentation de ces données, et en l'occurence des objets.
Poussons le raisonnement que tu proposes, à savoir :
1 - je rajoutes systématiquement une info de type à la structure pour pouvoir l'identifier.
2 - je veux maintenant que ca soit fait automatiquement sur mes objets, je fais donc en sorte que ca soit fait par le compilo et qu'un support à l'exécution soit présent : c'est le runtime RTTI que propose C++. Déjà, le langage C++ propose dans ce contexte un semblant de vue qui n'est pas uniquement des "bits" en mémoire comme en C, on a un début de machine virtuelle.
3 - je veux des infos sur tous les membres objet par introspection
4 - allez je veux même le code de tous les membres objet par introspection
5 - j'ajoutes donc un tas d'infos sur le code lui même : au final j'ai construit une couche d'abstration complète de mon code, j'ai créé un nouveau modèle de machine virtuelle.
Tiens d'ailleur au passage je me dis que le code natif ne sert plus à rien dans l'histoire, on peut le regénérer à partir du code virtuel puisqu'il contient toutes les infos. hop je le vire, il sera traduit en code natif au dernier moment : JIT.
Ah oui, et le C dans l'histoire, ne fera que rendre ta solution bancale, non standard : rien n'empêche un couillon (ou bêtement un bug si fréquent) d'aller écraser l'info de type dans ta structure. Pouf, tout ton code après s'écroule comme un con. D'où l'intérêt d'avoir un modèle beaucoup plus contrôlé.
Bon ca je sais pas ce que c'est. Enfin le nom me dit rien. Si c'est un truc
Des trucs du genre : j'instancie à distance un objet dans un autre processus sur une autre machine par exemple, et je la manipule comme si elle était en local (bref cas typique d'une application répartie avec des composants objets).
L'avantage de la machine virtuelle, c'est pour les applications embarquees,
quand le temps de compilation doit etre vraiment minimise, parce que c'est facile a traduire en code natif; sur un serveur/desktop/PC moderne ca ne sert a rien.
Alors pourquoi D ne propose pas les mêmes fonctionnalités en terme de sécu, d'introspection et tout le tralala ?
Pourquoi personne n'a encore fait de super langage sans machine virtuelle et qui concurrence Java & Co ?
Pourquoi on doit encore se taper ce con de C dans l'embarqué (malgré ce que tu dis, car souvent dans l'embarqué, les perfs sont primordiales)
Si on regarde un language comme Common Lisp, qui compile en code natif
Gni ? Et ? .NET compile en natif. Java compile en natif. Tu crois que Common Lisp ne propose pas par hasard un modèle de représentation des données virtuelles qui lui est propre ? Tu crois qu'il n'y a aucun service dynamique à l'exécution pour pallier les impossibilités d'introspection du langage natif ? Tu crois que common lisp te permet de faire de memcpy et autre bidouille en partant du principe que tu attaques physiquement une zone mémoire ou bien Common Lisp te propose une abstraction totale de la machine physique ? Tu crois que tout ca c'est pas caché dans ce qu'on appel généralement une machine virtuelle ?
[^] # Re: et le mien
Posté par TImaniac (site web personnel) . En réponse à la dépêche Le langage D 1.00 est disponible !. Évalué à 1.
Y'a pas que pour le programmeur qu'il y a un intérêt, mais aussi pour l'utilisateur : la couche d'abstraction vis à vis de matos est le meilleur moyen d'avoir une compatibilité binaire. On le voit facilement par exemple avec le passage au 64bits : le matos et l'OS est obligé de se coltiner un mode "legacy" 32 bits juste pour faire marcher de vieilles applis. Les appli .NET/Java tournent out of the box sur une machine 64 bits.
De toute facon c'est au systeme d'exploitation de fournir le confinement/sandboxing; le faire dans le langage c'est un palliatif, pas une solution.
Et ben c'est pareil que pour le problème de matos : les instructions machines du proc sont limitées et le code associé y est fortement lié : le modèle de sécu de .NET par exemple est bien plus avancé en terme de gestion de droits que ce que propose l'OS. Les 2 sont complémentaires, l'OS gère tout ce qui concerne les droits au niveau processus, le framework .NET travaille plutôt au niveau des assemblies.
Et puis y'a des choses que l'OS ne peut pas faire : un débordement de tampon qui se fini par une appli avec du code injecté, ben l'OS aura beau limiter ses droits, si l'appli avait ne serais-ce que les droits utilisateurs, paf, accès à des données sensibles, toussa. Et ca l'OS ne peut pas le faire car un débordement de tampon, ce n'est que finalement une fonctionnalité offerte par le langage C qui t'autorise à taper n'importe où dans l'espace mémoire du processus.
De plus la granularité est beaucoup plus fine : je peux faire du sandboxing interne : pleins d'applis sont développées avec un mécanisme de plugin, tu trouverais ca normal qu'un plugin "tiers" fasse planter une appli critique ? Non, ben tu l'isoles, dans le doute, c'est pas ton code, il peut être une sour ce de bug supplémentaire, je sandbox, et l'OS ne peut rien y faire.
il te suffit de coller un tag dans toutes tes structures; tu peux meme faire ca en C si tu veux.
Sauf que là c'est proposé out of the box, ca marche avec tous les types, c'est un modèle complètement objet this.GetType().GetBaseClass().FindMethod("trucmuch"), tu vas t'arracher en C.
Aller petit exercice : je te files une classe C++, et tu me génères dynamiquement un proxy sur une instance de cet objet, et bien sûr tu rajoutes au milieu une connection TCP.
Donc la machine virtuelle ne sert toujours a rien
T'as pas bien compris ce qu'est une machine virtuelle. La machine est "virtuelle". Dans le cas de .NET/Java, une partie de la vue virtuelle c'est la représentation de ces données, et en l'occurence des objets.
Poussons le raisonnement que tu proposes, à savoir :
1 - je rajoutes systématiquement une info de type à la structure pour pouvoir l'identifier.
2 - je veux maintenant que ca soit fait automatiquement sur mes objets, je fais donc en sorte que ca soit fait par le compilo et qu'un support à l'exécution soit présent : c'est le runtime RTTI que propose C++. Déjà, le langage C++ propose dans ce contexte un semblant de vue qui n'est pas uniquement des "bits" en mémoire comme en C, on a un début de machine virtuelle.
3 - je veux des infos sur tous les membres objet par introspection
4 - allez je veux même le code de tous les membres objet par introspection
5 - j'ajoutes donc un tas d'infos sur le code lui même : au final j'ai construit une couche d'abstration complète de mon code, j'ai créé un nouveau modèle de machine virtuelle.
Tiens d'ailleur au passage je me dis que le code natif ne sert plus à rien dans l'histoire, on peut le regénérer à partir du code virtuel puisqu'il contient toutes les infos. hop je le vire, il sera traduit en code natif au dernier moment : JIT.
Ah oui, et le C dans l'histoire, ne fera que rendre ta solution bancale, non standard : rien n'empêche un couillon (ou bêtement un bug si fréquent) d'aller écraser l'info de type dans ta structure. Pouf, tout ton code après s'écroule comme un con. D'où l'intérêt d'avoir un modèle beaucoup plus contrôlé.
Bon ca je sais pas ce que c'est. Enfin le nom me dit rien. Si c'est un truc
Des trucs du genre : j'instancie à distance un objet dans un autre processus sur une autre machine par exemple, et je la manipule comme si elle était en local (bref cas typique d'une application répartie avec des composants objets).
L'avantage de la machine virtuelle, c'est pour les applications embarquees,
quand le temps de compilation doit etre vraiment minimise, parce que c'est facile a traduire en code natif; sur un serveur/desktop/PC moderne ca ne sert a rien.
Alors pourquoi D ne propose pas les mêmes fonctionnalités en terme de sécu, d'introspection et tout le tralala ?
Pourquoi personne n'a encore fait de super langage sans machine virtuelle et qui concurrence Java & Co ?
Pourquoi on doit encore se taper ce con de C dans l'embarqué (malgré ce que tu dis, car souvent dans l'embarqué, les perfs sont primordiales)
Si on regarde un language comme Common Lisp, qui compile en code natif
Gni ? Et ? .NET compile en natif. Java compile en natif. Tu crois que Common Lisp ne propose pas par hasard un modèle de représentation des données virtuelles qui lui est propre ? Tu crois qu'il n'y a aucun service dynamique à l'exécution pour pallier les impossibilités d'introspection du langage natif ? Tu crois que common lisp te permet de faire de memcpy et autre bidouille en partant du principe que tu attaques physiquement une zone mémoire ou bien Common Lisp te propose une abstraction totale de la machine physique ? Tu crois que tout ca c'est pas caché dans ce qu'on appel généralement une machine virtuelle ?