GoldenCrystal :
C'est possible avec Visual Studio .NET Il suffit d'afficher l'onglet assembleur, et tu verras... (par contre mieux vaux ne pas le laisser ouvert si tu ne t'en sert pas parce que ça fait bugger les onglets au bout de qq débogages )

OK, j'avais pas vraiment cherché non plus ^^

Euh il faut qd même y penser sérieusement... Ca peut énormément augmenter la taille des progs, et c pas franchement trivial...
Est-ce que tu comptes faire du comptage de référence (mais alors il va y avoir plein de progs qui vont foirer : on a vite fait de faire des références mutuelles de classes, et puis en plus ça va être très inefficace niveau taille du code) ou un vrai GC (plus compliqué à implémenter, et nbrx compromis entre vitesse et fluidité)

Ben je pensais à du comptage de références, mais je regarderai comment marche un vrai GC pour voir si c'est envisageable[/cite]
Le comptage de références ne suffira pas... Dès que tu auras des interactions entre classes (événements, etc...) tu auras des références mutuelles.

Après tout, ce n'est pas forcément une si mauvaise idée... Avec un bon bytecode (mais dépendant de plateforme), ça devrait pouvoir se faire.

Hmm, le problème est la taille de toutes les métadonnées (parce que bytecode sans métadonnées ça n'a pas d'intérêt) + la taille du bytecode qui est énorme. Autant sur PC la taille est minime par rapport à un exécutable standard, autant sur TI la différence de taille se sentirait, mais en sens inverse.[/cite]
Bah oui, mais ça peut être utile (voire indispensable) d'avoir ces métadonnées...

Pour la réflexion, j'y ai pensé il y a quelque temps, mais je pense que c'est possible de s'en passer (A la limite pour les typeof, j'utiliserai une structure qui donnera l'id de type (tant qu'a faire, celui attribué pdt la compilation), et les types hérités, ça ne devrait pas prendre trop de place

C pourtant assez important comme feature... Et les attributs?

Les attributs, faut voir, ça c'est jouable, mais bon, ça fait qd même des métadonnées à stocker

Oui, évidemment Mais si on s'en sert avec modération, c plus efficace de mettre un attribut que de rajouter du code...

3. Pourquoi VB ? C#, ça powa carrément plus...

Mais je ne sais pas programmer en C#, et le langage est beaucoup plus complexe que le VB (quoique parfois...)

Plus complexe que VB ? Je pense pas, surtout si tu as fait du C++.

C'est certain que je pourrais apprendre vite, vu les similitudes C#-C++, mais je ne me suis jamais penché là dessus, puisque le VB est relativement satisfaisant.

La syntaxe est horrible

Mais après on peut imaginer que la conversion bytecode -> ASM soit suffisamment simple pour faire un JIT...

Le problème c'est la limitation de mémoire surtout.

Il n'y a pas besoin de bcp de RAM pour faire ça, si la majorité des optimisations a déjà été faite sur le bytecode ^^