Im .Net Framework sind eine Menge toller Klassen und Funktionalitäten enthalten, die einem das Leben einfacher machen und sicherliche auch für größere OpenGL Projekte verwendet werden können.

Ich habe mal einige Punkte ohne spezielle Reihenfolge aufgelistet, die mir mal so auf Anhieb eingefallen sind. Vielleicht kann ja jemand noch ergänzen was ihm wichtig am .Net 2.0 Framework ist.

1) Serialization
Man kann Objekte genauso wie sie sind auf einen Stream speichern und auch wieder laden. Das Format ist in .Net 2.0 auch abwärtskompatibel. Wenn man Felder hinzufügt, bleiben die alten Daten immer noch lesbar.

2) Assemblies
Gerade wenn man Programme flexibel oder erweiter machen will stößt man mit DLL's oft an die Grenzen. Man muß eine Schnittstelle definieren. Bei Klassen oder gar VCL Formen gibt's Probleme. Selbst einfache dynamische Arrays oder Strings sind nicht so einfach. In .Net muß man einfach nur eine Referenz zum Projekt hinzufügen oder die Assembly zur Laufzeit laden.

3) Integrierter C# Compiler
Eine Scriptsprache zu machen ist sicherlich nicht so furchtbar aufwendig. Auch nicht wenn man nativen Code erzeugen will. Aber hier bekommt man den C# Compiler gleich umsonst mitgeliefert. Und der Code läuft auch durch den gleichen JIT Compiler wie die Hauptanwendung ist wird daher besser als optimiert als die normale <Delphi 2005 Win32 Exe. Ein weiterer Pluspunkt ist, das es auch hier wieder keine harte Schnittstelle (Fassade) geben muß. Alle Klassen können direkt verwendet werden.

4) Reflection
Reflection gibt's ja auch im alten Delphi nur für Klassen und published Properties. Im .Net Framework sind vollständige TypeInformationen verfügbar. Eine besonders schöne Sache sind die Attribute, mit denen man Zusatzinformationen an Objekte heften kann.

5) Garbage Collector
Natürlich ist die manuelle Objektfreigabe kein Hindernis. Hat ja auch so die ganzen Jahre gut funktioniert. Aber es ist eine große Erleichterung diesen Gedanken nicht mehr ständig im Hinterkopf haben zu müssen und sich dann mit speziellen Konstruktionen wie TObjectList zu behelfen. Zuerst ist man immer versucht irgendwo einen Destruktor Aufruf gleich mithinzuschreiben, aber mit der Zeit lernt man den GC schätzen, auch wenn es erst verunsichert, das sich Objekte plötzlich frei im Speicher befinden können.

6) Standardklassen
Im .Net 2.0 Framework gibt's dank Generics für alle wichtigen Zwecke bereits vordefinierte Klassen und man ist immer erstaunt, an was alles gedacht worden ist. Viele Dinge werden dadurch dann recht einfach.
Eine besonders schöne Sache sind die generischen Collections wie List<>,LinkedList<>,Stack<> oder Dictionary durch die dann die ganzen Typecasts entfallen, die man bei TObjectList oder TStringList immer hatte.

Interessant wäre auch mal so ein Vergleich zwischen Java und .net.
Ich habe bisher bis keinen der beiden "Techniken" gearbeitet, und würde mal gerne wissen welche eher lernwürdig ist.

Was mich bisher an ".net" stutzen läßt, ist der Risiko Faktor Microsoft.

• Kann es Probleme geben wenn man .net Anwendungen unter Linux nutzt (etwa mit Mono)?
• Wie weit hat Microsoft die Struktur hinter ".net" veröffentlicht?
• Hat Microsoft irgend welche Rechte an ".net", die mich als Entwickler oder Anwender hinderlich sein können?

MfG
Flo

_________________
Danke an alle, die mir (und anderen) geholfen haben.
So weit... ...so gut

Wie das mit Linux aussieht, weiß ich nicht genau. Die Common Language Infrastructure ist aber mittlerweise genauso wie C# standardisiert und es gibt eine OpenSource Referenzimplementation mit dem Namen Rotor, auf der die Projekte für andere .Net Plattformen basieren. Der Quelltext des C# Compilers ist übrigens auch mit dabei.

http://msdn.microsoft.com/msdnmag/issue ... SourceCLI/
http://msdn.microsoft.com/library/en-us ... rcecli.asp
http://www.microsoft.com/downloads/deta ... laylang=en

Die Idee hinter .NET ist ja eigentlich recht einfach - ebenso wie der IL "Assembler", der auf einem Kellerstack ohne Register basiert (schon seit uralten Zeiten geistert in diversen Magazinen und dem Internet übrigens dieser Pascal Kompiler herum: http://homepages.cwi.nl/~steven/pascal/, der prinzipiell ganz ähnlich funktioniert, nur dass der generierte P-Code halt interpretiert wird).

Um nun aber einen Standard durchzuboxen, braucht es nicht nur ein elegantes Konzept (deren geniale gibt es wie Sand am Meer - man muss sich ja nur mal die enorme Auswahl an (teilweise von einzelnen Programmierern geschriebenen) Betriebssystemen ansehen, die oft wirklich gute Ideen inkludieren - die aber leider fast niemand kennt und niemand nutzt) - sondern es braucht auch die entsprechende Software dazu.
Im Fall von .NET ist das eindeutig Visual Studio und auch Delphi .NET - und je mehr Software für .NET entwickelt werden wird, desto wichtiger wird es werden.

Das ist nun aber primär nichts Schlechtes - der Standard ist offengelegt, und es gibt auch Open Source Implementationen (man kann Mono z.B. auch für Windows herunterladen - einige IL Programme für die Konsole (die schreiben sich fast wie in einer Hochsprache, da man auch die ganzen Objekte direkt ansprechen kann), die ich zum herumprobieren geschrieben habe, ließen sich dann auch problemlos unter .NET 1.0, 1.1 und Mono kompilieren). Wenn es zu dessen Durchsetzung der Marktmacht eines Softwareriesen bedarf, soll es halt so sein - wenn dieser Standard von jedem genutzt werden kann (was offensichtlich der Fall ist), ist das für Entwickler besser, als wenn niemand weiß, woran er sich halten soll.

_________________
Viel Spaß beim Programmieren,
Mars
http://www.basegraph.com/

Kann man eigentlich normale mit dem Visual Studio erzeugte Programme unte Mono laufen lassen, oder muß man da die entsprechenden Assemblies verwenden ? Theoretisch wäre es ja denkbar, aber ich meine mal gelesen zu haben, dass unter Mono statt Windows.Forms dann GTK verwendet wird.
Eigentlich sollte es gerade für Linux Fans ein Grund zur Freude sein, weil es dann auch hochwertige Software unter Linux geben wird, falls das so einfach funktioniert.

Nein, tut es leider nicht, weil die Funktionsweise zwischen der GTK und den WinForms sehr arg unterschiedlich sind. Ich hatte eine Zeit lang eine Diskussion mitverfolgt bei der man andacht einen GTK<==>WinForm Wrapper zu schreiben, allerdings gab es dort wohl leider zuviele technische Gründe, die dagegen sprachen. Der aktuelle Stand von Mono bei den WinForms ist leider noch weitab vom produktiven, da selbst kleine Applikationen doch noch sehr arg merkwürdig aussehen. Aber letztendlich, sofern MS nicht die Schirmherrschaft über .NET innehält könnte .NET zumindest Java im Bezug auf Plattformunabhägigkeit sehr gefährlich werden.

_________________
"Light travels faster than sound. This is why some people appear bright, before you can hear them speak..."

Solange man Dinge verwendet die es auf beiden System gibt geht es schon. Da windows.forms noch in der Entwicklung steckt koennte man zb GTK verwenden, das gibt es auch fuer windows. Somit koennte man jetzt schon platform unabhaengig programmieren. Bis auch windows.forms vorhanden ist, ist sicher nur eine Frage der Zeit.

Gibt es von .Net eigentlich wie bei JAVA auch die Source Dateien des Frameworks?
Manchmal würde man doch gerne mal sehen wie das ein oder andere implemtiert wurde. Aber bisher ging das nicht. Bei dem Java SDK wird der Source ja mitgeliefert. hab ich den bei .Net vllt. übersehen?

_________________
(\__/)
(='.'=)
(")_(")

Es gibt eine OpenSource Referenzimplementation Rotor, die man auch bei Microsoft laden kann.
Den Quelltext gibt's auch so zum Durchsuchen an vielen Stellen im Netz. z.B. hier:
http://dotnet.di.unipi.it/Content/sscli ... paces.html

Dies ist kein voll ernsthafter beitrag, allerdings schreibe ich dies, nachdem ich Gerüchte über ein .NET Framework 3.0 gehört habe.

_________________
Shareholder und Leitender Entwickler bei Pipedream-Games.

Zitat: Siehst du diesen Park da unten? Jeden Tag lernen sich darin Menschen kennen und verlassen einander. Und du hast dein ganzes Leben Zeit darin zu gehen.

Zu C# 3.0 habe ich ja schon im Off Topic Bereich LING geschrieben.