proggen.org

Da mein Compiler nun auch wieder unter MacOS läuft (64Bit), habe ich die geänderte Version erstmal wieder Linux (32 Bit) zu fressen gegeben. Nachdem der halbwegs aktuelle GCC (4.3.2 Linux, 4.0 Mac) auch wieder einige Dinge bemängelt hat, bin ich zurück zu Windows.

Spaßeshalber habe ich unter Linux mal die Zeit mit 'time', die ein make rebuild erfordert: 37,xx Sekunden. Früher waren es mal 34 Sekunden, also wieder 3 Sekunden Code hinzugefügt - was immer das zu bedeuten hat. Egal. ^^
Zurück zu Windows 7 (32 Bit) und Visual Studio Express: Projekt neu erstellen. Das erforderte gefühlt dann doch etwas Geduld.... Auf gefühlt gibt man ja nix, also Stoppuhr raus: 1:10.

Wieso braucht der Visual Studio Compiler (ohne Optimierung) doppelt solange wie der GCC!?

Wieso braucht der Visual Studio Compiler (ohne Optimierung) doppelt solange wie der GCC!?

Wenn du das ganze als Debug kompilierst, muss der VCC das ganze Debug-bremoborium erstellen, das kostet natürlich Zeit.
VS ist normalerweise auf Debug eingestellt, gcc nicht.

cloidnerux hat geschrieben:

Wieso braucht der Visual Studio Compiler (ohne Optimierung) doppelt solange wie der GCC!?

Wenn du das ganze als Debug kompilierst, muss der VCC das ganze Debug-bremoborium erstellen, das kostet natürlich Zeit.
VS ist normalerweise auf Debug eingestellt, gcc nicht.

Da von meinem Compiler noch keine Release-Version zu erwarten ist - das Ding wird seit jeher als Version 0.01 kompiliert, obwohl ich schon seit 2 Jahren überlege, ob ich mich auf 0.02 verbessern soll - kompiliert mein make-Skript ebenfalls grundsätzlich als Debug-Version. ^^

hm... ganz ehrlich: wenn du Programme für Mac, Windows und Linux erstellen willst, dann schmeiß VC++ zum Fenster raus... weil unter Linux gehen die Programme der neuen Versionen durch .net auf keinen Fall, noch net mal mit Wine...
Ich benutze grundsätzlich nur GCC (bzw. MinGW unter Windows) und die Geschwingigkeit ist mir relativ egal... ob ich nu ne Sekunde warte oder 2 ist mir wurscht. Zumal ich ein Programm meistens von grund auf selbst schreibe (also immer wieder Code hinzufüge) und so kompiliere ich alles von Anfang an, so spare ich dann hinten raus zeit... zumindest kommt es mir so vor... ^^.

VC++ hab ich nie probiert, weil der relativ unverträglich zum GCC ist... VC++ ist doch ein ganz eigener Dialekt zu C++. Oder bin ich da falsch informiert?

naums hat geschrieben:VC++ hab ich nie probiert, weil der relativ unverträglich zum GCC ist... VC++ ist doch ein ganz eigener Dialekt zu C++. Oder bin ich da falsch informiert?

Mein Compiler sind etliche hundert Klassen und kompiliert unter VC++ 2008 Express wie GCC ohne Änderungen.

VC++ hab ich nie probiert, weil der relativ unverträglich zum GCC ist... VC++ ist doch ein ganz eigener Dialekt zu C++. Oder bin ich da falsch informiert?

Nein, Visual Studio unterstützt C++, hat also einen C++ Compiler, C++ ist durch die ISO/IEC C++ definiert, also muss ein C++ Compiler diesen Standard unterstützen. Aber, Microsoft hat ein paar Zusätze eingebaut, z.B #prgama. Das ändert aber nichts am Quellcode, sondern Resultiert nur in einige seltsame Fehlermeldungen, wie bereits häufiger erwähnt.
Aber Mcirosoft hat für sein .NET-Framework eine C++ Abstraktion geschaffen, damit die, die nicht von C++ loslassen wollen, aber die vorzüge von .NET haben wollen, das auch nutzen können.

naums hat geschrieben:hm... ganz ehrlich: wenn du Programme für Mac, Windows und Linux erstellen willst, dann schmeiß VC++ zum Fenster raus...

Ich achte darauf das meine Programme auf allen halbwegs standardkonformen Compileren funktionieren. Der VC++ hat zwar teilweise komische Dinge die er durchgehen lässt und unterstützt manches nicht, aber der Großteil des C++-Standards wird doch unterstützt. Plattformabhängigkeit heißt für mich auch Compilerunabhängigkeit. Ich möcht niemanden in der Wahl seines Lieblingscompilers einschränken... (Zumindest solange es für mich mit ein halbwegs erträglichen Aufwand realisierbar ist )

naums hat geschrieben:[...]und die Geschwingigkeit ist mir relativ egal... ob ich nu ne Sekunde warte oder 2 ist mir wurscht.

Sag das nicht. Mein Spiel mitsamt der Engine kompiliert unter Vollauslastung meines Quadcores in ca. 30 Sekunden, und das obwohl das ganze noch nicht einmal allzu aufwendig ist.

Kerli hat geschrieben:Der VC++ hat zwar teilweise komische Dinge die er durchgehen lässt und unterstützt manches nicht, aber der Großteil des C++-Standards wird doch unterstützt.

Um mal eine Lanze für den VC zu brechen - ich habe meinen Code für den VC geändert und er meckerte diverse Dinge an, die dazu führten, dass ich noch einen Bug gefunden hat. Dies hat der GCC durchgehen lassen (das Programm stürzte aber unter Linux auch nicht ab).

Kerli hat geschrieben:Sag das nicht. Mein Spiel mitsamt der Engine kompiliert unter Vollauslastung meines Quadcores in ca. 30 Sekunden, und das obwohl das ganze noch nicht einmal allzu aufwendig ist.

Was kompilierst Du denn alles dazu?
Und wieso hast Du einen Quad, wenn ich als Informatiker hier immernoch auf einem Single Core hantiere?

Kerli hat geschrieben:Sag das nicht. Mein Spiel mitsamt der Engine kompiliert unter Vollauslastung meines Quadcores in ca. 30 Sekunden, und das obwohl das ganze noch nicht einmal allzu aufwendig ist.

Wtf? Bist du dir sicher, dass der Quadcore auch ausgelastet wird (make -j5) ?
Also auf meinem Laptop mit Dual Core hier kompiliert der Linux Kernel (zwar recht minimal, aber eben doch alles drin, was ich brauch) in ca 3-4 Minuten ... das bringt mich zur Frage, wie groß verdammt noch mal dein Spiel mit Engine ist?

Xin hat geschrieben: Was kompilierst Du denn alles dazu?

Die Engine mit meinen eigenen Bibliotheken (Logengine, XML-Parser) und dann ein Demospiel. Für genaue Größen einfach nach unten schauen

Xin hat geschrieben:Und wieso hast Du einen Quad, wenn ich als Informatiker hier immernoch auf einem Single Core hantiere?

Ich bin eben Softwareentwickler Und außerdem hab ich ihn mir gekauft

Dirty Oerti hat geschrieben:Wtf? Bist du dir sicher, dass der Quadcore auch ausgelastet wird (make -j5) ?

Ja, es sind zwar nicht gannz 30 Sekunden, aber laut 'time' immerhin 26

Dirty Oerti hat geschrieben:das bringt mich zur Frage, wie groß verdammt noch mal dein Spiel mit Engine ist?

sloccount hat geschrieben:SLOC Directory SLOC-by-Language (Sorted)
5945 gewoopi cpp=5794,ansic=112,xml=39
1098 xml-sipa cpp=1091,xml=7
933 open-log-generator cpp=611,ansic=322
381 tp-tree cpp=381


Totals grouped by language (dominant language first):
cpp: 7877 (94.26%)
ansic: 434 (5.19%)
xml: 46 (0.55%)

Wenn es wer selber ausprobieren möchte; der gesamte Code ist auch auf Launchpad erhältlich...