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

[dragi]

...und ich hab keine Ahnung :)

Hallo Delphi-Community,

ich habe nun zum ersten mal beschlossen mich auch einmal in der Welt ausserhlab Delphis umzusehen und habe mir gedacht ich versuche mal mit Visual C++ ein kleines Programm auf die Kette zu kriegen. Aber irgendwie habe ich da wohl ein ziemliches Verständniss Problem mit der IDE. Gibt es dort keinen Formular Designer??? Ich habe so etwas wie einen ResourceViewer und wenn ich dort auf "Dialog" gehe bekomme ich ein Fenster das man wie in unserem FormularDesigner bearbeiten kann. Das ist aber nur eine "Aboutbox". Kann mir jemand vielleicht nur mal grob erklären wie das in VC++ gedacht ist? Muss ich die Formulare etwa zur Laufzeit erzeugen und auch die Controls?
Auch auf die gefahr hin das ihr denkt ich wäre zu faul zu suchen ich suche nur eine Grobe erklärung damit ich weiss worauf ich mich einstellen muss :)

Vielen Dank

Dragi

[malo]

Hallo dragi,

der Formulardesigner vom VS ist anders als der von D3. Ab D8 wird auch bei Delphi ein ähnlicher Designer verwendet. Ich kann grade leider nicht nachsehen (hab kein Windows hochgefahren, nur Linux), aber das ganze dürfte doch keine Probleme machen... versuch mal unter "Datei"-->"Neu" ein neues Projekt zu erzeugen ;)

[Luckie]

@malo: Du verwechselst da was. Er rede wohl vom Visual Studio in der Version 6 und nicht vom Visual Studio für C#.

@dragi: Es handelt sich dabei um einen reine Ressourceneditor mit dem du unterandem Dialogressourcen erstellen kannst, die du dann in deinem Programm benutzen kannst. Delphi ist eine RAD Entwicklungsumgebung und nicht mit dem VC zu vergleichen, da beide IDEs unterschiedliche Konzepte verfolgen.

Mit dem VC Windows GUI Anwendungen zu erstellen entspricht der nonVCL Programmierung mit Delphi.

[dragi]

Sorry, hatte vergessen zu sagen das ich VS 6.0 meinte!

Hmm, dann wird das wohl ne ziemlich komplizierte Kiste denke ich. Ich habe mir gedacht mit C++ anzufangen da ich gerne unter embedded vc++ 4.0 Anwendungen für meinen Pocket PC schreiben möchte und dort bin ich direkt auf die gleichen probleme gestossen. Deshalb dachte ich mir ich versuchs lieber erst am PC. Aber da es nun hier genauso funktioniert ist das ja echt ne harte Nuss. Ich muss also jedes Control selber erzeugen und insource positionieren? ...oh man, ich liebe Delphi :D

Grüsse eines verwirrten und enttäuschten

Dragi

[jbg]

Zitat:

Zitat von Luckie

Visual Studio

Wofür wohl das "Visual" steht? Visuell ist/war an dem nur der Editor.

Zitat:

Windows GUI Anwendungen zu erstellen entspricht der nonVCL Programmierung mit Delphi.

Na klar erstellt man mit VS nonVCL Programme, denn unter VS gibt es keine VCL. Das Wort nonVCL funktioniert somit nur bei Delphi und beim C++Builder. Damit ist aber in der Regel die direkte WinAPI Programmierung gemeint. Und die muss man bei VS nun nicht wirklich einsetzen. Dafür gibt es die allerseits hochgepriesene, fantastisch designte, alles andere übertreffende MFC. :lol:

[Luckie]

Zitat:

Zitat von jbg

Zitat:

Windows GUI Anwendungen zu erstellen entspricht der nonVCL Programmierung mit Delphi.

Na klar erstellt man mit VS nonVCL Programme, denn unter VS gibt es keine VCL. Das Wort nonVCL funktioniert somit nur bei Delphi und beim C++Builder.

Du kennst die Bedeutung des deutschen Wortes 'entspricht'? Wohl eher nicht.

Zitat:

Dafür gibt es die allerseits hochgepriesene, fantastisch designte, alles andere übertreffende MFC. :lol:

Aber auch mit der MFC wirst du nicht umhinkommen den Ressourceneditor zu benutzen, um deine Dialogressourcen zu erstellen.

PS: Deinen Aussagen entnehme ich, dass du noch nie wirklich mit dem VC und / oder der MFC gearbeitet hast.

[Speedmaster]

Ich empfehle dir mal mit D2k5PE zu arbeiten, dort gibts C# und einen Formulardesigner!

[nailor]

Zitat:

Zitat von Luckie

Mit dem VC Windows GUI Anwendungen zu erstellen entspricht der nonVCL Programmierung mit Delphi.

auf gut deutsch heißt das, dass du wie befürchtet deine controls zur laufzeit selberbasteln.

und nochwas: c# und c++ sind nicht das gleiche. c# ist mehr delphi als c++ (behaupte ich jetzt einfach mal so).

[Speedmaster]

Zitat:

Zitat von nailor

c# und c++ sind nicht das gleiche. c# ist mehr delphi als c++ (behaupte ich jetzt einfach mal so).

Das halte ich für ein gerücht! Ich arbeite mich trotz das ich ein C# Gegner bin eben in C# ein, und es ist definitiv nicht dasselbe, wobei ich inzwischen der Meinung C# und Delphi haben beide ihre Vorteile.

Aaabber... C# ist vom Syntax definitiv nicht Delphi ähnlicher wie C++, ich kenne C++ aus Übersetzungsgründen!

[Luckie]

Nein das heißt es eben nicht. Du erstellst dir dein fenster als Ressource und diese kannst du dann in deinem Programm benutzen. Ich glaube, hier wissen einige nicht, was eine (Dialog)ressource ist und wie man damit umgeht. Ein Beispiel für Delphi ist in meinen Win32 API Tutorials für Delphi enthalten.

Zitat:

C# ist vom Syntax definitiv nicht Delphi ähnlicher

Es ging ihm wohl weniger um die Syntax, asl um das allgemeine Konzept. Das C# und Delphi von der Syntax nicht identisch sind, dürfte klar sein.

[Speedmaster]

Zitat:

Zitat von Luckie

Nein das heißt es eben nicht. Du erstellst dir dein fenster als Ressource und diese kannst du dann in deinem Programm benutzen. Ich glaube, hier wissen einige nicht, was eine (Dialog)ressource ist und wie man damit umgeht. Ein Beispiel für Delphi ist in meinen Win32 API Tutorials für Delphi enthalten.

Zitat:

C# ist vom Syntax definitiv nicht Delphi ähnlicher

Es ging ihm wohl weniger um die Syntax, asl um das allgemeine Konzept. Das C# und Delphi von der Syntax nicht identisch sind, dürfte klar sein.

Die Ähnlichkeit beruht allein auf .NET , sonst wäre diese "Verbindung" wohl nicht da!

[Robert_G]

Zitat:

Zitat von Luckie

PS: Deinen Aussagen entnehme ich, dass du noch nie wirklich mit dem VC und / oder der MFC gearbeitet hast.

Ich glaube er hat schon einiges mit VC++ gebaut. ;)

@Speedmaster & nailor
Es hat nur sehr wenig mit C++ gemein.
C# kann man als ein Java ansehen, das mit ein paar, aus Delphi bekannten, Features[1] aufgebohrt wurde. ;)

@Dragi
Ich glaube GUIs taugen nicht viel zum Kennenlernen von C++. ;)
Managed C++ bringt auch einen Designer mit.
Welch' Überraschung: Es ist der gleiche aus C#, Chrome, Delphi, Component Pascal, VB.Net, Eifel,... :mrgreen:
Aber managed C++ ist irgendwie ... witzlos ... :gruebel:

C# ist eine wirklich feine Sprache, wenn man in den c-like Sprachen tigern oder einfach .Net lernen will.
Außerdem ist es eine der beiden (IMHO) einzigen wirklichen .Net-Sprachen[2], die es momentan gibt. ;)
Wenn es dir zu "flach" ist kannst du ja immer noch Handles jonglieren gehen. :mrgreen:

[1] welche von der CLR selbst kommen
[2] also Sprachen ohne Legacy-Einschränkungen, wie VB, Delphi.Net, C++, Cobol (<- :lol: )

[jbg]

Zitat:

Zitat von Luckie

Du kennst die Bedeutung des deutschen Wortes 'entspricht'? Wohl eher nicht.

Soll ich jetzt einen Duden holen oder doch ein Fremdwörterbuch? Hätte ich nur im Deutschunterricht besser aufgepasst.
Trotzdem. Es bleibt ein etwas schlechter Vergleich, denn nonVCL (auch wenn du? das als direkte Win32API Programmierung geprägt hast) heißt für mich "ohne VCL". Und das bedeutet (für mich und meine schlechten Deutschkenntnisse), dass ich auch KOL oder sogar wxWidgets oder Qt einsetzen kann und unter nonVCL laufe.

Zitat:

Aber auch mit der MFC wirst du nicht umhinkommen den Ressourceneditor zu benutzen, um deine Dialogressourcen zu erstellen.

Man muss ja keine Dialogressource erstellen, das geht auch mit fleißig Tippen.

Zitat:

PS: Deinen Aussagen entnehme ich, dass du noch nie wirklich mit dem VC und / oder der MFC gearbeitet hast.

Was du da alles herauszulesen vermagst. Hast du denn schon mal ein MFC Programm geschrieben? Die MFC ist mit der OWL zu vergleichen, eine Kapselung der WinAPI. Aber ich gebe zu, dass ich mehr mit Qt arbeite als mit der MFC.

[Bernhard Geyer]

Zitat:

Zitat von dragi

ich habe nun zum ersten mal beschlossen mich auch einmal in der Welt ausserhlab Delphis umzusehen und habe mir gedacht ich versuche mal mit Visual C++

Muss es unbedingt "Visual" C++ sein? Wenn schon "fremdgehen" dann mit einer Java-IDE oder mit einer IDE für C#.
Ich mußte mich einige Jahre mit Visual C++ und der MFC herumärgern und für GUI-Entwicklung ist es 'ne Katastrophe. Spar dir lieber den Grips und lern eine modernere Klassenbibliothek.

[Luckie]

@jbg: Jupp, ich habe schon mit dem VC gearbeitet mit und ohne MFC. Ohne MFC ist es eben wie WinAPI Programmierung unter Delphi ohne VCL (Um mal den Begriff nonVCL mal zu umgehen, an dem du dich wohl etwas störst.) und mit MFC ist es einfach nur Krampf, finde ich.
Ich möchte mich auch noch mal entschuldigen bei dir für meine unbegründete Unterstellung, war ein unüberlegter Schnellschuss von mir. Sorry. :cheers:

[dragi]

@All

Danke für die Antworten. Ich denke mal ich habs einigermassen verstanden. Wenn ich mich nun wirklich dahingehend beschäftigen will Programme mit embedded vc++ zu schreiben muss ich mich mit dem ResourcenDingsda auseinandersetzen oder alles während der Laufzeit generieren.

Vielen Dank an euch!

Dragi

[Robert_G]

Es gibt auch ein CompactFramework. :zwinker:

[dragi]

Welches aber meines Wissens nicht mit der embedded vc++ IDE zusammenarbeitet die ich nutzen möchte da diese kostenlos ist. Sonst würde ich das ganze in einem aktuellen Visual Studio und c# machen :)

[Olli]

Zitat:

Zitat von Luckie

Mit dem VC Windows GUI Anwendungen zu erstellen entspricht der nonVCL Programmierung mit Delphi.

Quatsch. Man kann sehr gut mit der MFC *und* Dialogen arbeiten. Was daran ähnlich mit nonVCL sein soll?! :gruebel:

[Luckie]

Kommt man, wenn man in der Ressource im VC auf einen Button dopplet klick in die Ereigmis behandlucgsroutzine im Codeeditor? :gruebel:

[bigg]

Ist VC++ mit MFC nicht gleich C++ und ohne MFC gleich C :gruebel:
PS: Delphi und Visual C++ unterscheiden sich doch kaum.

Ich hab hier noch ein Tut
rumliegen "Wer C sagt, muß auch PlusPlus sagen!"

[Olli]

Zitat:

Zitat von Luckie

Kommt man, wenn man in der Ressource im VC auf einen Button dopplet klick in die Ereigmis behandlucgsroutzine im Codeeditor? :gruebel:

Nein, nicht in den Code-Editor aber in den Class-Wizard. Da du es doch angeblich hast mußt du es doch nur testen.
Oder willst du behaupten, daß man, wenn es nicht *ohne Umweg* geht, von einer Ähnlichkeit zu nonVCL ausgehen muß?

[Luckie]

OK, hast mich überzeugt. ;)

[alcaeus]

Zitat:

Zitat von bigg

Ist VC++ mit MFC nicht gleich C++ und ohne MFC gleich C :gruebel:

Schwachfug. C++ und C sind zwei verschiedene Sprachen, die man nicht mischen sollte. Nimm mal einen reinen C-Compiler (also einen der kein C++ kann) und versuch mal das:

Code:

cout << "foo";

Wird nicht klappen, da cout und cin eben C++-Methoden sind, und nicht C. Das waere der erste Unterschied. Weitere Referenzen gibts bei Ihrem C-Compiler per try'n'error :stupid:

Greetz
alcaeus

[bigg]

Zitat:

Schwachfug. C++ und C sind zwei verschiedene Sprachen, die man nicht mischen sollte. Nimm mal einen reinen C-Compiler (also einen der kein C++ kann) und versuch mal das:

Ich weiss es nicht, darum frage ich ja, außerdem bezog sich meiner behauptung nur auf Visual Studio bzw. dem Visual C++ Kompiler von Microsoft.

[Olli]

Zitat:

Zitat von bigg

Ich weiss es nicht, darum frage ich ja, außerdem bezog sich meiner behauptung nur auf Visual Studio bzw. dem Visual C++ Kompiler von Microsoft.

Alci hat ganz recht. C ist keine HLL, C++ schon. Da hätten wir also den ersten Unterschied. C++ folgt OOP, C nicht. C++ kennt Templateklassen und -funktionen, C nicht.

Wenn du C++ lernen willst, mache dich mit der Syntax vertraut, lies dir die C++-FAQ (Lite) durch und lerne daraus. Danach ein paar kleine Projekte und voila ...

[bigg]

C kennt keine Funktionen? :shock: :lol:
Vielleicht werde ich mich doch mal damit beschäftigen, kann ja nicht schaden. :mrgreen:

[Olli]

Zitat:

Zitat von bigg

C kennt keine Funktionen? :shock: :lol:

Templatefunktionen. Wer lesen kann ist klar im Vorteil ;)

[bigg]

In meinem eBook steht aber etwas anderes :?
Schau selbst..

Ach Template-Funktionen :oops:
*was ist das nun wieder* :lol:

sorry, war ein langer tag heute :oops:

[Olli]

Zitat:

Zitat von bigg

Ach Template-Funktionen :oops:
*was ist das nun wieder* :lol:

Sowas wie Templateklassen, nur für Funktionen. Beispiel:

Code:

template <typename T>
T minimum(T value1, T value2)
{
  return (value1 < value2) ? value1 : value2;
}

Dank minimum<double>, minimum<int>, minimum<unsigned> usw. kannst du diese Funktion für verschiedene Typen "instantieren".

Statt "template <typename T>" heißt es manchmal auch "template <class T>". Beide sind gleichwertig in diesem Kontext.

[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 ....