RAD Studio 2009 und .net?

[jfheins]

Zitat von anylol:

Bedeutet das also:
Wenn ich mir .net anschaue ist es besser (ja sorry, anderes Wort gibt es hierfür nicht) als Delphi, weil dieses kylix ja irgendwie tot ist?

Naja ... ich muss etwas ausholen:

Also, so einen "Satz von funktionen für grundlegende Aufgaben" gibt es eigentlich schon immer - gehört eigentlich zwingend zu einem Betriebssystem.

Seit Windows 95 hatte man nun gewisse Funktionen, und aufgrund wachsender Anforderungen etc. sind immer mehr Funktionen hinzugekommen. Irgendwann wurde es dann unübersichtlich, weil es von vielen Funktionen 6 verscheidene Versionen gibt, manche melden einen Fehler im Rückgabewert, manche nicht und pi pa po.
Das heißt Win32-API.
Dann hat Microsoft .net entwickelt um einmal schön "aufzuräumen" Zusammengehörige Funktionen wurden in Klassen gepackt, vielfach erweitert und vereinheitlicht. Neue Konzepte wurden verwirklicht und das nannte man dann ".net Framework"

Win32-API hat Windows natürlich noch, aber in jedem neueren Windows ist auch das .net-Framework vorhanden.

Beide Sachen haben aber gewisse Vor und Nachteile. Eine Sache jetzt als besser darzustellen hat keinen Sinn, da sofort jemand kommt und sagt "da ist das andere schneller"

Zitat:

Kann ich .net auch auf dem Mac compilieren? Wie heißt dort das Gegensrück?
(wenn ich schon mich mit was beschäftige, dann richtig).

Ich galube es geht, aber ich bin mir nicht sicher. Da MacOSX ja "nur" ein aufgebohrtes Linux ist, könnte sogar Mono drauf laufen aber mit macs kenne ich mich nicht so gut aus.

Zitat:

Kann man behaupten, das .net konkurenzfähig ist zu c(++)? (wegen, wenn es auch auf dem mac funktioniert, plattformunabhängig ist?)

Das kann man denke ich so sagen.
Edit: Was Anwendungsentwicklung angeht - einen Mikrocontroller in C# mit .net zu programmieren .. anyone?

Zitat:

Wo ist Boarland hin? Delphi= Borland! Oder aufgekauft?

Borland hat Delphi an Embarcadero verkauft, und Embarcadero lässt es unter der Marke CodeGear laufen.

Zitat:

Ist mono zu net 100% kompatibel?

Nicht ganz, es hinkt immer ein wenig hinterher. Aber das wesentliche funktioniert. Nur eben die allerneuesten Entwicklungen brauchen eben immer etwas Zeit.

[Phoenix]

Zitat von Sherlock:

mono ist nicht 100% kompatibel. Es gibt aber auch ein mono für Mac.

Der derzeitige Stand von mono ist 2.0 (http://www.heise.de/open/NET-Klon-Mo...meldung/116972

Aufpassen Mono 2.0 != .NET 2.0

Mono 2.0 beinhaltet z.B. bereits etliche Bibliotheken aus .NET 3.5 (z.B. System.Core.dll - das ganze Zeug für LINQ ist da drin). Einige fehlen dafür aber auch z.B. noch aus 3.0 (bzw. sind noch nicht fertig - z.B. die Workflow Foundation). Der Funktionsumfang des .NET Frameworks 2.0 soll aber wohl inzwischen komplett fertig sein.

Will heissen: In aller Regel (ausser man benutzt so schnieke neue Sachen wie ASP.NET MVC...) sollte das eigene Gedöns auch auf Mono (und damit auf der gleichen Runtime unter Windows, Linux und auf dem Mac) laufen.

[Apollonius]

Zitat von anylol:

Wenn ich mir .net anschaue ist es besser (ja sorry, anderes Wort gibt es hierfür nicht) als Delphi, weil dieses kylix ja irgendwie tot ist?

Kann ich .net auch auf dem Mac compilieren? Wie heißt dort das Gegensrück?
(wenn ich schon mich mit was beschäftige, dann richtig).

Kann man behaupten, das .net konkurenzfähig ist zu c(++)? (wegen, wenn es auch auf dem mac funktioniert, plattformunabhängig ist?)

.NET ist keine Sprache. .NET ähnelt in vielerlei Hinsicht Java: Ein Compiler erzeugt Bytecode, der dann von einer Runtime interpretiert oder JIT-kompiliert wird. Die ausgelieferte Datei ist daher bereits plattformunabhängig (natürlich nur, wenn du keine plattformsezifischen Dinge tust). Es heißt also nicht "write once, compile anywhere" wie beispielsweise bei nativem C++ oder Lazarus, sondern "compile once, run anywhere" (in leichter Abwandlung des Java-Mottos). .NET ist letztlich lediglich die Definition dieses Bytecodes, der sogenannten IL.
Es gibt Compiler, die beispielsweise C in Java-Bytecode übersetzen können. Dies ist allerdings nicht die Regel - meistens schreibt man Java-Programme auch in Java. In .NET ist das ein wenig anders. Für sehr viele Sprachen gibt es einen .NET-Compiler, beispielsweise C++, Delphi, C# und VB.NET (die beiden letzteren gibt es überhaupt nicht nativ).

[MrSpock]

Zitat von jfheins:

Microsoft hat nicht das Monopol auf .net, es gibt auch Mono für Linux.

Microsoft hat sehrwohl das Monopol auf .NET. Es gibt nur Gruppen, die dasselbe Interface für andere Plattformen zu implementieren versuchen. Neben der Harmonisierung der Betriebssystem-Funktionsaufrufe, will MS mit .NET den bisherigen Platzhirsch für plattformunabhängige Programmierung -JAVA- Konkurrenz machen.

[anylol]

Zitat von MrSpock:

Microsoft hat sehrwohl das Monopol auf .NET.

Äm, ich sagte Patent oder monopol? Naja, nicht das sie wirklich ein Software-Patent drauf haben. Das hieße ja, Mono lebt nicht mehr lange (bis zum Softwarepatent).

Zitat von Apollonius:

Ein Compiler erzeugt Bytecode, der dann von einer Runtime interpretiert oder JIT-kompiliert wird. Die ausgelieferte Datei ist daher bereits plattformunabhängig

Äm, nicht richtig oder??
Wenn ich unter Windows compiliere mit einer windows-IDE oder nur einen compiler, ist es eine windows-binary. richtig?
Ich muss also je OS und ie compiler 1x compilieren.

Zitat von Apollonius:

(natürlich nur, wenn du keine plattformsezifischen Dinge tust).

das bedeutet für mich: winapi= ignorieren. Und rtfm lesen.
Ich erhoffe mir das die community groß wird, größer als die von MSDN.
(Anmerkung: Ich finde es klasse wenn ich abkürzen kann dank des tooltips auf den Abkürzungen!)

Zitat von Apollonius:

In .NET ist das ein wenig anders. Für sehr viele Sprachen gibt es einen .NET-Compiler, beispielsweise C++, Delphi, C# und VB.NET (die beiden letzteren gibt es überhaupt nicht nativ).

Kannst mir jemand verraten, mit welchem Sinn es für C++ einen .net-compiler gibt?
c++ ist doch plattformunabhängig, da kommt *jemand* und bastelt etwas, was die Welt umbedingt braucht, einen .net-compiler. Ironischer weise wäre es auch noch so, das man das net-Framework braucht, und nicht auf mono verwiesen wird... (habe ich nicht nachgeschaut)

Schließlich gibt es auch eine Sprache D und ich erfinde morgen Programmiersprache F (mist, gibt es schon seid 1999, dann nehme ich Z!).


Andere Frage:
Ein Toolkit kann ich aber trotzdem verwenden, oder? Finde GTK schick!
(der Übersichtlichkeit: bitte nur über Geschmack streiten per PM, falls erwünscht. Meiner Meinung nach nicht.)

[mkinzler]

Zitat:

Äm, nicht richtig oder??

Bei Compilern für .Net-Sprachen oder für die Java-VM schon

[Apollonius]

Zitat von anylol:

Zitat von Apollonius:

Ein Compiler erzeugt Bytecode, der dann von einer Runtime interpretiert oder JIT-kompiliert wird. Die ausgelieferte Datei ist daher bereits plattformunabhängig

Äm, nicht richtig oder??
Wenn ich unter Windows compiliere mit einer windows-IDE oder nur einen compiler, ist es eine windows-binary. richtig?
Ich muss also je OS und ie compiler 1x compilieren.

Zitat von Apollonius:

Es heißt also nicht "write once, compile anywhere" wie beispielsweise bei nativem C++ oder Lazarus, sondern "compile once, run anywhere"

Das habe ich durchaus ernst gemeint.

[Phoenix]

Zitat von anylol:

Zitat von Apollonius:

Ein Compiler erzeugt Bytecode, der dann von einer Runtime interpretiert oder JIT-kompiliert wird. Die ausgelieferte Datei ist daher bereits plattformunabhängig

Äm, nicht richtig oder??
Wenn ich unter Windows compiliere mit einer windows-IDE oder nur einen compiler, ist es eine windows-binary. richtig?
Ich muss also je OS und ie compiler 1x compilieren.

Nein. .NET Code ist Intermediate-Language.
Jede Plattform übersetzt den IL-Code beim erstmaligen Aufrufen (also just in time - JIT) in echten binärcode für die CPU. Das bedeutet sogar, dass der IL-Code ggf. auf einem x64 System anders übersetzt wird als einem 32bit-System, und hier durch die runtime nochmal auf die jeweilige CPU optimiert wird.

Einmal compilieren -> gleiches Binary auf Windows, Linux oder Mac-Systemen benutzen. Und im Gegensatz zu Java heisst es sogar tatsächlich compile once, run anywhere und nicht compile once, debug anywhere.

Zitat von anylol:

Andere Frage:
Ein Toolkit kann ich aber trotzdem verwenden, oder? Finde GTK schick!

Sofern es das Toolkit für .NET gibt, ja. Aber Du hast Glück: Das Mono-Projekt arbeitet auch an Gtk#: http://www.mono-project.com/GtkSharp

Es gibt für Max OSX z.B. auch Cocoa#.

[DMW]

Zitat von anylol:

Kannst mir jemand verraten, mit welchem Sinn es für C++ einen .net-compiler gibt?
c++ ist doch plattformunabhängig, da kommt *jemand* und bastelt etwas, was die Welt umbedingt braucht, einen .net-compiler.

C++-Code ist nur solange plattformunabhängig, wie du dich auf die standardisierten Sprachmittel und Bibliotheken beschränkst; die C++-Standard-Library ist allerdings in vielen Fällen nicht ausreichend.

Da viele Unternehmen Unmengen wertvollen C++-Codes haben und somit nicht ohne weiteres ihre ganze Anwendung neu schreiben können, bietet ihnen C++/CLI die Möglichkeit, in einer einzigen Anwendung sowohl ihre Altbestände als auch neuen Code, der die Vorteile von .NET nutzt, gemeinsam zu verwenden. Das ist meines Wissens in keiner anderen Sprache möglich, auch ist die Interaktion zwischen managed und unmanaged code AFAIK nirgendwo so einfach.

Wenn du mehr über C++ für .NET wissen willst, lies den Wikipedia-Artikel zu C++/CLI.