Buch: Large-Scale C++ Software Design
-
ich kenne kein Projekt, wo ein kompletter Build 20h dauert.
Prinzipiell vorstellen kann ich es mir aber schon, wenn bspw. externe Libs auf Netzlaufwerken liegen, viele dlls mit vielen abhängigen Libs erstellt werden etc.
Bei einer gut konfigurierten Buildumgebung halte ich 20h für übertrieben. Zumindest für ein einzelnes Projekt.
Wenn eine Softwarefirma alle ihre einzelnen Projekte nacheinander neu bauen will, dann kann das natürlich 20h und länger dauern. Aber darum geht es hier ja nicht.
edit:
Wir haben knapp eine Million LOC C++, dazu etwa 100k Zeilen Erlang. Insgesamt dauert der Buildprozess inklusive Installer ca. 3 Stunden.
-
Sone schrieb:
Ach, sowas ist nichts besonderes bei großen Projekten - einige gehen da auch auf 20 oder mehr Stunden.
War das nicht ein Problem der 90-er Jahre?
-
volkard schrieb:
Sone schrieb:
Ach, sowas ist nichts besonderes bei großen Projekten - einige gehen da auch auf 20 oder mehr Stunden.
War das nicht ein Problem der 90-er Jahre?
Meinst du wegen er Rechenleistung? Klar geht es heute vergleichsmäßig schneller. Aber es ist nun mal wie es ist: Mehr LOC heißt: Längerer Build (also ich meine, komplett!).
-
Mehr LOC heißt: Längerer Build
Den Wahrheitsgehalt kann ich der Aussage nicht nehmen, aber der Informationsgehalt ist gleich null. Ein grosser Berg *Erde* beduetet auch, dass mehr geschaufelt werden. D.h. aber nicht, dass ich die Werkzeuge aus der Steinzeit dazu benutze. Und wenn man von Large Scale C++ spricht und bei Kompilezeiten haengen bleibt, ... hat man wohl das wesentliche verfehlt. Ist genau wie Religion oder Politik: Jeder kann drueber labern. Und genau das ist es: Labern ueber Kompilezeiten.
Aber es ist nun mal wie es ist
Tja, tolle Aussagen ... genau wie: ein Mann muss tun, was ein Mann tun muss ... oder aehnliches. Einfach nur Bullshit.
-
tntnet schrieb:
Mechanics schrieb:
Ja, wir nutzen pimpl auch ziemlich intensiv in der Arbeit. Brauchst du ein Buch darüber?
Kompilierzeiten sind nicht mehr ein so großer Problem wie vor Jahren. Wenn man mit den Includes etwas aufpasst, kann man auf moderner Hardware auch große Software in paar Minuten durchkompilieren. Da lohnt es sich nicht, sich großartig darüber auszulassen oder Bücher darüber zu lesen. Andere Aspekte sind bei der Softwarearchitektur viel wichtiger.
Aber wie gesagt, ich kenn das Buch nicht.Was verstehst Du unter große Software? Bei uns dauert ein kompletter Build ca. 6 Stunden. Kompilierzeiten sind auch heute noch ein großes Problem.
Unsere Software hat grob 6 Mio LoC und ein kompletter Build dauert auch etliche Stunden. Die Software ist teilweise auch entsprechend schlecht aufgebaut, vor allem ältere 3rdparty libs, die wir verwenden müssen und noch nicht austauschen können.
[Edit]Ich meinte, 6 Mio Zeilen eigenen Code. Keine Ahnung, wie groß alle 3rd party Bibliotheken sind und was davon alles gebaut wird. Wir benutzen z.B. Qt und haben das teilweise recht massiv umgebaut, das braucht sicher auch seine Zeit zum Kompilieren.[/Edit]
Es ist alles ärgerlich und nervig, aber es ist jetzt nicht DAS Kriterium bei der Architektur. Wenn es in dem Buch hauütsächlich darum geht, finde ich das uninteressant. Wenn es um andere Aspekte großer Projekte geht, dann würde ich das durchaus interessant finden.
-
Das Projekt bei der letzten Firma lag im Bereich zwischen 5-10 Mio Codezeilen, und jedes Einzelmodul benötigte etwa 5-15min. Gesamtzeit etwa 3 Stunden. Aber der Chef hat auch nur in seine Hardware investiert, die Zeiten hätte man mit neuen Geräten durchaus senken können. Wobei in dem Projekt auch kaum Templates verwendet wurden sind.
Das aktuelle Projekt ist da wesentlich genügsamer. Nach diversen Aufräumaktionen, einer Compilererweiterung die dem C++ Builder Multithreading beim Compilieren gibt, und einem 6Kern-PC sind wir nun (und das in einer VM) bei knapp 2min (ursprünglich waren es eher 5-10min).
-
Die Benutzer tun mir leid die Programme benutzen müssen die so komplex sind das man Millionen von Zeilen braucht.
-
dac schrieb:
Die Benutzer tun mir leid die Programme benutzen müssen die so komplex sind das man Millionen von Zeilen braucht.
Du benutzt keinen Browser, keinen Email Client, kein Betriebssystem?
Die meisten "großen" Programme haben Millionen von Codezeilen.
-
dac schrieb:
Die Benutzer tun mir leid die Programme benutzen müssen die so komplex sind das man Millionen von Zeilen braucht.
Na, du bist aber ein selbstmitleidiger
Was ich auch gerade letztens im Netz fand, ist die Aussage von jemandem, dass die Kompilierzeit von einigen Stunden auf nur Sieben Minuten reduziert wurde in dem der gesamte Code in eine Source-File geworfen wurde.
-
Ich kenne das buch. Es sind sicher ein paar ganz interessante sachen drin, aber eben auch einiges das inzwischen wirkllich veraltet ist. Zum beispiel "external include guards": include guards, die nicht im eingebundenen file stehen sondern dort wo eingebunden wird (dann muß nämlich nicht der header geöffnet werden nur um zu sehen, dass das define schon gesetzt ist). Der gewinn dürfte gegenüber dem was man seinen sources damit antut auf heutigen systemen eher gering ausfallen.
Themen wie das Reduzieren von Abhängigkeiten etc. Sind aber natürlich nach wie vor wichtig und aktuell. Ich denke aber, dass es dazu inzwischen bessere Bücher gibt.
-
Danke erstmal für die onTopic-Posts.
Ich denke aber, dass es dazu inzwischen bessere Bücher gibt.
Nämlich?
Nach krümelkackers erwähnter definite list klingt "Modern C++ Design" von Alexandrescu dazu ganz gut, jedenfalls allgemein für Architektur. Was denkt ihr?
-
Eisflamme schrieb:
Nach krümelkackers erwähnter definite list klingt "Modern C++ Design" von Alexandrescu dazu ganz gut, jedenfalls allgemein für Architektur. Was denkt ihr?
Das Buch hat jedenfalls nichts mit "Large Scale" zu tun. So pralle find' ich es auch nicht. Gut, wenn du noch nie etwas von SFINAE gehört hast oder dich noch kaum mit TMP beschäftigt hast, dann sind da neue Dinge für dich drin -- allerdings auch nicht auf dem neusten Stand. Es gibt ja inzwischen die Boost-Bibliotheken und C++11. Ich habe das Buch noch im Schrank stehen. Was ist es dir denn wert?
-
Hm, ich weiß nicht, nach der Kurzbeschreibung dachte ich schon, dass es sich für Architekturen eignet. Aber wenn das nicht so ist, dann ist es wohl auch nicht unbedingt das, was ich suche.
Es muss doch irgendwer über Architekturen in C++ was geschrieben haben? Ist ja jetzt nicht so abwegig. Hm... Oder es hängt zu sehr vom Kontext ab, sodass man das schlecht generalisieren kann. Aber der Large-Scale-Autor hat es doch auch geschafft, auch wenn das nicht up-to-date ist.
-
Ja, einige Sachen sind veraltet - Typlisten
variadic templates, und wenn mich nicht alles täuscht dann ist das Command-Pattern einfach durch Lambdas zu lösen.(Hab das Kapitel für Commands gerade erst angefangen, aber so wie es aussieht ist es genau das)
-
Sone schrieb:
und wenn mich nicht alles täuscht dann ist das Command-Pattern einfach durch Lambdas zu lösen.
Wahrscheinlich. Aber nur am Rande. Vielleicht will man ja gar nicht überall Lambdas verwenden. Versuch nicht, alles durch Lambdas zu lösen. Das ist natürlich ein cooles Feature, vor allem wenn man an 1-2 Stellen ohne viel Overhead was machen will. Aber sonst würde ich es z.B. wahrscheinlich sauberer finden, tatsächlich eine Command Schnittstelle zu definieren und nicht mit Funktionszeigern (oder std::function) zu hantieren.