> Tu réponds pas à tout le reste :
> introspection
RTTI. certes incomplet, lourdingue, pièce rajoutée, etc etc
> gestion des exceptions (le C++ doit intégrer un morceau de runtime pour ca)
euh, et ? c'est surtout que contrairement à Java (au pif) les exceptions ne remplacent pas une gestion d'erreurs rigoureuse et qu'elles ne devraient jamais arriver, et que quand une arrive, en général ton programme ne peut plus faire grand chose d'utile
une exception dans le constructeur du 5ème Toto d'un tableau de 10, on fait quoi ? on ne sait pas forcément dans quel état il est, les autres non plus, souvent on ne sait meme pas lequel a planté. la vie est belle...
> sandboxing
yapa
> protection contre les débordements (on parle de garantie, une lib n'offre pas de garantie)
a[i] rapide au lieu de sûr
> gestion mémoire (on parle de garantie, pas de l'utilisation parfaite et sans erreur d'une lib)
idem
donc bref, pas fait pour, héritage du passé ou choix de conception, ca se recouvre un peu.
tout ça c'est se plaindre qu'un marteau ca fait mal quand on se tape sur les doigts avec. c'est... fait pour.
ah, et qu'on ne me parle pas de garantie quand les VM plantent sans raison ni explication. c'est comme un cheque de banque garanti alors que la banque n'est pas sûre, ou carrément est en faillite : cette garantie ne vaut rien.
> déployer une applet web (recompiler dans le navigateur n'est pas une option).
les applets font bien souvent du JiT et c'est plantogène, Adobe comme Sun passent leur temps à corriger des problèmes de sécurité sur leurs VM, on a gagné quoi exactement ?
> proposer pleins de langages interopérables
ça n'a pas grand sens de comparer un langage avec une VM pouvant faire tourner divers langages via son interpréteur de bytecode. parce que l'OS qui fait marcher le langage il peut faire marcher d'autres langages aussi, et il y a, de fait, diverses possibilités d'interopérabilités.
[^] # Re: Pourquoi Mono ?
Posté par Gniarf . En réponse au journal Utiliser Mono sans peur. Évalué à 3.
> introspection
RTTI. certes incomplet, lourdingue, pièce rajoutée, etc etc
> gestion des exceptions (le C++ doit intégrer un morceau de runtime pour ca)
euh, et ? c'est surtout que contrairement à Java (au pif) les exceptions ne remplacent pas une gestion d'erreurs rigoureuse et qu'elles ne devraient jamais arriver, et que quand une arrive, en général ton programme ne peut plus faire grand chose d'utile
une exception dans le constructeur du 5ème Toto d'un tableau de 10, on fait quoi ? on ne sait pas forcément dans quel état il est, les autres non plus, souvent on ne sait meme pas lequel a planté. la vie est belle...
> sandboxing
yapa
> protection contre les débordements (on parle de garantie, une lib n'offre pas de garantie)
a[i] rapide au lieu de sûr
> gestion mémoire (on parle de garantie, pas de l'utilisation parfaite et sans erreur d'une lib)
idem
donc bref, pas fait pour, héritage du passé ou choix de conception, ca se recouvre un peu.
tout ça c'est se plaindre qu'un marteau ca fait mal quand on se tape sur les doigts avec. c'est... fait pour.
ah, et qu'on ne me parle pas de garantie quand les VM plantent sans raison ni explication. c'est comme un cheque de banque garanti alors que la banque n'est pas sûre, ou carrément est en faillite : cette garantie ne vaut rien.
> déployer une applet web (recompiler dans le navigateur n'est pas une option).
les applets font bien souvent du JiT et c'est plantogène, Adobe comme Sun passent leur temps à corriger des problèmes de sécurité sur leurs VM, on a gagné quoi exactement ?
> proposer pleins de langages interopérables
ça n'a pas grand sens de comparer un langage avec une VM pouvant faire tourner divers langages via son interpréteur de bytecode. parce que l'OS qui fait marcher le langage il peut faire marcher d'autres langages aussi, et il y a, de fait, diverses possibilités d'interopérabilités.