Die Entwicklung zurück

Ich grüße euch, Erdlinge!

Eines vorweg: Hier wird viel Text kommen und es geht um keine spezielle Frage, die zu beantworten wäre, daher möchte ich jedem kurz angebunden raten, nicht weiterzulesen (ohne aber abschrecken zu wollen :))!

Mein Softwareprojekt (Ein integriertes System zur Messdatenerfassung und -verarbeitung) wächst und gedeiht, allmählich halte ich auf die 200klocs zu, was für meine bescheidenen Maßstäbe exorbitant erscheint. Viele Zeilen sind wohl dem Umstand verschuldet, dass ich mich nicht an Bibliotheken binden mochte, deren Eigenschaften oder Schnittstellen ich einfach nicht mochte, für private Zwecke kann man ja auch schließlich machen, was man will und ist nicht zwingend an dem Effizienzwettrennen beteiligt (und hat nicht das Geld, kommerzielle Lösungen einzukaufen, die einem ansonsten vielleicht gefielen...).
Aber zum Thema! Ich stelle an mir während dieses Entwicklungsprozesses fest, dass eine stetige Erosion der C++-Kunst, wie ich sie zu verstehen gelernt habe, stattfindet. In meinen kleinen Projekten der ersten Zeit lief eigentlich alles glatt. Man hat angefangen verschiedenste C++-Konstrukte zu seinem Nutzen einzusetzen, alles typsicher aufgeteilt, mit Streams und Iteratoren gefrickelt, templates ausgereizt, man hat Bücher über tolle Techniken bis hin zu dem Kram von Andrescu gelesen. In zielgerichteten Programmen und in 3D-Zeug mit beschränkter Interaktivität hat alles toll funktioniert.
Inzwischen aber hantiere ich mit "reichen" GUI-Elementen, Skript- und Erweiterbarkeit, kontextuellen Operationen, dynamischen Konfigurationen und Abläufen. Es ist so gekommen, dass sich die feine Vernetzung von Daten und Events in's gröbere und in Richtung von größeren, möglichst unabhängigen Komponenten gewandelt hat.
Es kamen in der Zwischenzeit immer öfter Situationen auf, in denen ich punktuell explizit die Typsicherheit von C++ verlassen habe, eine Art von id- (seien es Strings als Klartextnamen oder numerische Werte) basiertem RTTI verwendet habe. An den meisten Stellen wäre es auch anders gegangen, oftmals war es nur ein Versuch, der aber bis in die Neuzeit erhalten blieb, wie es nunmal so kommt. Der Gedanke war halt, man könnte das immernoch zu bestem Lehrbuch-C++ zurückbauen, wenn einem danach ist.
Aber in mir reift immer mehr der Gedanke heran, demnächst zwischen den Komponenten und auch in den Komponenten ein einheitliches RTTI-System zu verwenden, um die einzelnen Speziallösungen zu einem "gesamten einheitlichen" zu integrieren, einfach weil ich mir damit alles viel klarer vorstelle. Auch in die Datenmodelle würde das in meinem Gedanken Einzug erhalten, ich könnte beispielsweise View-bezogene Meta-Daten abspeichern, Controls könnten sich einheitlich auf vom User selektierte Modell-Objekte einrichten. Also ich betrachte das jetzt so, dass am Ende mehr spezifische Information über die fraglichen Objekte "gezogen" oder aber auch "injiziert" wird, denn alles vielleicht benötigte immer explizit an einem Dutzend unterschiedlicher aber typsicherer Kommunikationsstellen im fraglichen Moment zur Verfügung zu stellen. Also irgendwie nach dem COM-Motto QueryInterface, nur halt doch eher noch in der C++-Welt verwurzelt.
Nun kämpfe ich seit einiger Zeit dagegen an, weil es mir irgendwie als Form von "Versagen" vorkommt, mich sozusagen diesem schwelenden Gedanken hinzugeben, weil das ja mal so überhaupt nicht dem gemeinen C++-Mantra folgt, von dem man unter Anderem auch hier natürlich immerzu liest. Außerdem habe ich natürlich Angst, dass ich mir all die harte Arbeit zunichte mache durch Folgen, die ich noch gar nicht absehen kann, ich bin halt kein erfahrener Softwarearchitekt, der schon (fast) alles gesehen hat und die richtige Lösung immer parat hat. Allmählich werden solche Paradigmenwechsel außerdem auch verhältnismäßig zeitintensiv, selbst als einfacher Versuch. Seit Ewigkeiten plagen mich diese Fragen nun, aber im Gegensatz zu anderen Problemfeldern, auf denen ich so tätig bin, kommen mir die Lösungen irgendwie nicht "von selbst" über die Zeit, eigentlich sind nur einige extrem schlechte Lösungsansätze als Mahnmal hängengeblieben, ansonsten ist das Kochbuch des guten Geschmacks sozusagen noch zu 90% ungeschrieben.

Ich würde mich an dieser Stelle sehr über Geschichten aus eurem Leben freuen, von wachsenden Projekten, von Entwicklungen euers Stils währenddessen, von Fehlern und Rückschritten. Entwickelt ihr auch die größten Anwendungen strikt nach Andrescu, könntet ihr euer Bildverarbeitungsprogramm zu einem Wordprozessor machen, wenn ihr nur die Traits-Klassen auswechselt? Habt ihr auch einmal die Welt der Typsicherheit verlassen? Zu welchem Zweck? Musstet ihr zurückrudern? Was ist passiert, als eure Projekte mit euch, an euch oder ihr an ihnen wuchst?
Ich würde mich riesig freuen, hier auch mal aus dieser Richtung etwas von euch kennenzulernen, ohne sich direkt auf spezielle C++-Teilaspekte zu versteifen. Vereinen soll der Umstand, dass alles in C++ begann, vielleicht seid ihr ja auch umgestiegen oder habt die Sprachauswahl ausgeweitet. Wichtig wäre eigentlich nur, dass das Umfeld etwas umrissen wird, damit man das gesagte einzuordnen weiß, denn schließlich sind die Lösungen nicht in jedem Gebiet dieselben (Mikrocontroller vs. Bilbiothek vs. GUI-Applikation vs. Datenbank-Screens).

Viele Grüße,
Deci

volkard

Das Projekte umkippen, ist normal. Je weniger Erfahrung der Architekt hat, desto sicherer geschieht es. Dann muss man es halt neu aufsetzen und diesmal nicht so schlimm frickeln, wie Du es anscheinend nur noch machst. So fährste gegen eine Wand, alles wird immer schwieriger zu warten, bald wehrt sich das Projekt spürbar gegen jede geänderte Zeile Code.

Na vielleicht klang ich in der Hinsicht gerade etwas pessimistisch, das ist so eine Charaktereigenschaft von mir ;). Mir kippt (zumindest gefühlt) im Moment eigentlich nichts um. Es hat sich nur eine Anforderungsänderung ergeben, in deren Verlauf eine Refaktorisierung (in diesem Fall eher eine Aufbohrung) der betroffenen Teile natürlich angemessen erscheint. Sowas passiert natürlich auch alle Tage, nur in diesem Fall kann ich noch nicht absehen, ob das Zusammenführen und Promoten der angesprochenen Dynamisierung vielleicht zuviel des Guten sein wird. Vielleicht muss ich den Weg einfach mal gehen, die Frage beschäftigt mich ja nun schon länger und nichts bleibt besser haften als ein headcrash... Das soll jetzt aber nicht von der Bitte nach Erfahrungsgeschichten ablenken, mal von anderen in diesem Belang zu hören würde mich freuen

Edit: Anders ausgedrückt, es funktioniert schon seit Projektbeginn sehr gut, an den einzelnen Baustellen zu arbeiten, ohne dass es Auswirkungen auf das Drumherum hat (Mal arbeite ich an Komponente A, mal an Modell B, mal an GUI C... oder wechsle halt auch mal ein ganzes Datenmodell aus etc...). In diesem Fall aber würde ich ja wie beschrieben das Drumherum durch die Vereinheitlichung mit einbeziehen. Daher geht meine Gedankenwelt gerade eher in die Richtung, ob es ab ein gewissen Zeitpunkt Sinn machen kann, so etwas wie CObject für alle im öffentlichen Austausch stehenden -> dynamisch/kontextuellen <- Bestandteile zu haben (Also in meinem Fall vor allem Komponenten der verschiedenen Datenmodelle). Bei den großen Game-Engines sehe ich solche Strömungen auch einfließen, nur sind Game-Engines ja gerade nicht mein direktes Anliegen und jede Baustelle braucht potenziell anderes Werkzeug... Andererseits bieten Game-Engines wiederum auch sehr große Ähnlichkeiten bezüglich Skriptbarkeit und Verkettung von "Datenmodellentitäten" zur Laufzeit...

nn

Decimad schrieb:

Das soll jetzt aber nicht von der Bitte nach Erfahrungsgeschichten ablenken, mal von anderen in diesem Belang zu hören würde mich freuen

Na, dann will ich auch mal meinen Senf dazu geben. Der Bereich der Messdatenerfassung ist mir auch nicht ganz fremd, ich arbeite im Bereich der Automatisierungstechnik und meine privaten Projekte sind meist kleinere Experimente, um neue Ideen erst mal reifen zu lassen.

Decimad schrieb:

Ich würde mich an dieser Stelle sehr über Geschichten aus eurem Leben freuen, von wachsenden Projekten, von Entwicklungen euers Stils währenddessen,
[...]

Entwickelt ihr auch die größten Anwendungen strikt nach Andrescu, könntet ihr euer Bildverarbeitungsprogramm zu einem Wordprozessor machen, wenn ihr nur die Traits-Klassen auswechselt?

Du sprichst da etwas an, was der Grund ist, warum ich hier nur sehr selten schreibe. Ich habe C++ zu Zeiten der ersten Auflage vom Stroustrup gelernt, meine Designs sind auch heute noch vom damals sehr neuen Buch "Design Patterns" geprägt. Auch wenn ich heute viele C++11 Konstrukte verwende, würde ich meinen C++ Stil eher als konservativ bezeichnen. Ich habe auch keine Ausgabe des C++ Standards und schaue auch nicht nach, ob das was ich tue der "reinen Lehre" entspricht.

Allerdings habe ich auch mit C# und etwas mit F# zu tun, Bücher zu F# wie "Real World Functional Programming" haben meinen aktuellen C++ Code sicher mehr beeinflusst als Andrescu.

Bis jetzt wurde noch jedes größeres Projekt unwartbar. Auch du wirst nicht drum herum kommen.

Eisflamme

Vorneweg:

Bis jetzt wurde noch jedes größeres Projekt unwartbar. Auch du wirst nicht drum herum kommen.

So wie ich das sehe, hast Du die Frage nicht kapiert. Hat OP die Wartbarkeit von großen Architekturen hinterfragt? Lies den OP nochmal kritisch auf Deine Interpretation dessen oder lass es - aber das wäre mein Vorschlag.

@OP:
Ich kann gut nachvollziehen, was Du meinst... und dass hier nur so halbgare Kommentare kommen, ist für mich persönlich immer irgendwie der Ausdruck davon, dass hier jeder weiß, wie er die feinen Facetten von C++ perfekt nutzt - aber niemals das alles auch in einem großen Projekt eingesetzt hat. Vielleicht wissen das manche Leute besser, dann sind sie aber nicht wirklich dazu fähig auszudrücken, was ihre Projekte erweiterbar und änderbar macht - und seien wir ehrlich, genau das ist die Frage. Ein:

Das Projekte umkippen, ist normal. Je weniger Erfahrung der Architekt hat, desto sicherer geschieht es. Dann muss man es halt neu aufsetzen und diesmal nicht so schlimm frickeln, wie Du es anscheinend nur noch machst. So fährste gegen eine Wand, alles wird immer schwieriger zu warten, bald wehrt sich das Projekt spürbar gegen jede geänderte Zeile Code.

beantwortet das nicht Mal ansatzweise. Wenn er so viel frickelt, woran könnte das denn liegen? "Kann man so allgemein nicht beantworten." Tut mir Leid, dann bist Du für mich kein ansatzweise guter Systemarchitekt. Hey, ich bin auch keiner, keine Frage. Und Deine Leistungen in Algoritmik bewundere ich. Aber ich kenne gute Architekten von großen Firmen und die hätten hier klare Antworten parat, kein schwammiges Gelaber oder kritikbezogene Antworten - schlecht reden kann jeder alles, vollkommen uninteressant und nutzlos.

Du sprichst da etwas an, was der Grund ist, warum ich hier nur sehr selten schreibe. Ich habe C++ zu Zeiten der ersten Auflage vom Stroustrup gelernt, meine Designs sind auch heute noch vom damals sehr neuen Buch "Design Patterns" geprägt. Auch wenn ich heute viele C++11 Konstrukte verwende, würde ich meinen C++ Stil eher als konservativ bezeichnen. Ich habe auch keine Ausgabe des C++ Standards und schaue auch nicht nach, ob das was ich tue der "reinen Lehre" entspricht.

Okay, wieder Mal würde ich hier gerne wissen: Wie viele 100kloc haben Deine Projekte. Sind es <100kloc... bei allem Respekt, aber das, was OP fragt, kannst Du basierend auf den Projekten (sprich: basierend auf praktischer Erfahrung, theoretisch womöglich, aber davon sah ich hier nichts) nicht beantworten.

Schaut man sich einmal Bibliotheken wie QT an, die zwar vielfach kritisiert werden aber für große Projekt eigentlich schon eine gut organisierte Architektur darstellen, so stellt man fest, dass C++11 oder auch Templates so gut wie gar nicht genutzt werden. Bei aller Kompetenz, die hier rumschwirren mag: Wenn es keine großen Projekte gibt, die C++ sauber umsetzen, wer will sich da denn anmaßen, dass C++ gut geeignet für große Projekte ist bzw. all die feinen Sprachfunktionen, die man im Detail nutzen möchte/sollte, sich dafür überhaupt eignen? Ich habe noch nichts dazu gelesen, wie sich jemand gegenüber dieser Kritik stellt.

Ich selber liebe C++ und glaube auch, dass es Ansätze für gute, große Architekturen gibt. Gesehen habe ich das aber noch nicht - falls OP hier irgendwas anderes meint, ziehe ich all meine Aussagen zurück, weil mir nichts ferner liegt als einen Flamewar o.ä. zu starten.

Aber könnte jemand Mal von Floskeln und gedankenlosen Schlechtredereien wegkommen und tachless reden? Oder weiß es einfach keiner besser? OPs Wunsch nach Antworten war der hier:

Ich würde mich an dieser Stelle sehr über Geschichten aus eurem Leben freuen

Super! Würde ich auch allzu gerne wissen! DAS hätte Wert!!

hier sind fast ausschließlich hobbyprogrammierer unterwegs, deswegen wirste hier nicht viel erfahren können

volkard

Ist leider wieder OT: Ein wenig Zurückbesinnen wie nn und Du das machen, das ist gut. Die C++-Gemeinde ist voller Spaß am Ausloten, was überhaupt geht, und verliert dabei den Bezug zur eigentlichen Problemlösung.

kdz schrieb:

hier sind fast ausschließlich hobbyprogrammierer unterwegs, deswegen wirste hier nicht viel erfahren können

Genau. Die Leute hier haben viel zu viel Zeit. Hacker die posten, hacken nicht und wenn, dann nur an Mini-Hobbyprojekten. Leute mit Ahnung von grossen Projekten lernen auch nicht den C++-Standard auswendig, sondern überlegen sich sprachunabhängig eine Architektur und lassen sie von Codemonkeys ausprogrammieren. Die interessieren sich nicht für Streams, Container und Policies. Das Ziel ist, eine Codebasis hinzuklatschen, die von Vollpfosten gewartet werden kann.

Ich hatte einmal eine Boost.MPL Typ-Liste in freier Wildbahn aufgespürt. Da war schönes C++ im Stil von diesem Forum dabei. Die Komponente wurde aber später in C# neu geschrieben.

otze

Hi,

ich arbeite an einem Projekt mit 160k Zeilen welches intensiv C++ Features einsetzt. Ohne templates wären es wahrscheinlich 2-3x so viele.

Ich würde mich an dieser Stelle sehr über Geschichten aus eurem Leben freuen, von wachsenden Projekten, von Entwicklungen euers Stils währenddessen, von Fehlern und Rückschritten.

Ich arbeit an einer Maschinenlern Bibliothek. Unser Ziel ist nicht weniger als "One-for-all". Das heißt, wir wollen alles anbieten und müssen damit rechnen, dass die User eine große Palette von verschiedenen Anwendungen haben. Das heißt wir müssen sowohl mit spärlichen als auch mit dichten Daten effizient zurecht kommen (fast jeder Algorithmus kommt mit einem template parameter für den Typ der Daten), manche Algorithmen auch mit beliebigen Datentypen. Zudem müssen alle Algorithmen flexibel implementiert sein, weil wir selbst natürlich Wissenschaft damit betreiben. Das heißt, dass ein Algorithmus nicht nur aus einem Teil besteht, sondern aus mehreren, die dann aus einer Toolbox beliebig kombiniert werden können. Das alles über virtuelle (templatisierte) interfaces hinzukriegen war in der Tat schwer.

Die misten Interfaces haben ine lange Palette von Änderungen hinter sich und ich habe mit SIcherheit jede Klasse 3x neu implementiert. Den Luxus haben wir uns einfach gegönnt

Entwickelt ihr auch die größten Anwendungen strikt nach Andrescu, könntet ihr euer Bildverarbeitungsprogramm zu einem Wordprozessor machen, wenn ihr nur die Traits-Klassen auswechselt?

Quatsch. Das skaliert nicht. Auch wenn ich sehr fortgeschrittene Sprachmittel verwende, habe ich die Erfahrung gemacht, dass normale User mit Traits extreme Probleme haben. Da blicken die nicht durch. Das selbe Interface dargestellt mit vituellen Klassen ist kein Problem, aber sobald Traits ins Spiel kommen, gehen die Rolladen runter. Komplizierte Dinge müssen einfach aussehen, sonst schaltet sich das Gehirn aus.

Ich habe vor kurzem eine Komponente einm Dumb-Down unterzogen, weil der Supportaufwand für mich einfach zu hoch wurde. Jetzt kann sie eben weniger.

Was ist passiert, als eure Projekte mit euch, an euch oder ihr an ihnen wuchst?

Mein Stil wurde ruhiger. Ich mache zwar noch immer komplizierte Dinge, aber das äussere Interface muss einfach sein. Es gibt Dateien, wo ein normaler User nicht rein schauen darf, weil er dann sofort in Ohnmacht fällt. Aber die sind gut versteckt ;). Ich reviewe mich inzwischen auch selber, schaue meinen alten Code an und überlege, ob ich das vielleicht einfacher, mit weniger Template-Overhead lösen kann.

Danke Otze, das klingt doch nach einem spannenden Feld und auch danach, als hättest Du da sehr viel Freude
Das beobachte ich an mir selber auch, dass ich inzwischen ein extrem ruhiges Code-Bild bevorzuge, ich kann mich also sozusagen auch selber kirre machen

nn

Eisflamme schrieb:

Okay, wieder Mal würde ich hier gerne wissen: Wie viele 100kloc haben Deine Projekte. Sind es <100kloc... bei allem Respekt, aber das, was OP fragt, kannst Du basierend auf den Projekten (sprich: basierend auf praktischer Erfahrung, theoretisch womöglich, aber davon sah ich hier nichts) nicht beantworten.

Privat, wie gesagt, eher klein. Um neue Dinge auszuprobieren.

Beruflich, im Hauptprojekt ca. 500kloc C# und 2600kloc C++, 1998 als einzelner Entwickler begonnen (natürlich ohne C#), mittlerweile haben 14 Leute dazu beigetragen, aktiv arbeiten wir mit 6 angestellten Entwicklern daran, aber nicht ausschliesslich. Angefangen in VS97, von Version zu Version gehoppelt, mittlerweile 2012. (Ja, ich bin seit dieser Zeit hier im Forum, habe mich erst viel später angemeldet.)

Eisflamme schrieb:

bei allem Respekt, aber das, was OP fragt, kannst Du basierend auf den Projekten (sprich: basierend auf praktischer Erfahrung, theoretisch womöglich, aber davon sah ich hier nichts) nicht beantworten.

Bei allem Respekt: Das kannst du nicht beurteilen.

Eisflamme schrieb:

Super! Würde ich auch allzu gerne wissen! DAS hätte Wert!!

Again, bei allem Respekt: Nein, hier geht es um primär um Kritik, man findet in diesem Forum nützliche Dinge, aber zu sehr beteiligen sollte man sich nicht.

otze schrieb:

das äussere Interface muss einfach sein.

Genau. Und der Code innen sollte auch einfach sein, irgendwann muss es vielleicht mal ein anderer warten. Viele hier meinen, wie toll sie sind, wenn sie komplizierten Code schreiben können, aber eigentlich ist es viel schwieriger einfachen Code zu schreiben, den jeder versteht.

otze

jap schrieb:

otze schrieb:

das äussere Interface muss einfach sein.

Genau. Und der Code innen sollte auch einfach sein, irgendwann muss es vielleicht mal ein anderer warten. Viele hier meinen, wie toll sie sind, wenn sie komplizierten Code schreiben können, aber eigentlich ist es viel schwieriger einfachen Code zu schreiben, den jeder versteht.

Mir ist es lieber 1k Zeilen hässlichen Code zu schreiben, wenn ich dafür aus 10k Zeilen repetetivem fehleranfälligen Code 2000 Zeilen generellen straight-forward code machen kann. Natürlich benötigt man dann für die 1000 Zeilen jemanden, der sich da mal ein paar Tage eindenkt. Dafür werden aber keine Forschungsergebnisse invalidiert, weil der bugfix nur in einem der 3 if-Zweige eingebaut wurde.

Eisflamme

nn:
Sorry, da habe ich mich im Ton vergriffen, das kam gar nicht so rüber, wie ich's meinte. Auf solche Fragen kommen hier immer so flache Antworten von Leuten, bei denen ich eigentlich denke, dass sie an sehr großen Projekten beteiligt sind und daher eigentlich die Fragen auch beantworten könnten, es aber aus mir unersichtlichen Gründen nicht tun.

Aber damit warst Du gar nicht gemeint und dein Beitrag danach war ja auch sehr interessant, also verzeih bitte.

otze schrieb:

jap schrieb:

otze schrieb:

das äussere Interface muss einfach sein.

Genau. Und der Code innen sollte auch einfach sein, irgendwann muss es vielleicht mal ein anderer warten. Viele hier meinen, wie toll sie sind, wenn sie komplizierten Code schreiben können, aber eigentlich ist es viel schwieriger einfachen Code zu schreiben, den jeder versteht.

Mir ist es lieber 1k Zeilen hässlichen Code zu schreiben, wenn ich dafür aus 10k Zeilen repetetivem fehleranfälligen Code 2000 Zeilen generellen straight-forward code machen kann. Natürlich benötigt man dann für die 1000 Zeilen jemanden, der sich da mal ein paar Tage eindenkt.

Stellt sich nur die Frage, warum einfacher Code länder sein sollte. Die meisten Template- Operatorüberladungslösungen die hier gezeigt werden sind meistens länger als der einfache Code.

Hallo!

Ich fänd's toll wenn dieses "Ein Satz aus dem größeren Zusammenhang eines Posts reißen" und darüber eine hitzige tiefe, aber schmale Ein-Satz-Diskussion vom Zaun zu brechen hier möglichst minimal gehalten wird, da ich einfach darauf hoffe, dass hier vielleicht nochmal eine mitteilungsbedürftige Seele hereinschaut und etwas zum Thema beiträgt! Sowas sieht man bei pseudointellektuellen Boulevard-Talkshows doch schon zu genüge, wir sind doch aber eigentlich besser, oder etwa nicht?

Eigentlich glaube ich, dass die meisten C++ Features und Idiome für Anwendungsentwicklung nicht viel bringen, sondern mehr für Libraries. Die meisten komplizierteren Template Sachen lassen sich z.B. gut anwenden, wenn man Libraries wie std::container oder aufwenigere schreibt, aber bei der normalen Anwendungsentwicklung braucht man sowas eher weniger. Operatorüberladung ist für ne Mathelib ganz nett, aber um Buttons zu nem Dialog hinzuzufügen (zu addieren) eher weniger. Eines der wenigen C++ Idiome, das man öfters verwenden kann ist RAII, aber den Rest braucht man doch selten.

Mechanics

Habs schon paar mal in anderen Threads geschrieben. Wir arbeiten an einem Projekt mit 6 Mio Zeilen. Ich selber bin jetzt nicht so der fanatische C++ Fanboy, der versucht alles über Templates oder Streams zu lösen. Solche Sachen (und vor allem Alexandrescu) eignen sich eher für Libraries, da geb ich SoundOfHome völlig Recht. Ich seh jetzt auch keinen wahnsinnig großen Unterschied zwischen C++ und Java/C#, was Softwarearchitekturen angeht. Natürlich würde man vieles eher etwas anders lösen, weil die Sprachen und die zur Verfügung stehenden Sprachmittel unterschiedlich sind, aber bei grundlegende Highlevel Konzepte würde ich nicht viel anders machen. Es kommt auch stark drauf an, was man macht. Wenn man mit C++ hauptsächlich irgendwelche wissenschaftlichen Anwendungen wie Physiksimulationen schreibt, wird die Architektur zwangsweise anders ausschauen, als bei einem "Anwendungsprogramm". Was wir schreiben ist eine Art Anwendungsprogramm und da eignen sich durchaus Konzepte wie DDD, MVC usw. Bei so einem großen Projekt gibts aber auch sehr unterschiedlichen Code. Wenns z.B. darum geht, die Anbindung an verschiedene PDM Systeme zu abstrahieren, bieten sich Templates nicht so wirklich an. Aber wir haben auch Code, um CAD Modelle zu generieren, und da haben wir in unseren grundlegenden Libs durchaus viel Templatecode. Das sind aber Implementierungsdetails, die im großen Überblick keine Rolle spielen würden.
Insgesamt muss man meiner Ansicht nach also immer beides im Auge behalten, Architekturkonzepte für das ganze Projekt, und Design Patterns/Idiome für die Implementierungen.