Nicolas Boulay a écrit 16010 commentaires

Tu veux que je te trouve un compilo C# autre que celui de MS ? C'est une blague ?

Je t'ai trouvé des exemples de langages ayant les 2 technologies. En OCaml, je crois que la version native est plus rapide que la VM.

"La première sécurité est la liberté"

Gni ? Tu confonds pas tout là ? on parle de quoi ? Du langage ? Du compilateur ? Du runtime ou des bibliothèques ?

Je parle des framework MS et ceux de Novell.

Encore un truc que je supporte pas dans ce langage, l'absence de spécification pour l'ABI du code produit.

Il faut voir la taille du bousin.

"La première sécurité est la liberté"

ocaml ? lisp ? Java avec gcj ? Mais je ne connais pas assez.

En général, on développe un langage pour un usage avec un runtime. Faire 2 runtime est difficile et surtout a un intérêt pratique faible.

"La première sécurité est la liberté"

Ou que le compilateur natif est mauvais.

"La première sécurité est la liberté"

Des fois je préfères moins d'optimisation :)

tu imagines ne pas inliner l'équivalent de tab[i] ?

Mais bon c'est tout le concept des templates que je trouve foireux.

Moi aussi. Mais c'est en même temps la force de C++ qui lui permet d'être encore très utilisé maintenant.


Le problème, c'est quand les étapes de compilation ne se font pas en même temps par le même compilateur, c'est là que c'est le bordel : tu diffuse une lib, tu regénères qu'une partie, t'utilises un compilateur ou une plateforme différente, etc. Les risques de désynchro ou d'incompatibilité entre les modules est trop forte.

Cela a toujours été vrai. Ce qui tourne sous .NET à peu de chance de tourner correctement sous Mono (sauf à y faire des tests spécifiques).
En plus, l'ABI C++ de gcc 3.* changeait beaucoup.

"La première sécurité est la liberté"

Ils interdisent la présence de proxy, et surtout il interdisent les scan qui partent de leur réseau (si ils ne le font pas il risque de se faire couper l'accès par les réseaux scanné).

"La première sécurité est la liberté"

on pourrait imaginer que c'est la classe qui fait concrètement la réservation mémoire

Et comment tu fais les allocations dans la pile pour les objets automatique ?

Enfin déjà interdire la présence du moindre code pour éviter qu'il soit compilé différemment dans la lib et par celui qui l'utilise ca serait bien.

Dans ce cas tu te prives de beaucoup de possibilités d'optimisation, typiquement les accesseurs devraient être dans le .h pour être inline.

Ca suppose que le code des templates notamment puisse être mis ailleurs (me semble que ca va être le cas dans la prochaine version).

Il doivent être compiler, donc cela parait difficile.


Enfin bref, c'est trop tard, je dis juste que ca a été très mal conçu ce système de .h et que c'est une vraie plaie à l'utilisation : y'a intérêt d'avoir des conventions et d'être très rigoureux. Et surtout que tout le monde fasse comme toi dans le même projet sinon c'est la merde.

Chaque élément de compile doit avoir toutes les infos. Et les infos partagées sont dans le .h. La seul étape qui reste est le link (long car il concerne l'ensemble du projet).

"La première sécurité est la liberté"

Évidement que cela un intérêt.

Si C# peut utiliser les 2 modes tant mieux. Mais cela ne rend pas le concept de VM comme flou.

"La première sécurité est la liberté"

A ma connaissance, il y a peu de GC qui soit parfait.

Il y a le reference counting qui a un gros cout d'execution à faire tourner des counter partout auquelle il faut rajouter ensuite un parcours pour attraper les cycles (et en cas de graphe ?).

Il y a les systèmes de recopie par suivi des pointeurs, il y a la recopie en estimant que toute données est un pointeur.

Les techniques de GC ne sont pas parfaite non plus. Ce n'est pas encore un moyen d'avoir un binaire qui tourne 10 ans sans problème.

"La première sécurité est la liberté"

Mais non la limite n'est pas flou du tout.

Elle est même évidente quand tu regarde l'exécution d'un programme sous VM et un binaire natif.

Dans le cas du binaire, tu as le loader qui map le fichier en mémoire, puis la libc va chercher les libs dynamique qui vont bien, puis le program counter est mis sur le _main().

Dans le cas d'une VM, (comme pour les shell), un programme est démarrer, la VM, qui ensuite lit le code sous forme de bytecode qui est une donné pour lui, et ensuite il le transforme pour soit l'interpréter, soit le compiler (JIT).

La différence est flagrante !

"La première sécurité est la liberté"

Si tu n'as pas de données privées dans les déclarations de class comment le compilo peut connaitre la taille de l'objet ?

"La première sécurité est la liberté"

L'effort n'est pas délirant par rapport à trouver le problème à la main. (genre le code plante parce qu'une fonction à coté fait un débordement de buffer sur une variable global...)

"La première sécurité est la liberté"

tu exagères un poil. Ils ont plein de serveur pour faire du partagé. De plus, ils monitorent aussi leur réseau pour couper les serveurs compromis.

"La première sécurité est la liberté"

Tu aurais été embêté pour faire de la compilation séparée sans les .h.

"La première sécurité est la liberté"

Oui et non.

C'est censé être standard, mais c'est hyper complexe. De plus, l'information existe et peut donc être utilisé.

"La première sécurité est la liberté"

Bah oui.

La technologie pour faire exécuter un code, n'est pas lié au langage lui-même mais aux choix fait pour l'exécuter. Cf par exemple l'utilisation de tcc pour transformer du C en script shell en utilisant une sorte de JIT.

C'est plus ou moins simple selon les cas. ocaml par exemple peut être compiler ou interprété.

"La première sécurité est la liberté"

Ok, donc toi ta définition de VM, c'est VM = JIT.

non, les premières VM n'étaient pas JIT. JIT implique une compilation en code natif à la volé, cela ne couvre pas les interprétations directs du bytecode.

"La première sécurité est la liberté"

En C++, tu as le mangling des méthodes qui permet de retrouver aussi les types des paramètres et les interfaces.

"La première sécurité est la liberté"

Puisque je me tue à expliquer qu'on peut compiler du code C# en x86, c'est bien que la différence est ailleur.

Si tu compiles en natif, il n'y a plus de VM. Un langage de haut niveau n'a pas forcément besoin d'une VM, c'est ça que tu ne veux pas comprendre.

dans machine virtuelle, il y a virtuel. Que concrêtement le support de déploiement soit du bytecode, même si ca suppose un certain niveau d'abstraction, c'est un autre problème.

Ben non. VM !=abstraction.

"La première sécurité est la liberté"

Si, le jeu d'instruction. Soit c'est un bytecode, soit c'est du x86/x86-64/ppc/arm/mips...

"La première sécurité est la liberté"

L'incompétence n'est pas une excuse.

tu peux trouver aussi des subtilités dans C#, je suis quasiement sûr que gérer proprement les exceptions ne doit pas être simple.

"La première sécurité est la liberté"

En gros, il sous-entende qu'il pourrait attaquer avec les autres brevets de l'api, la belle affaire.

"La première sécurité est la liberté"

donc en C à cause des fonction comme longjump, setjump, c'est aussi une VM ?

"La première sécurité est la liberté"

C'est une construction du langage comme if, while ou goto qui générer ensuite des instructions machines.

"La première sécurité est la liberté"

C'est pas parcque tu produis du code natif que tu n'as pas de vu abstraite de la machine du point de vue du programmeur.

Abstraire la machine est le role des OS et des langages par rapport à m'asm pur et dur. Linux tourne bien sur plein d'archi différentes mais les logiciels C tournent tous dessus.

une VM ce n'est pas que ça. C'est aussi un jeu d'instruction particuliers.

"La première sécurité est la liberté"