Warum lassen C/C++ Compiler soviel Müll zu?

knivil schrieb:

In groesseren Projekten wird sowieso alles ueber Nacht gebaut, so dass es eigentlich egal ist.

Klar, die Entwickler compilieren einfach nichts, sondern checken ihren Code einfach ein.

und wenn eine Zeile wegen eines vergessenen Semikolons mal nicht compilieren sollte, fügt man das Zeichen ein und wartet halt bis zur nächsten Nacht - bloß kein Streß

knivil

LOLBla schrieb:

knivil schrieb:

In groesseren Projekten wird sowieso alles ueber Nacht gebaut, so dass es eigentlich egal ist.

Klar, die Entwickler compilieren einfach nichts, sondern checken ihren Code einfach ein.

Und wie viel ist das so an Zeilen, den ein Entwickler am Tag neu kompilieren muss? Wie viel Zeit geht dabei drauf? Spielt das eine Rolle? Normalerweise nicht.

knivil schrieb:

LOLBla schrieb:

knivil schrieb:

In groesseren Projekten wird sowieso alles ueber Nacht gebaut, so dass es eigentlich egal ist.

Klar, die Entwickler compilieren einfach nichts, sondern checken ihren Code einfach ein.

Und wie viel ist das so an Zeilen, den ein Entwickler am Tag neu kompilieren muss? Wie viel Zeit geht dabei drauf? Spielt das eine Rolle? Normalerweise nicht.

An welchem größeren Projekt hast du schon mitgearbeitet?

knivil

LOLBla schrieb:

An welchem größeren Projekt hast du schon mitgearbeitet?

Was ist ein groesseres Projekt? Wie gross sollte der Eigenanteil sein? Wie lange darf die Entwicklungszeit sein? Welche Sprache? GUI oder Algorithmus (Core, Netzwerkkommunikation, ...)? Zaehlt eine Eclipse-Plugin (nein, das habe ich nicht gemacht)? ... Und was soll das beweisen?

PS: Es sind 16 und nu?

Wenn ich einen kompletten Rebuild des Linux-Kernels mache, dann geht das recht flott, wenn man die Größe bedenkt. Wenn ich ihn schon einmal kompiliert habe, dann sind kleinere Änderungen recht schnell kompiliert.
Und wie in jedem ordentlich entworfenen Projekt dieser Größe kann ich auch nur Teile neu kompilieren, sprich den Teil an dem ich arbeite.

Fazit: bei einem großen C oder C++ Projekt ist ein gut entworfenes Build-System das A und O.

Basher_ist_nicht_BashAr

knivil schrieb:

Basher schrieb:

das hängt vielleicht damit zusammen, dass man unter c++ alles doppelt hat, die klassendefinition in .h-files und den code in .cpp-files.

Bullshit! Und wenn es so waere wuerde ich die Compilezeit gerne in Anspruch nehmen, um ein vernuenftiges Design zu ermoeglichen.

was hat das auseinanderreissen von klassen in zwei dateien (.h und .cpp) mit vernünftigem design zu tun? pro klasse immer 2 dateien synchron pflegen zu müssen, ist umständlicher, als hätte man nur eine. einfach doof sowas.

knivil schrieb:

In groesseren Projekten wird sowieso alles ueber Nacht gebaut, so dass es eigentlich egal ist.

ok, einen vorteil hat es ja: durch diese übelst langen build-zeiten bei grossen projekten, ist man gezwungen, für einzelkomponenten unit-tests o.ä. zu schreiben. sowas fördet natürlich die stabilität des codes, gute schnittstellendefinitionen und planvolles design. bei anderen sprachen muss man dafür selbstdisziplin aufbringen.

knivil

was hat das auseinanderreissen von klassen in zwei dateien (.h und .cpp) mit vernünftigem design zu tun?

Ich oeffne die Headerdatei und sehe die Methoden der Klasse uebersichtlich auf einem Fleck, wenn moeglich noch mit etwas Dokumentation wie Vor- und Nachbedingungen. Wenn ich eine Klasse benutze, so ist die Headerdatei meist in einem zweiten Fenster (naja, so etwas aehnliches) offen. Beim schreiben/designen/denken von Code reicht ein kurzer Blick, ganz ohne auf Tools angewiesen zu sein. Codecompletion, die als Menue aufpopt, ist viel langsamer als ein kurzer Blick, auch ist das Popup klein und bietet nicht die Uebersicht wie ein grosses Fenster. Ganz zu schweigen von den hilfreichen Kommentaren/Beschreibungen/Vor-/Nachbedingungen. Diese Uebersicht kann man mit Headerdateien unter Verwendung eines normalen Editors haben ganz ohne Toolsupport.

pro klasse immer 2 dateien synchron pflegen zu müssen, ist umständlicher, als hätte man nur eine. einfach doof sowas.

Datenmember schon mal nicht. Auch hatte ich nie Probleme damit.

ok, einen vorteil hat es ja: durch diese übelst langen ...

Jaja, wer argumentiert hat schon verloren ... warum probiere ich es ueberhaupt. Man kompiliert meist inkrementell wenn man seinen eigenen Code testet. Wie lange braucht es, 5000 Zeilen normalen C++ Code zu kompilieren (Templates mal aussen vor, da ich Endlosschleifen produzieren kann)?

Basher_ist_nicht_BashAr

knivil schrieb:

Ich oeffne die Headerdatei und sehe die Methoden der Klasse uebersichtlich auf einem Fleck, wenn moeglich noch mit etwas Dokumentation wie Vor- und Nachbedingungen. Wenn ich eine Klasse benutze, so ist die Headerdatei meist in einem zweiten Fenster (naja, so etwas aehnliches) offen. Beim schreiben/designen/denken von Code reicht ein kurzer Blick, ganz ohne auf Tools angewiesen zu sein. Codecompletion, die als Menue aufpopt, ist viel langsamer als ein kurzer Blick, auch ist das Popup klein und bietet nicht die Uebersicht wie ein grosses Fenster. Ganz zu schweigen von den hilfreichen Kommentaren/Beschreibungen/Vor-/Nachbedingungen. Diese Uebersicht kann man mit Headerdateien unter Verwendung eines normalen Editors haben ganz ohne Toolsupport.

^^das gilt aber nur, wenn man editoren wie notepad verwendet. ich glaube, jedem schäbigen 'vim' kannste heutzutage beibringen, dass er methodenkörper usw. auf- und zuklappen kann.

knivil schrieb:

ok, einen vorteil hat es ja: durch diese übelst langen ...

Jaja, wer argumentiert hat schon verloren ... warum probiere ich es ueberhaupt. Man kompiliert meist inkrementell wenn man seinen eigenen Code testet.

klar, der msvc z.b. kennt auch schon lange sowas wie 'precompiled headers' und andere tricks, um den build-vorgang zu beschleunigen. aber trotzdem hört man immer wieder, dass das bauen eines grossen projekts sehr lange dauert (und über nacht gemacht wird!). es reicht ja schon, wenn du einen kommentar in eine zentrale header-datei einfügst. schon muss alles neu gebaut werden, das diesen header #includiert.

knivil schrieb:

LOLBla schrieb:

An welchem größeren Projekt hast du schon mitgearbeitet?

Was ist ein groesseres Projekt? Wie gross sollte der Eigenanteil sein? Wie lange darf die Entwicklungszeit sein? Welche Sprache? GUI oder Algorithmus (Core, Netzwerkkommunikation, ...)? Zaehlt eine Eclipse-Plugin (nein, das habe ich nicht gemacht)? ... Und was soll das beweisen?

PS: Es sind 16 und nu?

So so, irgendwie glaub ich nicht, dass du schon so alt bist. Oder waren die "großen" Projekte alle nach nem Monat oder zwei fertig?

Wieso gibt es eigentlich firmen, die SW herstellen, damit man auch Clustern compilieren kann? Die wissen wohl noch nicht das immer alles über Nacht compiliert wird.

knivil

Klar kann das vim (aber auch nur durch ein plugin). Aber ich so ein Mensch, dem es egal ist, an welchem Rechner er arbeitet, und deswegen moeglichst unabhaengig von vorinstallierter Software oder irgendwelchen Einstellungen. Da moechte ich nicht jedes Mal erst irgendwelche Plugins nachladen und hoffen, dass es dann funktioniert.

Auch ist es ja durchaus ueblich Beschreibung und Realisierung zu trennen. Uebersicht kommt frei Haus. Java kloppt aber alles wieder zusammen, nur um Editoren mit zusammenklappbaren Bloecken zu produzieren. Das soll jetzt Fortschritt sein?

wenn du einen kommentar in eine zentrale header-datei einfügst. schon muss alles neu gebaut werden, das diesen header #includiert.

Bei Java ist das anders? Wie unterscheidet er zwischen Kommentar und Aenderung einer Methodensignatur?

Oder waren die "großen" Projekte alle nach nem Monat oder zwei fertig?

Tja, ich beantworte deine Fragen, wenn du meine beantwortest. Angefangen bei "Was ist ein groesseres Projekt?" bis hin zu "Was soll das beweisen?" Aber ich glaube du willst nur rumpoebeln. Auch habe ich nichts brauchbares bei google unter 'compiling on cluster' gefunden. Vielleicht hilfst du mit ein paar Links nach. Ansonsten ist es wohl kein Problem ein verteiltes "make" zu konfigurieren. Ich kenne es nur aus der Spieleindustrie, dass die Generierung von Texturen oder Vorberechnung von anderen Daten (insbesondere fuer Beleuchtung) mehr Zeit in Anspruch nehmen als man in einer Nacht hat. Aber das hat dann nichts mit der Compilation eines C++ Quelltextes zu tun.

In deinen 16 großen Projekten ist dir also noch nie sowas wie z.B. IncrediBuild begegnet, sag ja einiges über deine Erfahrung mit großen Projekten aus...

knivil

LOLBla schrieb:

In deinen 16 großen Projekten ist dir also noch nie sowas wie z.B. IncrediBuild begegnet, sag ja einiges über deine Erfahrung mit großen Projekten aus...

Aeh haeh, wer sagt das? Ich zitiere mich mal selbst:

Man kompiliert meist inkrementell wenn man seinen eigenen Code testet.

Auch hilft dir IncrediBuild wenig, wenn 10 Entwickler ihre Aenderungen einschecken. Auch ist die Idee wohl eher alt.

Jaja, ich weiss: Don't feed the trolls! Aber ich habe heute ist mein Wohltaetigkeitstag fuer alle Trolle. Sie wuerden ja sonst verhungern. Naechstes Jahr bringe ich ihnen lesen bei ...

Was laberst du dann, dass du bei google nichts findest?

Basher_ist_nicht_BashAr

knivil schrieb:

wenn du einen kommentar in eine zentrale header-datei einfügst. schon muss alles neu gebaut werden, das diesen header #includiert.

Bei Java ist das anders? Wie unterscheidet er zwischen Kommentar und Aenderung einer Methodensignatur?

in Java gibts keine header-files, die überall includiert werden müssen. wenn du z.b. per refactoring 'ne signatur einer methode änderst, die an mehreren stellen benutzt wird, dann müssen natürlich auch diese files neu compiliert werden. theoretisch könnte das build-system bzw. die IDE erkennen, dass nur ein kommentar geändert wurde und die datei nicht zum compiler schicken. aber ich glaub' nicht, dass sowas sinnvoll wäre, weil das compilieren sowieso schon rasend schnell ist.

knivil

Und theoretisch ist das auch nicht spezifisch fuer Java.

knivil schrieb:

Man kompiliert meist inkrementell wenn man seinen eigenen Code testet.

Auch hilft dir IncrediBuild wenig, wenn 10 Entwickler ihre Aenderungen einschecken. Auch ist die Idee wohl eher alt.

Was laberst du eigentlich für zusammenhangloses Zeug? Was hat IncrediBuild damit zu tun wieviel Leute was einchecken?

hustbaer

Ich weiss nicht was ihr hier als schnell oder langsam empfindet. Ich finde es persönlich sehr störend, wenn ein Teil eines Projekts (soll heissen: eine DLL, LIB oder EXE) schon mehrere Minuten braucht. Und Build-Zeiten von mehreren Minuten hat man bei C++ schnell. Eine unserer grösseren Libraries baut z.B. schonmal 10 Minuten. Wenn ein gesamtes Projekt neu gebaut werden muss (z.B. weil es eine Änderung in einer Basis-Library gab, die sogut wie überall verwendet wird), dauert das auch schon mal ne Stunde oder zwei.

@knivil:
C Build-Zeiten (Linux Kernel) mit C++ Build-Zeiten zu vergleichen ist wohl ziemlich weltfremd.
Genauso was die nightly Builds angeht: was bringt mir das, wenn ich trotzdem 5 Minuten warten muss, bis der Teil an dem ich arbeite fertig gebaut hat? Oder meinst du es beschleunigt das Arbeiten irgendwie wenn ich bis zum nächsten Tag arbeiten muss, um das Ergebnis eines Builds zu sehen.

audacia

hustbaer schrieb:

warum????? schrieb:

Zeus schrieb:

Wegen der Rekursion in der Grammatik. IfStatement, WhileStatement sind Statement und hinter dem Kopf darfst du weitere Statements schreiben - recht einfach. Aber verhindert halt nicht, das schreiben vom dummen Code.

Aber warum braucht C++ Code dann soviel länger zum Compilieren als Java Code, der eigentlich viel eingeschränkter ist?

weil C++ viel komplizierter zu compilieren ist als Java.

argument dependent lookup, implizite konvertierungen, templates, overload resolution -> in kombination ist das viel arbeit für einen compiler

Das machts alles nicht aus; ein guter C++-Compiler kann durchaus die Geschwindigkeit eines Delphi-/Java-/C#-/Whatever-Compilers erreichen. Ausschlaggebend ist primär die Menge.

Basher schrieb:

volkard schrieb:

ich frage mal andersrum. warum ist ein brainfuck-compiler so verdammt schnell?

wahrscheinlich weil der befehlssatz sehr klein ist und weil ein bf-programm meistens nur aus einer datei besteht. ok, möglicherweise frisst bei C++ die optimierung des codes auch schon einiges an rechenzeit. ein reiner C-compiler ist auch nicht sehr schnell, im vergleich zu Java-compilern, die dagegen reine raketen sind.

Kommt natürlich darauf an, wie du Schnelligkeit mißt. Wenn du den Zeilendurchsatz betrachtest, gewinnt der C- oder C++-Compiler meistens. Beispielsweise ist der Zeilendurchsatz von BCC (dem C++Builder-Compiler) schätzungsweise achtmal so hoch wie der von DCC (dem Delphi-Compiler). Dennoch kann die Übersetzungszeit eines größeren C++-Projektes in die Stunden gehen, während man bei kleineren Delphi-Projekten vom Kompiliervorgang überhaupt nichts mitbekommt, und selbst bei größeren Komponentenpackages oder Bibliotheken (SynEdit, JCL, JVCL, ...) wartest du schlimmstenfalls Sekunden auf ein vollständiges Rebuild. Ursache ist, daß die Zeilenzahl einer vom Präprozessor behandelte C++-Übersetzungseinheit gewöhnlich sechs- oder siebenstellig ist. Bei C ist das Grundproblem ebenfalls vorhanden, aber C-Header haben üblicherweise ganz andere Dimensionen als C++-Header. Beispiel:

/* c.c */
#include <stdio.h>

/* cpp.cpp */
#include <iostream>

>cpp32 c.c > nul
>wc -l < c.i
1027

>cpp32 cpp.cpp > nul
>wc -l < cpp.i
29359

Vorteil der Angelegenheit ist, daß sich die Kompilierung von C++-Projekten ohne zusätzlichen Aufwand parallelisieren läßt. Das ist bei Delphi nicht ganz so einfach, da die Abhängigkeiten der Units voneinander ein recht verwachsener Graph sind; nur wenige Units haben keine direkte oder indirekte Abhängigkeit voneinander und können dann gleichzeitig kompiliert werden.

Um dem Problem in der Praxis zu begegnen, verwendet man in C++ üblicherweise die bereits erwähnten PCH (pre-compiled headers). BCC generiert z.B. bei entsprechender Konfiguration implizit PCHs, und C++Builder enthält einen PCH-Wizard, der einen für ein einzelnes Projekt optimierten Master-Header zusammenstellen kann. Wenn PCHs richtig eingesetzt werden, werden die Build-Zeiten von C++-Projekten auch sehr überschaubar.

Zeus schrieb:

hustbaer schrieb:

Ein ähnliches Übersetzungsmodell liesse sich für C++ auch machen. Allerdings müsste man dann einige Dinge in der Sprache umkrempeln. Und das wird nicht passieren, da jeder so weit wie möglich zum Standard kompatibel bleiben möchte.

Dann mach mal.

Für C++ wurde ja bereits ein Modul-Konzept vorgeschlagen. Was daraus wird, weiß ich nicht - vielleicht TR1 oder TR2 des neuen Standards? -, aber es sollte unter anderem dieses Problem beheben.

knivil schrieb:

was hat das auseinanderreissen von klassen in zwei dateien (.h und .cpp) mit vernünftigem design zu tun?

Ich oeffne die Headerdatei und sehe die Methoden der Klasse uebersichtlich auf einem Fleck, wenn moeglich noch mit etwas Dokumentation wie Vor- und Nachbedingungen. Wenn ich eine Klasse benutze, so ist die Headerdatei meist in einem zweiten Fenster (naja, so etwas aehnliches) offen. Beim schreiben/designen/denken von Code reicht ein kurzer Blick, ganz ohne auf Tools angewiesen zu sein. Codecompletion, die als Menue aufpopt, ist viel langsamer als ein kurzer Blick, auch ist das Popup klein und bietet nicht die Uebersicht wie ein grosses Fenster. Ganz zu schweigen von den hilfreichen Kommentaren/Beschreibungen/Vor-/Nachbedingungen. Diese Uebersicht kann man mit Headerdateien unter Verwendung eines normalen Editors haben ganz ohne Toolsupport.

+1. Finde ich auch in Delphi (interface/implementation) deutlich angenehmer.

Wie man das header-implementierung design gutfinden kann bleibt mir ein rätsel. Das ganze system wurde doch nur gebaut um dem compiler die arbeit zu erleichtern und nicht dem programmierer. schon vor 30 jahren war das system unzumutbar und kein ernstzunehmender entwickler will mit sowas freiwillig zu tun haben. *kopfschüttel*