C# nativ kompilieren?

theta schrieb:

@Sharph: Hey, nicht gleich sauer werden.

Ich bin nur sauer geworden, weil ich diese Antwort schon x-mal lesen musste. Wann immer jemand das irgendwo fragt, kommt diese Antwort, die nunmal eindeutig falsch ist.

theta schrieb:

Ich weiss, es gibt Umwege und Hacks, aber dabei verliert man viele Vorteile und ist schlicht am Konzept vorbei.

Konzept hin oder her. Es ist ja nicht das .NET-Framework-Konzept, das mir so gefällt, sondern schlicht die C#-Sytax auf Codeebene. Und ich finds irgendwie blöd: Will man native Programme, muss man sich mit Frickel-C++ rumärgern. Will man die gute Sprache, kann man keine nativen Anwendungen schreiben. Warum wird das nicht voneinander getrennt? Programmiersprache und Form der Anwendung? Warum ist C++ immer nativ und C# und Java immer Bytecode? An sich gibt es in der Sprachbeschreibung selbst ja nichts, was für die eine oder andere Art der ausführbaren Datei prädestiniert ist. Das heißt: Man könnte einen nativen C#-Compiler programmieren und einen ISO-C++-Compiler, der Bytecode erzeugt und mit einer Virtual Machine funktioniert. Warum wird Programmiersprache und Art der ausführbaren Datei immer gekoppelt? Ich will gar kein Bytecode-Konzept, sondern eine simple Win32-Anwendung. Aber: Ich will mich nicht mit dieser altmodischen Sprache und den halbgaren Privatframeworks rumärgern, sondern eine Programmiersprache mit sauberer Syntax und mit gut durchdachten Standardfunktionen benutzen. Das .NET-Konzept interessiert mich nicht so, aber die Sprache C# und die Funktionen des .NET-Frameworks (aus Code-Sicht) finde ich genial.

Th69

Dann schreib dir doch deine eigene Sprache, welche alle Vorteile vereint -)

Der Vorteil bei Bytecode ist nun mal die bessere Portierbarkeit (anstatt auf jeder Plattform noch mal neu kompilieren und linken zu müssen). Die Optimierungen können dann bei Start bzw. On-the-fly vorgenommen werden (sog. JIT-Compiler, d.h. Just-In-Time).

Und bei den heutigen Rechnerleistungen langweilen sich die Prozessoren doch meistens eh'.

Aber evtl. könntest du dir ja mal .NETZ http://madebits.com/netz/index.php anschauen...

Th69 schrieb:

Dann schreib dir doch deine eigene Sprache, welche alle Vorteile vereint -)

Na klar. Ich hab ja auch sonst nichts zu tun. Und danach erstell ich mir mein eigenes Betriebssystem, das besser ist als eine ideale Kombination aus Windows und Linux.

Th69 schrieb:

Der Vorteil bei Bytecode ist nun mal die bessere Portierbarkeit

Klar, aber bei C++ beschwert sich ja auch keiner, dass es keinen Bytecode erstellt. Somit sind native Anwendungen an sich erstmal nicht "unbeliebt". Ich möchte meine nativen Anwendungen aber gern in einer sauberen Sprache schreiben. Und C# ist ich, was Programmiersprachen angeht, mein absoluter Favorit. Aber dafür gibt's eben leider keine Implemntierung für reine Windows-Anwendungen.

Th69 schrieb:

Aber evtl. könntest du dir ja mal .NETZ http://madebits.com/netz/index.php anschauen...

Das ist aber nur ein Komprimierungstool für die mit .NET erstellten Exen und Dlls. Auch das hat nichts damit zu tun, die Programme irgendwie unabhängig vom Framework laufen zu lassen. (Soweit ich das sehe.)

Dann musst du wohl oder übel D nehmen.

Herb

Schau dir mal http://www.remotesoft.com/linker/ an. Kostet halt leider ein paar Euro...

hustbaer

@Sharph:
Deine Frustration entspringt nur aus dem Umstand, dass du die Realität verweigerst.
Es gibt halt keinen praktikablen Weg C# Programme "nativ" zu compilieren.
Thema erledingt.

Nächste Frage?

audacia

Sharph schrieb:

Und ich finds irgendwie blöd: Will man native Programme, muss man sich mit Frickel-C++ rumärgern. Will man die gute Sprache, kann man keine nativen Anwendungen schreiben.

=> Delphi.

Sharph schrieb:

An sich gibt es in der Sprachbeschreibung selbst ja nichts, was für die eine oder andere Art der ausführbaren Datei prädestiniert ist.

Doch; Java und C# erwarten einen GC, und für einen solchen sind Managed Environments per se besser geeignet. C++ hat außerdem jede Menge Features, die in einer sicheren Umgebung nicht umsetzbar sind. In C++/CLI und C# wird das durch die Abgrenzung von "unsafe code" umgangen.

knivil

Will man native Programme, muss man sich mit Frickel-C++ rumärgern.

Nein, es gibt viele Alternativen.

Doch; Java und C# erwarten einen GC, und für einen solchen sind Managed Environments per se besser geeignet.

Es gibt auch native Compiler fuer Lisp und Scheme oder die nach C uebersetzen. Diese erwarten auch einen GC. Python soll auch eine recht kleine runtime haben und direkt in die executable mit einbinden.

Knuddlbaer

Sharph schrieb:

Rhombicosidodecahedron schrieb:

Sharph schrieb:

Ich will C#-Code nativ kompilieren.

nGen.exe

Oh, ich hasse das! Wann immer nach einer Möglichkeit gefragt wird, wie man .NET-Anwendungen ohne Framework benutzen kann, kommt irgendein Depp mit ngen.

Vor dem Flamen bitte lesen. Die Antwort nGen.exe wurde auf das native Kompilieren gegeben. Der Part "ohne Framework" wurde separat beantwortet. Es wird in der Antwort in keinster Weise behauptet, dass man mit nGen eine Anwendung ohne installiertem Framework laufen lassen kann.

audacia

knivil schrieb:

Doch; Java und C# erwarten einen GC, und für einen solchen sind Managed Environments per se besser geeignet.

Es gibt auch native Compiler fuer Lisp und Scheme oder die nach C uebersetzen. Diese erwarten auch einen GC.

Es gibt auch GCs für C++, und ich sagte nicht "vorausgesetzt", sondern "per se besser geeignet".

digitalmars schrieb:

Dann musst du wohl oder übel D nehmen.

D? Das benutzt doch keiner.

Herb schrieb:

Schau dir mal http://www.remotesoft.com/linker/ an. Kostet halt leider ein paar Euro...

Und wenn ich mir das Ding gekauft habe und es funktioniert, lad ich euch alle zur Feier des Tages zu einem Kurzurlaub nach Florida ein.

hustbaer schrieb:

@Sharph:
Deine Frustration entspringt nur aus dem Umstand, dass du die Realität verweigerst.
Es gibt halt keinen praktikablen Weg C# Programme "nativ" zu compilieren.
Thema erledingt.

Nächste Frage?

Wenn das so gesagt worden wäre, dann wär das ja in Ordnung gewesen. Ich hab mich nur über die Erwähnung von ngen aufgeregt, weil das immer als die Lösung präsentiert wird.

audacia schrieb:

=> Delphi.

Klassenatribute per default public? Ich bitte dich.

knivil schrieb:

Nein, es gibt viele Alternativen.

Sag mal noch'n paar (echte) Alternativen zu C++, die qualitativ an C# heranreichen. Aber bitte nicht so'n Zeug wie Python: "Eine Variable muss nicht deklariert werden, sondern wird einfach benutzt." Kotz würg!

Knuddlbaer schrieb:

Vor dem Flamen bitte lesen. Die Antwort nGen.exe wurde auf das native Kompilieren gegeben. Der Part "ohne Framework" wurde separat beantwortet. Es wird in der Antwort in keinster Weise behauptet, dass man mit nGen eine Anwendung ohne installiertem Framework laufen lassen kann.

Also ungefähr so, als würde jemand fragen:
"Wie komme ich am schnellsten von Berlin nach Moskau. Aber ohne Flugzeug, da wird mir immer schlecht."
Und ich antworte dann in folgender Weise:

Wie komme ich am schnellsten von Berlin nach Moskau.

Mit dem Flugzeug.

Und wenn er sich dann aufregt, dass er schon gesagt hat, dass Flugzeuge ausgeschlossen sind, antworte ich: "Vor dem Flamen bitte lesen. Die Antwort mit dem Flugzeug wurde auf die generelle Frage gegeben, wie man am schnellsten nach Moskau kommt. Ich hab in keiner Weise behauptet, dass das auch auf dich zutrifft."

knivil

Du bist viel zu emotional und verschliesst dir selbst die Tuer zu grossartigen Ideen.Das Konzept von dynamisch typisierten Sprachen ist halt so. Werte haben einen Typ, Variablen nicht.

knivil schrieb:

Du bist viel emotional und verschliesst dich selbst grossartigen Ideen.Das Konzept von dynamisch typisierten Sprachen ist halt so. Werte haben einen Typ, Variablen nicht.

Nenn mir bitte einen Vorteil dieser Praxis. Ich nenn dir mal einen Nachteil:

int meineTolleZahl = 5;

meinetolleZahl = 8; // Kompilerfehler: Variable unbekannt
                    // (weil ich mich verschrieben habe)

meineTolleZahl = 5;

meinetolleZahl = 8; // Viel Spaß beim Fehlersuchen,
                    // wenn das Programm etwas größer ist

knivil

Scripte, deswegen auch Scriptsprache ... dynamische Inhalte, anpassbare Anwendungen ... genutzet von vielen Spielen. Auch fuehrt das Lesen einer noch nicht vorhandenen Variable zum Fehler. Und da Variablen nunmal benutzt werden um Inhalte zu speichern, damit man sie spaeter wieder lesen kann, ist dein Beispiel nicht ganz so schlimm. Er faellt auf. Groesse ist nur ein Problem bei Spagetthie-Code. Auch wird von manchen case sensitivity als eher unguenstig angesehen. (Quelle finde ich grad net wieder)

knivil schrieb:

Scriptsprachen ...

hustbaer

Sag mal noch'n paar (echte) Alternativen zu C++, die qualitativ an C# heranreichen

Es gibt einige Alternativen die qualitativ mit C# vergleichbar sind, bloss sind die z.T. ganz anders zu programmieren.
Nur ein paar Beispiele: diverse LISP Dialekte und Abarten, ADA, Eiffel.

Eiffel ist sogar recht ähnlich (sprich: imperativ), bloss verwendet es eine "Pascal-artige" Syntax (Wörter statt Sonderzeichen), was viele abschreckt. Der grösste Nachteil ist wohl die geringe Verbreitung, und alles was sich daraus ergibt: die sehr lückenhafte Standard-Library, die z.T. nicht ganz ausgereiften Tools, kleinere Community etc.

Dafür kann es "nativ" compiliert werden, und kommt ohne riesen Framework aus.

EDIT: ADA ist natürlich auch imperativ /EDIT

audacia

Sharph schrieb:

audacia schrieb:

=> Delphi.

Klassenatribute per default public? Ich bitte dich.

Netter Versuch

audacia schrieb:

Sharph schrieb:

audacia schrieb:

=> Delphi.

Klassenatribute per default public? Ich bitte dich.

Netter Versuch

Was soll das heißen? Ist es nicht so, dass bei Delphi die Attribute public sind, wenn man nichts anderes angibt?

knivil

Omg, super Auswahlkriterium fuer die Beurteilung einer Programmiersprache ... Sorry, aber ich glaube du laesst nichts zu, was nicht C# von der Syntax ist ...

knivil schrieb:

Omg, super Auswahlkriterium fuer die Beurteilung einer Programmiersprache

Na klar. Stell dir mal vor, bei deiner Hose wäre der Reißverschluß per default nicht da.

knivil schrieb:

... Sorry, aber ich glaube du laesst nichts zu, was nicht C# von der Syntax ist ...

Du hast es erfasst.

Evaluation EvaluateLanguage(Language language)
{
    return LanguageIsCSharp(language)
        ? Evaluation.Good
        : Evaluation.Shit;
}