grundlegende frage zu mono/c#

marmeladebomber · Beitrag von **marmeladebomber** » 04.06.2004 19:36:38

ist c# eine sprache die
a) kompiliert in 1/0 wird
b) ähnlich wie java in bytocde kompiliert wird
c) in 1/0 kompiliert wird aber mono/.net braucht um zu laufen

ich tappe da zurzeit ein wenig im dunklen. oft wird "konkurrenz" zu java gesprochen, dann sehe ich wieder etwas anderes, ich kenne mich nicht mehr aus?

Joghurt · Beitrag von **Joghurt** » 04.06.2004 19:39:25

b)

Allerdings werden (IIRC) in .NET alle Programme in den CLI-Bytecode compiliert, also auch C, VisualBasic etc.

http://de.wikipedia.org/wiki/.NET

marmeladebomber · Beitrag von **marmeladebomber** » 04.06.2004 20:10:55

danke für die aufklärung

aber dotgnu.org möchte ja einen "echten" compiler schreiben, oder ist das nur die implementation des compilers?

EDIT: der gnudot compiler ist in C geschrieben, der mono in c#
Problem dabei ist das henne/ei prinzip. der mono muss irgendwann unter MS.net compiliert werden. da könnte MS theoretisch einen riegel vorschieben.

suntsu · Beitrag von **suntsu** » 04.06.2004 20:17:37

die Antwort ist wie schon geschrieben b.
Es würde auch dem konzept wiedersprechen native programme zu machen.
Allerdings ist es nicht auszuschliesen das es etwas wie den gcj für java.

gruss
manuel

edit:
Der mono compiler musste einmal mit dem ms compiler gebaut werden. Jetzt wird er mit mono gebaut.
http://www.go-mono.com

Beitrag von **BeS** » 04.06.2004 20:20:54

Hallo,

marmeladebomber hat geschrieben: aber dotgnu.org möchte ja einen "echten" compiler schreiben, oder ist das nur die implementation des compilers?

ich kenne mich jetzt nicht mit C# im Detail aus, vom Prinzip ist es aber wie Java angelegt, in Bytecode kompilieren und dann durch eine vm ausführen.
Das hindert aber niemand daran auf die vm zu verzichten und einen "richtigen" Kompiler zu schreiben, du kannst z.B. mit dem gcc auch java Programme kompilieren so das sie ohne vm ausgeführt werden können. Ich könnte mir also auch gut vostellen das was ähnliches für C# geplant ist.

Edit: suntsu war etwas schneller

Joghurt · Beitrag von **Joghurt** » 04.06.2004 20:28:46

marmeladebomber hat geschrieben:EDIT: der gnudot compiler ist in C geschrieben, der mono in c#
Problem dabei ist das henne/ei prinzip. der mono muss irgendwann unter MS.net compiliert werden. da könnte MS theoretisch einen riegel vorschieben.

Das GCC musste auch mal mit einem anderen Compiler compiliert werden; das GCC in C und mono in C# gechrieben ist, finde ich ganz lustig

peschmae · Beitrag von **peschmae** » 04.06.2004 20:33:27

marmeladebomber hat geschrieben:EDIT: der gnudot compiler ist in C geschrieben, der mono in c#
Problem dabei ist das henne/ei prinzip. der mono muss irgendwann unter MS.net compiliert werden. da könnte MS theoretisch einen riegel vorschieben.

Da hätte MS theoretisch den Riegel vorschieben können. Jetzt ist der Mono-Compiler schon recht lange self-hosted.

Die grössten Unterschiede zwischen .NET und Java sind:
- Java wird grundsätzlich interpretiert und - wenn ein Codestück oft ausgeführt wird - mit dem JIT kompiliert und nach und nach optimiert. Bei .NET (nicht bei Mono, die haben einen portablen Intepreter und einen JIT-Compiler für x86) wird alles JIT kompiliert.
- .NET ist für mehrere Sprachen gedacht - nicht nur C# sondern auch C++, Basic, etc

Mal abgesehen davon sind die Lizenzen bei beidem böse - und eine komplette freie Implementierung gibts weder von .NET noch von Java.

MfG Peschmä

glar00k · Beitrag von **glar00k** » 05.06.2004 16:39:23

peschmae hat geschrieben: Mal abgesehen davon sind die Lizenzen bei beidem böse - und eine komplette freie Implementierung gibts weder von .NET noch von Java.

MfG Peschmä

Dann musst du aber ganz fix den debian maintainern auf die Finger hauen, die haben nämlich mono (eine .NET Implementierung :) nach unstable in den main tree geschoben :)

Grüße

peschmae · Beitrag von **peschmae** » 05.06.2004 18:44:54

wieso?

Ich sprach von keine komplette freie Implementierung, nicht von keine komplett freie Implementierung

Ausserdem bin ich nicht mohameth und schreibe dauernd Beschwerdenbriefe bzw Mails

MfG Peschmä

glar00k · Beitrag von **glar00k** » 05.06.2004 20:26:59

Ups, der Teufel steckte mal wieder im Detail, Sorry :) Aber Mono wird den frei verfügbaren .Net Standard mit Version 1.0 IMHO schon ziemlich komplett unterstützen. Das Microsoft-Spezifische Zeug brauchen wir eh nicht :)

Grüße

marmeladebomber · Beitrag von **marmeladebomber** » 05.06.2004 21:12:21

weitere grundlegende fragen:

die frage welches toolkit man nehmen soll um eine gui zu kreieren:
a) windows.forms (wird, wies ausschaut bald gut implementiert)
b) wx.net (osx, windows, linux unter einem hut)
c) gtk# (windows, linux, osx nativ ist fraglich. gtk gibts auch nicht nativ)

sympatisch finde ich wx.net, da osx dabei ist und frei.
windows.forms wird bald gut unterstützt; warum soll ich mir die "mühe" machen in wx.net zu implementieren. Außerdem würde sich der windowsanwender eine Installation bzw. eine Fehlerquelle sparen.

Wie seht ihr das?

peschmae · Beitrag von **peschmae** » 06.06.2004 12:00:56

Naja, insgesamt sehe ich den Vorteil einer VM einfach nicht ganz.
(Und ja, ich habe recht lange Java programmiert und mache das immer noch ab und zu)

Zu den Toolkits - die Frage ist vor allem wie konsistent Wx.Net (bzw. WxWidgets im allgemeinen) implementiert ist. Mit SWT hatte ich diesbezüglich noch recht grosse Probleme.
Gtk ist für Portierungen auf nicht-X11-Plattformen nicht gerade der Hammer, leider.
Von Windows.Forms habe ich nicht wirklich ne Ahnung - ich nehme mal an dass es gelungener ist als MFC, schliesslich war da ja der Borland-Chefentwickler, den sich M$ geklaut hat, dran mit beteiligt. Fragt sich nur ob es endlich LayoutManager gibt

Naja, nach dem Release muss ich mir das alles wohl man noch n bisschen angucken. Aber irgendwie hat das ganze .NET-Zeugs einen ungemütlichen Beigeschmack - man weiss nie was Microsoft noch alles anstellt.
In der Zwischenzeit geht meine Stimme an C++ mit Qt.

MfG Peschmä

marmeladebomber · Beitrag von **marmeladebomber** » 06.06.2004 13:49:32

wie macht das eigentlich gimp?
Das läuft unter MACos, Linux und Windows. Und verwenden wird wahrscheinlich GTK (Gimp Tool Kit)

Wird da der Code stark verändert für die platformunabhängig, oder ist sind die Änderungen nicht besonders groß und man braucht im wesentlichen nur den Code unter eineme anderen System kompilieren?

Beitrag von **BeS** » 06.06.2004 14:01:50

Hallo,
vom Prinzip reicht es wenn du GTK+ auf windows installierst, solange du keine gnome libs verwendest sollten du die Programme dann kompilieren können. Von daher ist es ähnlich wie Qt/kde-libs.
In der Praxis ist es aber nichtmehr so einfach. Ich habe mal eine Zeit lang damit experimentiert und es nicht geschafft GTK+ so einzurichten, dass ich einfache GTK Programme unter windows kompilieren konnte.
Auf der GTKmm Seite gibt es eine relativ einfache Anleitung, allerdings sah die GTK+ Anleitung damals auch relativ einfach aus.

Irgendwie fehlt mir auch die Motivation es nochmal mit gtkmm zu probieren seit ich Qt kenne.
Die einzige Motivation ist, dass ich als gnome user gerne mit "meinem" Toolkit programmieren würde, aber diese Motivation hält sich momentan in Grenzen.

marmeladebomber · Beitrag von **marmeladebomber** » 06.06.2004 16:29:52

wie schaut es bei der portabilität mit den wxwidgets aus? die sind ja quasi genau für das gemacht? Gibts da auch so viele probleme?

peschmae · Beitrag von **peschmae** » 06.06.2004 20:01:06

marmeladebomber hat geschrieben:wie macht das eigentlich gimp?
Das läuft unter MACos, Linux und Windows. Und verwenden wird wahrscheinlich GTK (Gimp Tool Kit)

Wird da der Code stark verändert für die platformunabhängig, oder ist sind die Änderungen nicht besonders groß und man braucht im wesentlichen nur den Code unter eineme anderen System kompilieren?

Also die Windows-Ausgabe ist eine "richtige" Portierung - nicht nur (wie bei Qt, Werbespot (uups, ist ja verboten hier

)) einfach neu kompilieren.
Bei MacOS X weiss ichs nicht - da dürfte ein nativer port noch schwieriger werden. Oder verwendet der etwa X11 im Hintergrund (dann ists wohl kein Problem)

WxWidgets ist dafür gemacht - von dem her schauts gut aus. Allerdings kann ich nicht beurteilen wie konsistent die Implementierungen untereinander sind.
(Qt (Werbespot, schon wieder

) hat diesbezüglich keine Probleme, weil es die Widgets selber zeichnet (dabei wird allerdings unter MacOS die native Theme-Engine berücksichtigt))
Würde mich auch interessieren wie reibungslos bei WxWidgets Ports vor sich gehen.

MfG Peschmä

marmeladebomber · Beitrag von **marmeladebomber** » 07.06.2004 20:51:42

wie seht ihr das (strategisch, bitte kein flameware gnome/kde)?

Redhat/Fedora dh. USA, GB, China, Japan sind, glaube ich die meisten gnomuser
Europa -> KDE User

Dann gibts ein Projekt auf freedesktop.org dass qt/gtk zusammenführt, sodass die Programme einheitlich ausschauen werden. dh. es ist wurst ob gnome/kde

Suse/Novell/OpenOffice Ximian/Ximian Red Carpet...
Mono/Evolution/Novell Ifolder sind alles gtk Programme
java was auch ein rolle spielen wird, ist swing ua.

also jezt rein strategisch, den Markt beobachtend würde ich derzeit eher gtk (dh. wxwidgets) Programmieren als qt. Platformunabhängigkeit wird immer wichtiger werden. Zumindest Windows und Linux. Apple ist sicherlich ein thema, da die meisten Entscheidungsträger mit Apple rundumlaufen und man die so ködern kann.

dh:
c++ => wxwidgets (11 Jahre erfahrung, dh was)
c => gtk (eine ewigkeit, sollte auch funktionieren)
c# => gtk oder wx.net (würde ich eher als sehr jung bzeichnen)