Wie lang kompiliert (und linkt) ihr?

ach, son swt gedöns kann schonmal richtig lange dauern. also 10 minuten ^^

x schrieb:

mal ne andere Frage, wie ist denn hier die Einheit loc definiert? Wirklich "lines of code" oder sind hier auch die leeren Zeilen und die ganzen File-Headers mit modification history mit dabei...

ich hab' so ein tool ausm internet verwendet. das hat nur code in c-files und aus den headern makros gezählt, die code erzeugen könnten. also keine kommentare, leerzeilen, prototypen und dergleichen. aber stimmt schon, was loc bedeutet, ist nirgends allgemeingültig definiert.

hustbaer

Optimizer schrieb:

Das trifft's imho noch nicht ganz. Das Grund ist imho, parsen des Templates -> vector<int> erstellen -> compilieren, parsen des Templates -> vector<float> erstellen -> compilieren, parsen des Templates -> ...

Lass mich kurz nachdenken, welchen immer gleichen Schritt könnte man sich mit einem besseren Übersetzungsmodell sparen? Das geparste Template kann höchstens innerhalb einer Übersetzungseinheit weiterverwendet werden, von tausend, also fast gar nicht. Dad heißt, die Arbeit wird sogar für die gleichen Instanzierungen ständig wiederholt. Wenn das mal keine Unzulänglichkeit im Übersetzungsmodell ist, dann weiß ich's nicht.

Nope. Solche Templates wie std::vector tun nicht wirklich weh.
Weh tun die Teile wo durch Template-Metaprogrammierung tonnenweise Templateklassen instanziert werden, und das für ein oder zwei Zeilen harmlos aussehendem Programmcode.
Die Regeln bezüglich overload resolution oder auch Regeln wir SFINAE helfen auch nicht gerade die Compilezeiten niedrig zu halten.

Was das Parsen angeht: schonmal von precompiled headers gehört? Funktioniert wunderschön, und hilft das ganze zigfache Parsen zu vermeiden. Bringt bei echten Template-Schlachten aber auch nicht viel, weil das Parsen eben nicht der Teil ist wo wirklich viel Zeit draufgeht. Nicht vergessen: C++ templates sind Turing complete.

Und dann kommt natürlich noch die Zeit dazu die der Optimizer braucht, und das kann auch einiges sein. Ok, hier widerspreche ich mir gerade selbst... aber wenns so is... was soll ich machen
BTW: dass der Optimizer in vielen Programmen SO viel zu tun hat liegt auch oft am "gnadenlosen" Einsatz von Templates. Guck dir mal die Implementierung von Boost.Bind, Boost.Function oder Boost.Lambda an. Huiuiuiui....

p.S.: unterhaltsam ... für die die es noch nicht kennen: http://ubiety.uwaterloo.ca/~tveldhui/papers/2003/turing.pdf

Don06

hustbaer schrieb:

Guck dir mal die Implementierung von Boost.Bind, Boost.Function oder Boost.Lambda an.

Boost.Spirit vergessen?

#include <boost/spirit.hpp>
int main(){}

Dauert bei mir 4-5 Sek.

hustbaer

@Don06:
Jo Spirit und MPL und Multiindex und Typeof und...
Nö, nicht vergessen, aber Spirit und MPL gehören IMO schon zu den abgehobenen Sachen, daher hab ich die mal weggelassen.

Bind, Function und Lambda setze ich fast jeden Tag ein, und die reichen oft schon um Programme schön langsam compilieren zu lassen, daher hab ich die angeführt. Wenn ich sage der "Hauptgrund sind Templates" muss ich ja wohl die angeben die ich wirklich oft verwende, sonst wäre das ja ... geschummelt

auch C++ Programme die wenig bis keine Templates verwenden kompilieren lange.

Dravere schrieb:

Redest du gerade davon, dass Java gut dokumentierbar und wartbarer Code hat? Ich wechsle jedes grössere Projekt nach C++, weil ich dort bessere Dokumentation und Wartung habe. Schon nur die Deklaration <-> Definition Trennung von C++ ist viel angenehmer zum warten.

Klar, als Geschichts- und Informatikstudent hat man da natürlich den Überblick und täglich viele größere Projekte nach C++ zu portieren.

In Java ist immer alles am Stück, ganz ganz hässlich, meiner Meinung nach.

Warte, bis du ins zweite Semester kommst, dann änderst du deine Meinung.

borg

borg schrieb:

mh, also ein komplettes rebuild des java projekts an dem ich gerade beruflich arbeite dauert durchaus so 5-10 minuten. (auf einem t30...)

Generierst du da auch Code (MDA) oder nur kompilieren?

Nur kompilieren. Ein rekursives wc -l im root ordner des projekts sagt 2158214 loc. da sind aber unmengen jsp's, scripte und xml dateien mit drin.
das ist einfach nur abartig für diese "kleine" webanwendung, wenn man bedenkt das der linux kernel mit 9mio loc in der gleichen größenordnung liegt.

byto

Gut dokumentierter Java-Code hat ja schon alleine wegen der Javadoc Kommentare wahrscheinlich um den Faktor 1.5 - 2 mal so viele LOCs. Dazu kommt noch die Tatsache, dass Java-Code häufig durch anonyme Objekte alles andere als kompakt ist (hinsichtlich LOCs).

Gregor

byto schrieb:

Gut dokumentierter Java-Code hat ja schon alleine wegen der Javadoc Kommentare wahrscheinlich um den Faktor 1.5 - 2 mal so viele LOCs.

Ach. Und Doxygen ist da wesentlich kompakter? Oder was meinst Du? Gut dokumentierter Code hat in jeder Sprache eine Dokumentation, die wesentlich zur Größe der Quelldateien beiträgt.