Mögt ihr das .NET Framework? Ich bis heute nicht

[marcoX]

Zitat von Ralf Kaiser:

Zitat von marcoX:

Das ist korrekt, aber man kann ja auch in Delphi den Compiler anweisen nicht alles mit einzukompilieren und dann DLLs beilegen. Dann hat man auch nur eine wenige KB große EXE.

Ist mir jedenfalls (die Geschmäcker sind da sicher verschieden) als ein Framework.

Wobei: Wenn man die VCL und anderen nötigen Teile eines Programmes als BPLs beilegt, was hat man dann?

Eben: Man hat ein Framework beigelegt (oder muss es zum Download anbieten)

Man muss ja nicht die ganze VCL beilegen, das was manan DLLs beilegen muss, ist nicht sonderlich viel, ich glaube wenige MB, war jedenfalls damals beim C++ Builder so. Und auch bei C# muss man neue "Komponenten" in Form von DLLs beilegen.

Ich finde die Delphi-Lösung jedenfalls weit flexibler. Ich kann es einkompilieren, ich kann es aber auch lassen.

[Phoenix]

Zitat von marcoX:

Ich finde die Delphi-Lösung jedenfalls weit flexibler. Ich kann es einkompilieren, ich kann es aber auch lassen.

Was ist daran flexibler? Das geht mit .NET bzw. mit Mono auch. Man kann mittels Full-Ahead-of-Time compilation auch die Teile der Runtime in eine native .exe einkompilieren die benötigt werden. Das ist dann das gleiche was Delphi mit seiner RTL macht. Dann wird die .exe halt ein klein wenig größer, man braucht aber dafür kein Framework zu installieren. Hat halt den Nachteil, dass man das dann pro Plattform neu kompilieren muss, also separat für OS-X, Linux und Windows. Ach.. moment.. das kann Delphi ja nicht. Also ist man mit Mono dann doch flexibler

[FredlFesl]

Zitat von marcoX:

Wenn das Borland/Embacadero mit den winzigen Mitteln alles kann, was könnte dann bloß Microsoft alles?

Hast Du überhaupt eine Ahnung, was dot.NET ist?

Zitat von marcoX:

Ich bin wirklich happy, dass es mit Delphi/Lazarus eine letzte Bastion gegen den totalen .NET Zwang gibt!

Dann sind C, Java, php und (so gut wie) alle Web-Applikationen also schon .NET-Zwang?

Mir scheint, Du hast einfach etwas gegen dot.NET, weisst aber gar nicht, warum? ==> Glaube = nichts wissen ==> Religion.

[Daniel]

ehm ... ist das der Versuch, eine Diskussion über Ideologien loszutreten? Nunja ... ein bisschen fundierter müsste die Kritik schon sein, wenn Du an einer ernsthaften Diskussion interessiert bist. Derzeit liegt diese Diskussion auf gleicher Ebene wie zum Beispiel "Ich mag keine Erbsensuppe". Da mag man als Außenstehender nur sagen "Ja und? Ist sein gutes Recht, isst er halt was Anderes."

Das Thema .NET ist hier und woanders x-mal durchgekaut worden. Das .NET-Framework hat technische Eigenschaften, die sich nicht wegdiskutieren lassen und sehr viele Entwickler arbeiten hochproduktiv damit. Natürlich steht es Dir frei, eine Technologie abzulehnen. Du solltest Dir nur darüber im Klaren sein, dass diese "Stammtisch-Mentalität" eine gewisse Professionalität vermissen lässt.

[Bernhard Geyer]

Zitat von marcoX:

Und verschiedene Sprachen...nun es gibt die VCL für Delphi, für den C++ Builder und für PHP, zeitweise gab es sie sogar für C#. Wenn das Borland/Embacadero mit den winzigen Mitteln alles kann, was könnte dann bloß Microsoft alles?

Der Vergleich hinkt. Im Gegensatz zu VCL für .NET ist die FCL verwendbar. VCL.NET war eine Todgeburt. Von "VCL" für PHP ist sehr fraglich wie weit es eingesetzt wird. Auch hat VCL.Delphi wenig mit VCL.PHP gemein. Schon mal eine Portierung probiert? Auch ja: Und läuft VCL schon auf Smartphones (werden ja bald öfter verkauft als Windows-PC's). Und erst gestern musste ich (ok, ist D6) noch einen ziemlichen Bug in Delphi bei verwendung von Widestrings umschiffen (ist in XE gefixt).

Zitat von marcoX:

Microsoft entwickelt seine Tool selbst nicht mit .NET. Weder portiert es Anwendungen (auch kleinere nicht), noch habe ich Software entdeckt, die MS selbst in .NET programmiert hätte.

Ist nicht VS.NET mittlerweile mit NET entwickelt? Diverse ander Tools auch.

[jfheins]

Ich sehe .net zum Großteil als "Delphi VCL 2.0" - und das hat mehrere Gründe. Zum einen natürlich Anders Hejlsberg aber auch sonst gibt es viele Parallelen.

Manche Dinge finde ich in .net besser gelöst - angefangen mit den multicast delegates, über die Sicherbarkeitsdefinitionen bis hin zu den Unicodes Strings.

Unicodes Strings: Waren von Anfang an* dabei. In Delphi kann es da zu Problemen kommen, wenn die Komponente nicht mit Unicode getestet wurde. (Okay, lässt sich kaum vermeiden wenn man das Framework umstellt...)
Sichtbarkeiten: In Delphi gibt es private, protected, public, published, strict private und strict protected. Die Sichtbarkeit hängt auch damit zusammen ob die Klassen in einer Datei stehen oder nicht.
Mir gefällt das Prinzip mit den namespaces besser - Man kann z.B. eine Datei pro Klasse hernehmen und braucht sich noch nichtmal um Kreuzverweise Gedanken zu machen!

multicast delegates spricht für sich denke ich. Auch wenn ich es noch nicht gebraucht habe, sowas habe ich auch lieber direkt in der Sprache integriert. Man kann sich in Delphi zwar eine Lösung zusammenschustern, aber das Kostet ziemlich viel Zeit und man ist darauf angewiesen, diese Lösung auch immer zu benutzen. Fremdcode lässt sich aber nicht immer so leicht anpassen.

Zum Abschluss noch ein kleiner Codeschnipsel, den ich sehr cool finde:

Code:

                for (int i = 0; i < files_lv.Items.Count; i++) // Listview durchiterieren
                {
                    if (files_lv.Items[i].Checked) // Nur die angehakten
                    {
                        ThreadPool.QueueUserWorkItem(new WaitCallback(Calculate), i); // Multithreaded
                        //Calculate(i); // Sequenziell
                    }
                }

Durch Benutzen der einen oder der anderen Zeiel ist die Komplette Berechnung entweder sequenziell oder komplett Multithreaded. Keine zusätzliche Änderung nötig.
Zugegeben, ich musste erst etwas suchen bis ich den ThreadPool gefunden hatte. Und alles nach Calculate() muss damit zurecht kommen, in einem Thread aufgerufen zu werden. Da wurden also schon Anpassungen fällig. Aber ich finde das Stückchen Code trotzdem genial

* = ab .net 2.0, vorher hab ich's nicht benutzt

Ach ja, asp.net ist natürlich auch noch eine super Sache. Ich hab's mir einmal angesehen und meine Begeisterung für PHP ist schlagartig gesunken
Und ja, wenn man sich geschickt anstellt kann man den gleichen Code einmal als Desktop Anwendung und einmal als Webservice verwenden.

[Viktorii]

Zitat von jfheins:

multicast delegates spricht für sich denke ich.

Was ist denn eine multicast delegate?

Was ein delegate ist, glaube ich verstanden zu haben. Im Prinzip das was bei Qt ein Slot ist !?!

Aber was heißt in dem Zusammenhang multicast?

[Phoenix]

Zitat von Viktorii:

Zitat von jfheins:

multicast delegates spricht für sich denke ich.

Was ist denn eine multicast delegate?

Eine Delegate ist im Prinzip nichts anderes als ein Funktionspointer.

Mit dem was so technisch 'Multicast Delegate' heisst kann man einfach gesagt an ein einziges Event mehrere Handler gleichzeitig dran hängen und alle werden ausgeführt.

In Delphi kann ein Event immer nur genau eine Methode ausführen. Ausser man trickst ein bissel rum (ich hab hier mal vor Jahren eine Multicast-Delegate Klasse für Delphi gepostet).

[Stevie]

Zitat von Phoenix:

Zitat von Viktorii:

Zitat von jfheins:

multicast delegates spricht für sich denke ich.

Was ist denn eine multicast delegate?

Eine Delegate ist im Prinzip nichts anderes als ein Funktionspointer.

Mit dem was so technisch 'Multicast Delegate' heisst kann man einfach gesagt an ein einziges Event mehrere Handler gleichzeitig dran hängen und alle werden ausgeführt.

In Delphi kann ein Event immer nur genau eine Methode ausführen. Ausser man trickst ein bissel rum (ich hab hier mal vor Jahren eine Multicast-Delegate Klasse für Delphi gepostet).

Für neuere Delphi Versionen (ab 2010) hab ich auch mal eine geschrieben

Zum Thema: Obwohl ich mich primär als Delphi Entwickler sehe, hab ich in der Vergangenheit von .Net sehr viele Impulse bekommen gerade was meine Library angeht und ich schau mir immer gerne Sachen direkt aus dem Framework oder aus .Net Projekten ab. Durch die geringere Bürde an Altlasten und der GC kann .Net an vielen Stellen einfach seine volle Kapazität ausspielen, was in Delphi nicht oder nur sehr umständlich geht. Dafür hat Delphi wieder an anderen Stellen seine Stärken.

[daywalker9]

Zitat von Bernhard Geyer:

Zitat von marcoX:

Microsoft entwickelt seine Tool selbst nicht mit .NET. Weder portiert es Anwendungen (auch kleinere nicht), noch habe ich Software entdeckt, die MS selbst in .NET programmiert hätte.

Ist nicht VS.NET mittlerweile mit NET entwickelt? Diverse ander Tools auch.

Ja, VS 2010 ist mit .NET und WPF programmiert worden.