Hallo,
Welche Vorteile bringen Net, ich habe gestern ein Programm in Delphi.net erstellten.

Dieses Programm brauchte eine lange Zeit bis es gestartet war, danach war es gleich schnell.

Mit freundlichen Grüssen

Klaus Flötgen

Grundlagen über .net kannst du z.B. beim DSDT nachschauen: Microsoft .NET Framework. Der Vorteil besteht vor allem darin, dass es eine interpretierte Sprache ist, sie also Platformunabhängig ist (oder zumindest sein sollte). Der Nachteil dessen (du hast es schon erwähnt) sind die imensen Geschwindigkeitseinbußen, die durch das Interpretieren hervorgerufen werden

Alstar

Alstar hat folgendes geschrieben:

Grundlagen über .net kannst du z.B. beim DSDT nachschauen: Microsoft .NET Framework. Der Vorteil besteht vor allem darin, dass es eine interpretierte Sprache ist, sie also Platformunabhängig ist (oder zumindest sein sollte). Der Nachteil dessen (du hast es schon erwähnt) sind die imensen Geschwindigkeitseinbußen, die durch das Interpretieren hervorgerufen werden Alstar

....da sieht man wie gut du den Artikel gelesen hast! Bei .NET wird nichts Interpretiert, das .NET Framework hat einen compiler der das Programm auf den Aktuellen PC anpasst, und die Programme laufen teilweisse um mehrere Prozent schneller( MMX und SSE wird genutzt )!

Den Geschwindigkeitsverlust den der Threadersteller ansprach ist nur bei Delphi vorhanden! Bei anderen Entwicklungsumgebungen wie Visual Studio Express C# oder #develop merke ich davon nichts!
Zudem ist das Delphi.NET nicht sonderlich gelungen, und um einmal Robert_G zu Zitieren:
"Nimm doch lieber Chrome" -> www.chromesville.com/ <--- Ist ein Paskaldialekt

Speedmaster hat folgendes geschrieben:

Den Geschwindigkeitsverlust den der Threadersteller ansprach ist nur bei Delphi vorhanden!

Echt? Also ich habe hier nur beim ersten Start irgendeines .NET Programms Geschwindigkeitseinbusen die daraus resultieren, dass das .NET Framework erstmal geladen werden muss. Und das betrifft nicht nur Delphi.NET Anwendungen sondern auch C# Anwendungen.

Zitat:

Bei anderen Entwicklungsumgebungen wie Visual Studio Express C# oder #develop merke ich davon nichts!

Ich merke auch bei Notepad davon nichts. Du mischt hier Programmstart und IDE-Start (die IDE ist zwar auch ein Programmm, aber das muss der Endkunde nicht ausführen).

Zitat:

Zudem ist das Delphi.NET nicht sonderlich gelungen

Das ist Geschmackssache.

Zitat:

"Nimm doch lieber Chrome"

Delphi.NET wurde abwärtskompatibel Entwickelt. Chrome musste keine Abwärtskompatibilität garantieren, weil es einfach nichts gibt was bereits mit Chrome erstellt wurde. Und wenn man dann von Delphi.NET als Nieschenprodukt spricht, dann begibt man sich mit Chrome in eine noch kleinere Niesche.
Warten wir mal ab, wenn VCL.NET für Avalon bereit steht.

Danke für die Argumente.

Mit freundlichen Grüssen
Klaus Flötgen

AndyB hat folgendes geschrieben:

Delphi.NET wurde abwärtskompatibel Entwickelt. Chrome musste keine Abwärtskompatibilität garantieren, weil es einfach nichts gibt was bereits mit Chrome erstellt wurde. Und wenn man dann von Delphi.NET als Nieschenprodukt spricht, dann begibt man sich mit Chrome in eine noch kleinere Niesche. Warten wir mal ab, wenn VCL.NET für Avalon bereit steht.

Ich wüsste nicht das Delphi.NET jemals Abwärtskompatibel gewesen ist! Schließlich ist es die erste Delphi.NET Version!
Das Umwandeln von Delphi.Win32 zu Delphi.NET wäre eh kein Problem, wenn Delphi.NET einen etwas anderen Syntax hat wie Delphi.W32!

Speedmaster hat folgendes geschrieben:

Ich wüsste nicht das Delphi.NET jemals Abwärtskompatibel gewesen ist! Schließlich ist es die erste Delphi.NET Version!

Delphi.NET ist bis auf Zeiger und vereinzelte Konstrukte (z.B: virtuellen Konstruktor in überschriebenem Konstruktor aufrufen) zu Delphi.Win32 kompatibel. Man kann damit Code-Sharing betreiben und sogar alte Programme, die nicht auf Zusatzkomponenten setzen, die nicht für VCL.NET verfügbar sind, und auch keine Zeigeroperationen durchführen fast ohne irgendwas umzuschreiben als .NET Programm kompilieren.

Zitat:

Das Umwandeln von Delphi.Win32 zu Delphi.NET wäre eh kein Problem, wenn Delphi.NET einen etwas anderen Syntax hat wie Delphi.W32!

Klar, weil man dann alles neu bzw. umschreiben müsste.
Bei Chrome scheitert das Code-Sharing bereits am neuen Schlüsselwort method, dass es in Delphi nicht gibt und man entweder alles IFDEF'ed oder gleich eine neue Unit aufmacht. Dann hat man aber den Code zweimal und Bugs müssen zweimal ausgebessert werden, sofern man beide (.NET und Nativ) gleichzeitig unterstützen will.

Speedmaster hat folgendes geschrieben:

....da sieht man wie gut du den Artikel gelesen hast! Bei .NET wird nichts Interpretiert. Den Geschwindigkeitsverlust den der Threadersteller ansprach ist nur bei Delphi vorhanden! ...ist das Delphi.NET nicht sonderlich gelungen, und um einmal Robert_G zu Zitieren: "Nimm doch lieber Chrome" -> www.chromesville.com/ <--- Ist ein Paskaldialekt

Der JIT Compiler kann aber durchaus mit einem Interpreter verglichen werden ! Die Zeiten einer einzelnen EXE sind dann vorbei. Die muß erst mal vorbereitet und zum laufen gebracht werden. Es werden andere Voraussetzungen gebraucht. Wie bereits gesagt wurde : ein Haufen IFDEFs wird nötig werden, sofern Win32 und .Net möglich sein sollen. Wer nonVCL macht, für den ist kaum Hoffnung in Sicht. Da hilft auch Chrome wohl kaum was.

Das .NET Prinzip gefällt mir auf jeden Fall besser, als die zerstückelte und unsichere WinAPI. Auf mittlere Sicht führt kein Weg dran vorbei. Dieser Tage tauchte bereits ein Programm auf, welches das NET-Framework verlangt hat und das kommt in Zukunft wohl immer öfter vor !

AndyB hat folgendes geschrieben:

Klar, weil man dann alles neu bzw. umschreiben müsste. Bei Chrome scheitert das Code-Sharing bereits am neuen Schlüsselwort method, dass es in Delphi nicht gibt und man entweder alles IFDEF'ed oder gleich eine neue Unit aufmacht. Dann hat man aber den Code zweimal und Bugs müssen zweimal ausgebessert werden, sofern man beide (.NET und Nativ) gleichzeitig unterstützen will.

Sry, aber das verstehe ich nicht, wozu gibt es die Möglichkeit von 'string.Replace();' damit kannst du dein Code innerhalb weniger Minuten oder Sekunden umwandeln und hast überall 'method' anstatt 'function' oder 'procedure'!

Zudem brauchst du kein .NET zu verwenden wenn du es so machst wie du Vorschlägst!
Wenn du richtig .NET Programmieren willst benutzt man die .NET Klassen und nicht die Borland DLL's, den sonst ergibt es IMHO keinen Sinn mit .NET zu arbeiten!

hansa hat folgendes geschrieben:

Der JIT Compiler kann aber durchaus mit einem Interpreter verglichen werden ! Die Zeiten einer einzelnen EXE sind dann vorbei. Die muß erst mal vorbereitet und zum laufen gebracht werden. Es werden andere Voraussetzungen gebraucht. Wie bereits gesagt wurde : ein Haufen IFDEFs wird nötig werden, sofern Win32 und .Net möglich sein sollen. Wer nonVCL macht, für den ist kaum Hoffnung in Sicht. Da hilft auch Chrome wohl kaum was.

Er Interpretiert .NET Assembly Code, und wandelt ihn so in reine Binarys um das er mit Maximaler Geschwindigkeit läuft!
Sicher dauert der Start etwas länger, aber ich merke davon fast nichts!
Ich bin der Meinung es bringt in Zukunft nichts mehr Ausserhalb von .NET zu Arbeiten wenn man Kongurenzfähig sein möchte!

hansa hat folgendes geschrieben:

Das .NET Prinzip gefällt mir auf jeden Fall besser, als die zerstückelte und unsichere WinAPI. Auf mittlere Sicht führt kein Weg dran vorbei. Dieser Tage tauchte bereits ein Programm auf, welches das NET-Framework verlangt hat und das kommt in Zukunft wohl immer öfter vor !

Ganz deiner Meinung!

Speedmaster hat folgendes geschrieben:

Ich bin der Meinung es bringt in Zukunft nichts mehr Ausserhalb von .NET zu Arbeiten wenn man Kongurenzfähig sein möchte! ..

Kongurenzfähig wird man so echt nicht. Allerdings gbt es noch ein Wort zu beachten : Kompatibilität. Was macht jemand, der vor 6 Jahren ein Programm gemacht und mehrmals im Einsatz hat ? Soll der etwa alles völlig neu entwickeln ? Es gilt lediglich direkte Winapi Aufrufe nicht einzusetzen, FILE OF zu vermeiden usw.

Wer die Warnungen ab D6 nicht ignoriert, der weiß zumindest schon lange, was zu tun und zu lassen ist. Im Zweifelsfall helfen dann auch ein paar IFDEF aber zumindest nicht Hunderte davon. Selbst in Delphi für W32 gibt es schon Alternativen. MessageDlg habe ich z.B. komplett eliminiert.

hansa hat folgendes geschrieben:

Kongurenzfähig wird man so echt nicht. Allerdings gbt es noch ein Wort zu beachten : Kompatibilität. Was macht jemand, der vor 6 Jahren ein Programm gemacht und mehrmals im Einsatz hat ? Soll der etwa alles völlig neu entwickeln ? Es gilt lediglich direkte Winapi Aufrufe nicht einzusetzen, FILE OF zu vermeiden usw.

Es 'gbt'( <-- ) die Möglichkeit DLL's zu benutzen wie in W32, von daher hat man die Möglichkeit sein Programm im laufe der Zeit umzuschreiben, und kann es auch weiterentwickeln( Erwartet das Teile des Programms in DLL's sind ). Allerdings sollten diese logischerweisse auf Win-API Aufrufe verzichten!

Speedmaster hat folgendes geschrieben:

Sry, aber das verstehe ich nicht, wozu gibt es die Möglichkeit von 'string.Replace();' damit kannst du dein Code innerhalb weniger Minuten oder Sekunden umwandeln und hast überall 'method' anstatt 'function' oder 'procedure'!

Nur dann kann ich ihn nicht mehr in einem anderen Programm verwenden. Nicht alle Programme sind von heute auf morgen .NET Programme. Alte Programme möchten auch gepflegt werden. Und wenn ich eine Unit in zwei Programmmen einsetzen kann (Unit-Sharing), dann mache ich das auch. Und da möchte ich sicherlich nicht 500 und mehr {$IFDEF CHROME}method{$ELSE}procedure/function{$ENDIF} stehen haben.

Zitat:

Zudem brauchst du kein .NET zu verwenden wenn du es so machst wie du Vorschlägst!

Ich möchte ja auch nicht eine .NET und eine native Variante ein und derselben Anwendung haben. Das wäre Unsinn. Aber zwei Programme, die sich an einem Punkt die gleiche Logik teilen, möchte ich nicht zwei mal warten. Nur weil App 1 unter .NET und App 2 nativ geschrieben wurde.

Zitat:

Wenn du richtig .NET Programmieren willst benutzt man die .NET Klassen und nicht die Borland DLL's

Dann hast du .NET wohl noch nicht verstanden.
.NET heißt nicht: Alles was von Microsoft mit dem .NET Framework ausgeliefert wird, hat alleinigen Anspruch auf das einzig und wahre .NET.
Auch andere Anbieter (und dazu zählt Borland nun mal auch) dürfen Assemblies ausliefern. Die Programme, die diese (deiner Meinung nach) "feindlichen" Assemblies nutzen sind auch richtige .NET Anwendungen.

Und wenn mir jetzt einer damit kommt, dass die VCL.NET (um die es hier übrigens nicht geht) aber nur aus P/Invokes besteht, dem muss ich sagen, dass WinForms auch nur aus lauter P/Invokes besteht. Reflector einfach mal anwerfen. Borland war nur so gnädig und hat im Gegensatz zu Microsoft den Quellcode mit ausgeliefert.

AndyB hat folgendes geschrieben:

Dann hast du .NET wohl noch nicht verstanden. .NET heißt nicht: Alles was von Microsoft mit dem .NET Framework ausgeliefert wird, hat alleinigen Anspruch auf das einzig und wahre .NET. Auch andere Anbieter (und dazu zählt Borland nun mal auch) dürfen Assemblies ausliefern. Die Programme, die diese (deiner Meinung nach) "feindlichen" Assemblies nutzen sind auch richtige .NET Anwendungen. Und wenn mir jetzt einer damit kommt, dass die VCL.NET (um die es hier übrigens nicht geht) aber nur aus P/Invokes besteht, dem muss ich sagen, dass WinForms auch nur aus lauter P/Invokes besteht. Reflector einfach mal anwerfen. Borland war nur so gnädig und hat im Gegensatz zu Microsoft den Quellcode mit ausgeliefert.

Ich sagte es auch nicht, aber die VCL benutzt soweit ich weiss immer noch soviel WinAPI & Co, das dies definitiv sinnlos ist .NET zu benutzen!
Borland kann soviele Assemblys machen wie sie wollen, ich mache ja auch selber welche, aber der größte Teil der Assemblys von Borland ist nutzlos, da man das Entsprechende Gegenstück( Was meist auch schneller/sicherer ist ) in dem normalen .NET findet!
Microsofts Quellcode ist zum großen Teil OS, guck mal auf msdn!


Das Argument das du sagst "Ich will eine Unit in 2 Projekten benutzen", ist im Moment durchaus berechtigt, aber das wird sich mit der Zeit ändern!

*Kann sein das Teilweisse Müll dasteht, aber hatte einen Anstrengenden Tag hinter mir( 12 Stunden Auto fahren!! )*

Hallo Andreas,
Erstmal möchte ich mich von der etwas von unserem Speedy distanzieren.
Einen Debugger in eine .Net-Anwendung zu klinken dauert in D2005 "Jahrhunderte", genau wie es "Jahrhunderte" im VS oder Corsavy dauert.
#d in der Version 1.X[meta]welche Speedmaster wohl verwendet[/meta] hat keinen Debugger. Da sämtliche Bibliotheken durch #d selbst schon geladen sind[meta]ist ja auch eine .Net App[/meta], macht es kurz *plopp* und die App läuft.

AndyB hat folgendes geschrieben:

Bei Chrome scheitert das Code-Sharing bereits am neuen Schlüsselwort method, dass es in Delphi nicht gibt und man entweder alles IFDEF'ed oder gleich eine neue Unit aufmacht. Dann hat man aber den Code zweimal und Bugs müssen zweimal ausgebessert werden, sofern man beide (.NET und Nativ) gleichzeitig unterstützen will.

Chrome besitzt "legacy" switches, die dich method, procedure und function gleichwertig verwenden lassen[meta]procedure bzw. function nur bei einem/keinen result[/meta].
Außerdem kann man with-Blöcke ohne Variable, globals und class method-ähnliche Konstruktoren aktivieren.
Aaaber, die Sprache ist so anders, dass man nur bei kümmerlichen Mini-Beispielen ohne 1.000 IFDEFs auskommen würde.
Ich persönlich halte nicht viel von native/managed X-compiling.
Auf beiden Seiten verliert man Handlungsfreiraum und _eigentlich_ bringt das Ganze nur etwas um sich von native zu managed zu bewegen.
D.Net ist IMHO viiieeel zu krass auf diese Kompatibilität ausgerichtet, obwohl das eine

Zitat:

short term solution to a long term non-issue

ist.
Es gibt keinen Compiler switch, der dich vom legacy mode zu einem KickAss sauberen, multipassed-.Net mode führt.
Jede deiner Klassen wird lauter Krempel angehängt bekommen, so dass sie aussieht wie unter Win32.
Ob du es benutzt oder nicht, deine Klassen bekommen: ClassName, ClassInfo, Dispatch, ... aufgezwungen.
Alles witzlos außerhalb von Portierungsbemühungen. GetType().Name ist ClassName. Den Link zur MetaClass willst du doch gar nicht haben, wenn du sie gar nicht nimmst.
Ich nehme sie z.Bsp. fast nur sichtbar innerhalb von Assemblies, aber auch MetaClasses können so geformt sein, dass man sie ohne Krämpfe in C# verwenden und sogar in Ableitungen deklarieren/implementieren kann.

Es gibt nicht einmal ein using Statement: ouch! :autch: try finally für jedes IDisposable...

Das mag sich jetzt schlimm anhören, aber ich war und bin einfach enttäuscht über diese zusammengeflickte Zwischenlösung.
Das hat Delphi in meinen Augen nicht verdient.
.Net war die Chance für ein großes Catchup - nie wieder Header übersetzen müssen, nie wieder hinterhinken...
Momentan hinkt D.Net aber weiter hinterher als es bei Delphi32 je der Fall war.

Normalerweise schreibe ich zu dem Thema nicht was ich denke, aber nun ist's mal wieder raus...

Robert, du glaubst ja wohl nicht ernsthaft, daß jemand versteht, was Du uns damit mitteilen willst ? Die Frage lautet lediglich : "Was sind die Vorteile von .NET ?" Und wer so was liest, der kann nur einen Schluß ziehen : .NET ist einfach nur *mist*e. Was ich allerdings nicht behaupte !! Und was Delphi betrifft : die sind lediglich den einzig machbaren Gang gegangen. Dein Szenario eignet sich nur für völlig neue Programme, eher mickrige Experimental-Programme um M$ einen Bug zu melden. Oder auch größere die aber Jahre Zeit haben, bis sie eingesetzt weren können. Denn selbst M$ hängt bei .NET gewaltig hinterher. Wenn Borland dann noch ein Jahr länger für was sinnvolles braucht, was solls.

Also : wo liegen konkrete Vorteile in einem konkreten Programm und zwar bereits jetzt ? Wie kann ich ein Programm mit sagen wir mal lediglich ca. 5.000 Zeilen darauf umbauen ?

Zitat:

Ich persönlich halte nicht viel von native/managed X-compiling. Auf beiden Seiten verliert man Handlungsfreiraum

Das sehe ich anders. In meinen Core-Units verwende ich eigentlich recht selten Zeiger oder andere "unsafe" Konstrukte. Die Logik braucht sowas nicht. Erst wenn man verbindung zur "Außenwelt" (aka Windows) herstellt, werden ggf. Zeiger benötigt. Aber VCL Units haben nichts in meinen Core-Units zu suchen. Da verwende ich nur die RTL. Und genau diese Core-Units lassen sich mit Delphi.NET recht leicht in ein .NET Assembly packen. So kann ich z.B. die gleiche Datenstruktur in einer nativen Anwendung benutzen und gleichzeitig mit ASP.NET die Daten auf den gleichen weg im Intranet präsentieren und verwalten. Und mit kleinen RTL-Patch laufen diese Delphi.NET ASP.NET Anwendungen auch unter Mono auf einer Linux-Kiste, obwohl SysUtils und Classes benutzt werden.