Ich führe die Diskussion mal weiter, da ich das einfach loswerden muss:
Ich habe mittlerweile Qt Creator 4.6rc installiert, wo mit Clang5.1 ein "besseres" Code Model vorhanden ist. "Besser", weil es 1.5GB RAM frisst (1GB mehr als mit dem klassischen Modell) und jede Code Completion einige Sekunden geht und einen Kern voll auslastet. Naja, ist ja alles noch Beta(TM).
Jedenfalls gibt es jetzt so nette Codestyle-Warnings:
(m_serial_monitor ist ein std::unique_ptr).
Hier sehe ich mittlerweile das grösste Problem von C++: Je neuer der Standard, desto mehr wird die Herkunft geleugnet. Ich habe echt nichts gegen Syntaxerweiterungen, die Boilerplate wegnehmen, wie die foreach-Loops.
Aber irgendwie wird krampfhaft versucht, Pointer zu verstecken, eigentlich beginnend schon mit Referenzen in C++98(?), dann weiterführend mit auto_ptr, shared_ptr, unique_ptr, etc.
Ich finde diese Hilfen sehr nett, gerade durch RAII kann man sich viele Kopfschmerzen ersparen, aber den Grundsatz "never use new/delete", der u.a. auf SO so dermassen beliebt ist, ist doch irgendwie falsch.
Das artet dann in solchen Artikeln aus:
https://www.quora.com/Why-is-C++-considered-a-bad-language
(Wobei der nette Mensch vergisst, dass GCs dafür einfach irgendwann mal einspringen, und der Optimizer ziemlich gut ist für Function calls).
Wie schon gesagt, was gebraucht wird, ist ein C, das syntaktisch einfacher/kürzer ist, namespacing/(Classes) besitzt, und eine Art Smartpointer hat, um Leaks zu vermeiden. Dazu noch ein bisschen Würze wie Typesafety, meinetwegen auch Templates.
Das wäre dann ein C++. Exceptions meide ich persönlich wie die Pest, da es in der Regel zu sehr schlimmen Code führt (try-catches als control flow oder für Rückgabewerte (schauder)). CryptoPP spielt in dem Gruselkabinett recht weit vorne mit, mit Exceptions für falsche Schlüssel, self-deleting Parameter Pointers etc.
An unserer Uni hatten wir kürzlich eine Code Review für Java-Code. Codefragmente, die mehr als 20 Zeilen lang waren, wurden als schlecht erachtet, da man mehr in Funktionen auslagern sollte. OOP wird nicht mehr als Ausweg für zu unübersichtlichen Code, sondern als Standard gelesen.
Jedes mal, wenn ich sage, meine Klassen haben etwa 50 Funktionen und manche Funktionen sind 200 Zeilen lang heisst es, dass das schlechter Stil ist. Wenn ich in einer Gruppenarbeit eine Referenz auf ein Objekt übergebe, das eine State-Variable hat, die dann innerhalb der Funktionen verändert wird, kommt jemand daher und refactort das Ganze, sodass bei jedem Iterationsschritt (State-Change) ein Objekt erstellt wird, das den letzten State und den nächsten State hält, das dann als State übergeben wird, da das ja eher Funktional und daher besser sei. Da die Klasse aber auch den Kontext hielt, wird die Referenz dann einfach per Konstruktor an den Arbeiter übergeben. Somit macht man dasselbe quasi doppelt, kopiert sich und den Speicher zu Tode, aber es sieht funktionaler aus! Ziel erreicht, Performance ist ja eh egal.
Wenn ich aber jeweils die privaten Projekte vergleiche, machen meine Projekte echte Arbeit (CPU-Emulation, Logik-Emulation) in einem annehmbaren Zeitrahmen (1 durchschnittliche ARMv6-Instruktion auf einem 7500U @ 2.7GHz in ~200ns, keine besonderen Performancemassnahmen), während die Fans von OOP und 2-Zeilen-Funktionen einfach ein paar Standardfunktionen zusammenkleben und Bilder ausgeben oder aus Prinzip mit JSON arbeiten.
Ich will damit nicht sagen, dass ein aufgeräumter Stil schlecht ist, sondern, dass es auf den Anwendungsbereich ankommt. Man kann keine komplexen Bitoperationen in 5 Zeilen abschliessen; man kann nicht SmartPointer verwenden, wenn man innerhalb eines Scratch Buffers arbeiten will, etc. Wenn man aber ein PoC machen will, dann ist JSON legitim. Für Apps am Mobilnetz ist es mittlerweile Standard, danke auch für den Datenverbrauch.
Aber irgendwie ist dieser "Nutz doch die riesige Standardbibliothek für alles" aus Java, C# und mittlerweile Rust ein erklärtes Ziel von C++.
Und genau das, denke ich, ist das Problem des Komitees. Statt die Stärken von C zu betonen und die Schwächen auszumerzen, will man unbedingt modern sein und alles haben, was andere auch haben, ungeachtet dessen, was C so gut macht.
Das artete dann auch in diesem Aprilscherz aus:
https://www.heise.de/developer/artikel/No-New-New-Das-Ende-von-Zeigern-in-C-4009347.html
Was mich aber wundert, ist der scheinbare Konsens auf dem OOP/Funktional/"Moderne Sprache"-Wahn. Kaum jemand jemand, mal von den Kernel-Entwicklern abgesehen, scheint den alten Stil zu verteidigen.
Ich weiss nicht, ob es daran liegt, dass heutzutage niemand mehr direkt auf Hardware arbeitet (da ist mir oft selbst C zu ungenau, bzw. GCC mit seinen Register-readbacks after write) oder dass mittels IDEs das Nachverfolgen von Codepfaden einfacher ist, aber irgendwie missfällt mir diese Entwicklung. Aber wer weiss, vielleicht bin ich auch der einzige ¯\_(ツ)_/¯
Gruss
cwriter