Delphigeschädigter Möchtegerncoder alleine mit VC++...

[Robert_G]

Das heißt zwar in .Net nun generics anstatt Templates, aber es ist ungemein zeitsparend. :)

Code:

public class Miep<T> 
    where T : IComparable
{
    T value;

    public T Value
    {
        get{return this.value;}
        set{this.value = value;}
    }

    public static bool operator <(Miep<T> left, Miep<T> right)
    {
        return left.Value.CompareTo(right.Value) < 0;
    }

    public static bool operator >(Miep<T> left, Miep<T> right)
    {
        return left.Value.CompareTo(right.Value) > 0;
    }
}

Delphi-Quellcode:

type
   Miep<T> = public class 
      where T is IComparable;
   public
      property Value : T;
      class operator Less(left, right: Miep<T>) : boolean;
      class operator Greater(left, right: Miep<T>) : boolean;
  end;
  
implementation

class operator Miep<T>.Less(left: Miep<T>; right: Miep<T>) : boolean; 
begin
   exit (left.Value.CompareTo(right.Value) < 0);
end;

class operator Miep<T>.Greater(left, right: Miep<T>) : boolean; 
begin
   exit (left.Value.CompareTo(right.Value) > 0);
end;

[shmia]

Zitat:

Zitat von Robert_G

....
C# kann man als ein Java ansehen, das mit ein paar, aus Delphi bekannten, Features[1] aufgebohrt wurde. ;)

C# ist eine wirklich feine Sprache, wenn man .....

Stimmt genau.
Der Grund dafür ist, das ein hochrangiger Entwickler von Borland Delphi (habe leider den Namen nicht parat)
zu Microsoft :evil: gewechselt hat und dort C# massgeblich mitentwickelt hat.

C# benötigt z.B. keinerlei Forward-Deklarationen mehr.
Man kann sich also in Klasse A schon auf Klasse B beziehen, obwohl Klasse B erst viel später definiert wird.
Entscheidend ist das Unit-Konzept; es gibt also keine Headerfiles wie bei C++ mehr, sondern es ist alles in einer Unit (Datei).
Die compilierten Unit enthalten eine Symboltabelle mit allen Infos, die andere Units benötigen.
Das ist ein Hauptgrund, warum Delphi so schnell compiliert und dies trifft auch bei C# zu.

Ausserdem enthalten Delphi und C# ein automatisches Make-Tool ( http://de.wikipedia.org/wiki/Make );
es wird kein make-file mehr benötigt, sondern der Compiler erkennt welche Abhängigkeiten bestehen und was compiliert werden muss.

[Olli]

Zitat:

Zitat von shmia

Der Grund dafür ist, das ein hochrangiger Entwickler von Borland Delphi (habe leider den Namen nicht parat)
zu Microsoft :evil: gewechselt hat und dort C# massgeblich mitentwickelt hat.

Hast du was gegen die völlig legitime Entscheidung dieser Person zu einem Wechsel? Klingt irgendwie so.

Zitat:

Zitat von shmia

Das ist ein Hauptgrund, warum Delphi so schnell compiliert und dies trifft auch bei C# zu.

Quark. Der Hauptgrund warum Delphi so schnell kompiliert ist, daß Delphi ein Single-Pass-Compiler ist/hat und daß bei Delphi das Gros der Units bereits vorkompiliert (also im object code) vorliegt. Units müssen also größtenteils nur eingelinkt aber nicht kompiliert werden.

[shmia]

Zitat:

Zitat von Olli

Zitat:

Zitat von shmia

Der Grund dafür ist, das ein hochrangiger Entwickler von Borland Delphi (habe leider den Namen nicht parat)
zu Microsoft :evil: gewechselt hat und dort C# massgeblich mitentwickelt hat.

Hast du was gegen die völlig legitime Entscheidung dieser Person zu einem Wechsel? Klingt irgendwie so.

Als Delphi-Fan sehe ich das natürlich negativ, wenn Borland Entwickler zur ohnehin übermächtigen Konkurrenz wechseln.

Zitat:

Zitat von Olli

Zitat:

Zitat von shmia

Das ist ein Hauptgrund, warum Delphi so schnell compiliert und dies trifft auch bei C# zu.

Quark. Der Hauptgrund warum Delphi so schnell kompiliert ist, daß Delphi ein Single-Pass-Compiler ist/hat und daß bei Delphi das Gros der Units bereits vorkompiliert (also im object code) vorliegt. Units müssen also größtenteils nur eingelinkt aber nicht kompiliert werden.

Das ist das, was ich mit dem automatischen Make-Tool sagen wollte: es wird nur das compiliert, was unbedingt nötig ist.

Ich habe behauptet, Delphi legt seine internen Symboltabellen im Objektcode ab.
Der Compiler prüft zuerst, ob die DCU-Datei neuer als die PAS-Datei ist.
Falls ja, wird die PAS-Datei gar nicht angeschaut, sondern die Symboltabelle aus der DCU-Datei extrahiert.
Das ist ein entscheidender Geschwindigkeitsvorteil!
Beweiss: wenn man Delphi nur eine DCU-Datei vorsetzt, aber die PAS-Datei vorenthält, kann der Compiler
dennoch arbeiten, weil er einfach die Symboltabellen aus der DCU extrahiert.
Eine DCU-Datei ist demnach = compilierter Code + Linkersymbole + interne Symboltabelle

[Olli]

Zitat:

Zitat von shmia

Das ist ein entscheidender Geschwindigkeitsvorteil!

Stimmt. Hast du aber bei anderen Sprachen (zB VC++) auch. Dort werden die OBJ-Dateien nicht nochmal kompiliert, wenn die eigentlichen Module (und Header) nicht verändert wurden. Der eigentliche zeitliche Vorteil entsteht durch Single-Pass- gegenüber Multi-Pass-Compiler.

Zitat:

Zitat von shmia

Beweiss: wenn man Delphi nur eine DCU-Datei vorsetzt, aber die PAS-Datei vorenthält, kann der Compiler
dennoch arbeiten, weil er einfach die Symboltabellen aus der DCU extrahiert.
Eine DCU-Datei ist demnach = compilierter Code + Linkersymbole + interne Symboltabelle

Das wäre dann der Linker, nicht der Compiler ;) ... auch wenn die unter Delphi nicht so strikt getrennt sind. Gleiches gilt im Übrigen auch für C/C++-Linker, denen du ja auch nur OBJ-Files vorsetzt - der arbeitet auch ohne C/CPP-Dateien ;).

Ich hoffe du verstehst den kleinen aber feinen Unterschied ...

[Robert_G]

Zitat:

Der Grund dafür ist, das ein hochrangiger Entwickler von Borland Delphi (habe leider den Namen nicht parat)
zu Microsoft :evil: gewechselt hat und dort C# massgeblich mitentwickelt hat.

<edit>Anders Hejlsberg. Der hatte schon den Pascal Compiler bevor er zu Borland kam. (Für irgendsoein proprietäres System damals...)
Er war nicht nur irgendein hochrangiger Entwickler bei Borland. Ohne ihn wäre Delphi nie gewesen (er kam ja mit dem ganzen Pascal Kram zu Borland) bzw. nicht das was du heute kennst.</edit>
Die meisten Features gewinnt C# aber alleine durch .Net. Es ist sozusagen nur ein dünner Layer über der CLR.

Was .Net nicht direkt kann, kann auch C# nicht, selbst wenn es mit nur minimalen Extraklassen/Extracode kompilierbar wäre.
C# ist eine feine Sprache, aber nicht das Maß der Dinge. ;)
(verglichen zu der in meiner sig ist es aber alles andere als überlegen, IMHO :zwinker: )

Zitat:

C# benötigt z.B. keinerlei Forward-Deklarationen mehr.

Das gilt für fast alle .Net Sprachen. (bis auf unbedeutende Ausnahmen, welche wohl deshalb unbedeutend sind)
Ich für meinen Teil fasse so schnell beruflich keinen Single pass compiler mehr an. Ist einfach zu nervig und die resultierenden Friemeleien kosten IMHO zu viel Zeit.

Zitat:

Man kann sich also in Klasse A schon auf Klasse B beziehen, obwohl Klasse B erst viel später definiert wird.
Entscheidend ist das Unit-Konzept; es gibt also keine Headerfiles wie bei C++ mehr, sondern es ist alles in einer Unit (Datei).

Das ist so nicht richtig.
In C#, Chrome, VB.Net, Eifel,... muss man sich überhaupt nicht mehr mit irgendwelchen Dateien bzw. Dateinamen rumärgern.
Du musst nur die Dateien dem Compiler bekannt machen (also in deinem Projekt haben), schon kann man mit den enthalten Klassen arbeiten, welche man von überall (also in jeder Datei) in jeder Reihenfolge verwenden kannst.

Zitat:

Die compilierten Unit enthalten eine Symboltabelle mit allen Infos, die andere Units benötigen.
Das ist ein Hauptgrund, warum Delphi so schnell compiliert und dies trifft auch bei C# zu.

C# kompiliert nicht sonderlich schnell. Und es wird ganz sicher keine temporären Zwischenprodukte (also keine DCU-Gegenstücke) rumliegen lassen, bzw. überhaupt verwenden.
In der Kompiliergeschwindigkeit liegt ein Vorteil von single pass compilern, aber der ist doch in Wirklichkeit ziemlich uninteressant...
Falls du damit Assemblies meintest: Die sind ziemlich ähnlich zu den Packages in good old Delphi32. ;)

Zitat:

Ausserdem enthalten Delphi und C# ein automatisches Make-Tool ( http://de.wikipedia.org/wiki/Make );
es wird kein make-file mehr benötigt, sondern der Compiler erkennt welche Abhängigkeiten bestehen und was compiliert werden muss.

Das ist auch normal für fast alle .Net-sprachen.

[jbg]

Zitat:

Zitat von Olli

Der eigentliche zeitliche Vorteil entsteht durch Single-Pass- gegenüber Multi-Pass-Compiler.

Das mag ein Grund sein, aber bei C++ müssen für jede .cpp/.cc Datei jedesmal alle eingebundenen Header durchlaufen werden. Deswegen wurden vorkompilierte Header eingeführt, die aber dank der Makros nicht immer benutzt werden können, weil die Header je nach definiertem Makro mal dies und mal das enthalten können. Und diese vielen Headerdateien fehlen nun mal bei Delphi bzw. sind als Interface-Abschnitt bereits in den .dcu Dateien enthalten.
C++ und Pascal unterscheiden sich eben im Dateiverwaltungspunkt recht stark und darin liegt auch eine Menge an verlorener bzw. gewonnener Kompiliergeschwindigkeit.


C# kann vorkompilieren? Also ich habe vom C# Compiler noch nie eine .obj/.o Datei erhalten. Der meckert da nämlich immer, dass er kein main() gefunden hat. Das einzige was man da als vorkompilieren bezeichnen kann, sind Assemblies, aber die sindd wiederum bereits erstellte Projekte (DLLs).
Warum der C#-Compiler bei größeren Programmen schneller ist als der C++-Compiler liegt wohl daran, dass er nicht zig Millionen Zeilen Header einlesen und verarbeiten muss. (Schon mal Qt 4 kompiliert mir MSVC?)

[Olli]

Zitat:

Zitat von jbg

Das mag ein Grund sein, aber bei C++ müssen für jede .cpp/.cc Datei jedesmal alle eingebundenen Header durchlaufen werden.

Stimmt! Erstmal Präprozessor, dann für jedes Modul den Header usw ... grausam ;) ... übrigens beschreibst du damit eine Charakteristik eines Multi-Pass-Compilers :zwinker:

[sniper_w]

Zitat:

Quark. Der Hauptgrund warum Delphi so schnell kompiliert ist, daß Delphi ein Single-Pass-Compiler ist/hat und daß bei Delphi das Gros der Units bereits vorkompiliert (also im object code) vorliegt. Units müssen also größtenteils nur eingelinkt aber nicht kompiliert werden.

Und warum ist delphi immer noch so schneller als VS wenn man das ganze Projekt "builden" lässt? Habe gerade Quake 2 in delphi, der braucht nicht einmal 1 sekunde, in VS...na ja...

[Olli]

Zitat:

Zitat von sniper_w

Und warum ist delphi immer noch so schneller als VS wenn man das ganze Projekt "builden" lässt? Habe gerade Quake 2 in delphi, der braucht nicht einmal 1 sekunde, in VS...na ja...

Weil eben doch nicht alles neu kompiliert wird! Die DCUs sind der Trick. Wurde oben ja schon besprochen ....