Ouais, le #, c'est comme le java, pour ceux qui le savent pas, ca se décompile et ca te redonne exactement le même code source à la virgule prés.
Bref, ca fait chier si tu veux pas faire un prog open-source.  
Je cherche donc un moyen d'empécher cette décompilation, en c# comme en java.
Quelqu'un a-t-il déja regardé ?

A partir du moment ou t'as un byte code, c'est que c'est "interprété" par une machine virtuelle ou un interpréteur.  
Si l'interpréteur peut lire le code, alors un décompilateur le peut aussi.
 
Par contre il existe des "obfuscators" qui rendent ton code crade pour que la lecture apres decompilation soit malaisée.
 
Ca doit se trouver en libre sur http://freshmeat.net, du moins pour java. Sinon il reste google en cherchant obfuscator.

Merci pour le nom d'obfuscator, je cherchais un peu au hasard avant.
 
Comment expliques-tu cette abération : si je tape "return 3*4;" les compilateurs java et c# ne traduisent même pas 3*4 en 12 dans le byte-code. Je vois pas l'intéret, ca fait plus de boulot a l'éxécution.
Je pensais que c'étais un minimum compilé !!! je trouve ca aberrant...
 
Tiens autre question : y a til un moyen de faire un exe avec c# qui ne necessite plus l'utilisation des milliers de dll du framework, un peu comme en MFC quand on lie les librairies statiquement à la compilation ? *
En fait ca me fait chier de distribuer mon exe de 100ko avec le framework de 20Mo ...

si je tape "return 3*4;" les compilateurs java et c# ne traduisent même pas 3*4 en 12 dans le byte-code.
 
Je sais pas trop, surtout que ca m'étonne aussi sur le coup. Pour C# je sais pas, mais en java c'est etrange, car les int sont des types de base, et * n'est pas redéfinissable. Si tu pouvais redefinir l'operateur pour le type int ca se comprendrait, mais la... Quelqu'un de plus compétent est au courant ?
 
y a til un moyen de faire un exe avec c# qui ne necessite plus l'utilisation des milliers de dll du framework
 
Désolé, je ne connais ni C# ni les MFC. en fait windows je suis un peu paumé.

 
il ya rien d'abérrant là dedans, compiler ce n'est pas calculer le résultat des expressions (ça, c'est fait à l'exécution), avant la compilation effective, certaines transfos sont normallement faites (remplacement des contantes par leurs valeurs par exemple), mais pour le calcul d'expressions (même entièrement numériques) ce n'est pas le boulot d'un compilo

d'accord, mais 3*4 écrit comme ca c'est con de pas le calculer directement et mettre 12 dans le byte-code, non ?

 
Oui surtout que n'importe quel compilo C/C++ le fait.

Au fait, vous en avez trouvé un bien de decompilateur C#? paske l'a j'ai du mal a en trouver.
 
Merci d'avance
a+

 
<aucune idee>
bah ptet qu'y a des options d'optim a activer

 
Perso, je me suis renseigné à l'époque de la sortie de C# et il n'y a pas moyen. C'est une des raison qui fait que C# aura un interet un jour quand ce framework sera intégré à l'OS chez tout le monde (dans 5 ans ?)

Euh si, justement! Le constant folding bien fait doit remplacer les expression constantes par la valeur constante correspondante appropriée.

 
 
A+,

Euh les gars, vous en avez pas un alors de decompilateur?

C'est pas le boulot des compilos byte code, mais celui des compilos natifs.
Concernant .net : le byte-code et compilé en natif et stocké sous cette forme avant la première exécution, c'est à ce moment là que ce genre d'optim peut être faite.
Concernant java : c'est les compilos just-in-time qui vont faire ce boulot s'il est nécessaire (puisqu'il se pourrait que l'expression entière passe à la poubelle).
 
D'une manière générale, cette optimisation n'est pas super-utile, du calcul pur d'expression comme ça n'est pas ce qu'il y a de plus coûteux. D'autre part, l'élimination des sous-expressions communes va prendre en charge la factorisation à court terme (car le calcul est probablement moins coûteux que de squatter un registre 3 heures) du résultat s'il est utilisé plusieurs fois.

c'est absolument pas le boulto d'un compilateur de faire ça

Oui et non: ce type d'optimisation (constant folding) peut etre fait a l'un ou l'autre stade. La seule raison qui me semble justifier de n'effectuer les optimisations que dans une phase just-in-time, c'est que, comme de toute facon, le compilo just-in-time va les effectuer de maniere plus pointues et ciblées pour la machine cible, il est donc inutile (et eventuellement, néfaste pour la qualité de l'optimisation effectuée par le compilo just-in-time), de faire une optimisation prealable, lors de la generation du byte code.
A+,

http://www.go-mono.com/c-sharp.html