Buch: Large-Scale C++ Software Design
-
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.