c´t => Microsoft-Internet .net
yankeecs 19.02.2002 - 23:01 1892 18
Guest
Deleted User
|
vor allem wird mir nicht wohl bei dem gedanken, dass der anbieter meiner pr0n-site theoretisch Zugriff auf mein Bankkonto (das natürlich auch passport verwendet ....) hat. das funktioniert in 98% aller fälle bereits jetzt; pr0n-provider, die ein passwort im plain-text speichern, sollte man allgemein eher meiden... (hab ich gehört ) was mich an den .NET programmiersprachen am meisten reizt, ist die möglichkeit, software in "intermediate language" auszuliefern und erst am zielrechner auf das system optimiert zu kompilieren -> w00t. dabei muss man zwar bei einem prozessor/mainboard-wechsel die software neu installieren/kompilieren, aber da kommt man heutzutage auch nicht drum herum.
|
that
Hoffnungsloser Optimist
|
|
that
Hoffnungsloser Optimist
|
was mich an den .NET programmiersprachen am meisten reizt, ist die möglichkeit, software in "intermediate language" auszuliefern und erst am zielrechner auf das system optimiert zu kompilieren -> w00t. dabei muss man zwar bei einem prozessor/mainboard-wechsel die software neu installieren/kompilieren, aber da kommt man heutzutage auch nicht drum herum. Seit wann muss man beim Mainboardwechsel neu installieren? - das Generieren des optimierten Maschinencodes wird ja just-in-time gemacht. Und wenns wirklich bei einem einzelnen Programm auf die Startup-Performance ankommt (und man deshalb bereits vor der Ausführung native Code generiert), kann man ja den IL-Code aufheben.
|
Guest
Deleted User
|
das Generieren des optimierten Maschinencodes wird ja just-in-time gemacht. hä? also da hab ich was anderes gehört... installation = kompilierung; dann hab ich mein fertiges programm (vgl. linux kernel, c#-web-services usw) edit: so isses bei c#-web.services The runtime framework then creates the final binary code that makes up the application and executes it. The compiled IL code is used for each request until the source code is changed, at which point the cached version is invalidated and discarded. isses bei "normalen" applications anders? *weitersuch* edit2: scheint, als hättest du recht. Now when this .exe is run (commandprompt><filename>[.exe]) the MSIL is now compiled into CPU-specific code by a Just-In-Time compiler (JITer). The runtime provides one or more JIT compilers for each computer architecture that runtime operates on. This feature allows developers to write a set of MSIL that can be JIT compiled and executed on computers with different architectures. The CLR doesn’t provide interpreter to interpret the MSIL Code. Instead the MSIL Code will always run native by compiling the whole MSIL at one shot to the machine code of the underlying computer architecture. The JVM on the other hand can interpret the bytecode using a Java interpreter or can be compiled entirely to native code using a JITer. edit3: freude, wir haben beide recht - man kanns machen, wie man will: Java byte code and MSIL are both intermediate assembly-like languages that are compiled to machine code for execution, at runtime or otherwise. wow, ich führ lange selbstgespräche...
|