Existiert schönes C++ in der Praxis?

It0101

Kann ich so auch bestätigen. Das was ich in meinem ersten Arbeitsjahr direkt nach der Uni so zusammengeschraubt habe, würde ich heute ausgedruckt nicht mal mehr als Klopapier verwenden wollen...

Ist nicht so dass es nicht funktioniert hätte, aber rein von der Wartbarkeit, dem Stil und der Performance war das nicht gerade großes Damentennis....

Heute siehts schon deutlich besser aus, aber es ist eben immer noch viel Luft nach oben.

It0101

Wobei der Begriff "schönes C++" ohnehin subjektiv ist.
Da wirst du von 10 Leuten vermutlich mindestens 9 Definitionen bekommen

Eisflamme

Also mein 30.000 LOC-Projekt, an dem ich seit Jahren nebenbei arbeite, hatte viele echt eklige Bestandteile. Und dann sind mir auch noch bessere Wege eingefallen und zusätzlich habe ich ja die ganze Zeit hier im Forum diskutiert, was mir ein paar Augen geöffnet hat.

Bin auch gerade am Refactoring des mit Abstand größten Basisteils, läuft schon seit ungefähr 3 Wochen, wird jedoch noch deutlich länger dauern. Leider kann ich nicht alles refactorn, das würde einfach zu lange dauern. Respekt, wie man große Projekte in kurzer Zeit komplett refactorn kann!

hustbaer

It0101 schrieb:

Die fstream-Konstruktoren waren ja schon fast peinlich

Peinlich ist eher dass C++ keinen "String-Ref" Typ hat.

Denn wieso sollte eine Funktion (Konstruktor oder normale Funktion ist dabei egal), die einen String nicht als Output-Parameter verwendet, dem Aufrufer aufzwingen dass es ein std::string zu sein hat?
Bzw. als Frage: was ist peinlich daran wenn man den richtigen Parametertyp verwendet?

TyRoXx

It0101 schrieb:

Wobei der Begriff "schönes C++" ohnehin subjektiv ist.
Da wirst du von 10 Leuten vermutlich mindestens 9 Definitionen bekommen

Ne, ist es nicht. Es geht hier ja nicht um lustige Formatierung und andere persönliche Vorlieben. Schönes C++ ist vor allem korrekt, wobei Verständlichkeit und Wartbarkeit als präventive Korrektheitsmaßnahmen inbegriffen sind. Wenn man sich einige Jahre mit Refaktorisierung auseinandersetzt, realisiert man, dass bestimmte Prinzipien gelten. Kurz ist besser als lang. Je weniger Kommentare erforderlich sind, desto besser. Immutable ist besser als mutable. Jede Klasse sollte genau eine Zuständigkeit und möglichst wenige Elemente haben. Redundanz ist schlecht. Interfaces helfen zu enge Bindungen zu vermeiden. usw. Solche Dinge sind nicht subjektiv oder hängen von C++ ab.

Solche Sachen muss man aber erst einmal lernen. Da diese Erkenntnisse kaum beschrieben sind und an keiner Schule gelehrt werden, muss man sie sich selbst mit viel Zeit erarbeiten. Ein Forum wie dieses kann einem die Richtung vorgeben, reicht aber als Quelle nicht aus. Die wenigsten Programmierer befassen sich außerhalb des Betriebs mit Softwareentwicklung. Noch viel weniger schreiben darüber im Web. Ich schätze, dass der Anteil der "dark matter programmers" über 95% liegt. Kann man natürlich schwer messen.

Vermutlich kommen mehrere Faktoren zusammen, damit jemand in einem Forum aktiv wird. Zum einen muss man sich für Software wirklich interessieren. Damit fallen 90% der Programmierer weg ("9-to-5"). Zum anderen muss man bereit sein etwas zu lernen, sich kritisieren zu lassen und man muss Ausdauer haben. Wieder die Hälfte weg. Wer sich weder für Software interessiert, noch etwas lernen will, der wird zum Beispiel Lehrer. Was dabei rauskommt, hört man immer wieder ("die Absolventen von heute können nichts").

Die Folge ist jedenfalls, dass sich zwei Gruppen bilden. Die einen sitzen im Elfenbeinturm und philosophieren darüber, ob Compiler ohne C++14 noch zeitgemäß sind. Die anderen sitzen ihre Zeit ab und halten sich für die größten, weil sie sich nie mit ihren Fehlern auseinandergesetzt haben. Der Kontakt zwischen diesen Gruppen findet typischerweise über Fragen im Forum oder auf StackOverflow statt. Die Trennung hat sich selbst verstärkt. Die guten wurden untereinander besser, die schlechten blieben so. Das ist so wie C++ vs PHP. Die eine Sprache wird mit der Zeit besser, die andere bleibt der gleiche Mist aber jetzt mit Soße oben drauf.

Eine Lösung für dieses Problem kenne ich nicht. Das scheint ein gesamtgesellschaftliches Problem zu sein.

Marthog

It0101 schrieb:

Mich verwundert nicht, dass der eine oder andere streckenweise mit C-Funkionen arbeitet. Ich versuche es, wo immer die Performance es zulässt, mit C++ zu arbeiten.

Das Performanceargument zählt nur teilweise, denn bei Möglichkeit nutzt z.B. std::copy intern auch memcpy.
Ein schlechter bis mittlerer Compiler kann vielleicht nur schlecht optimieren, aber ein guter, hat bei den C++-Funktionen mehr Freiheit zu optimieren.

tntnet schrieb:

Aber ich bin auch mit C++03 sehr zufrieden und finde es fast schon ein wenig befremdlich, mit welcher Selbstverständlichkeit hier im Foum C++11 angewendet wird.

Ganz einfach: C++11 ist die Zukunft und wenn man rechtzeitig anfängt, sich darauf einzustellen, kann man so schnell wie möglich die Vorteile nutzen.
Klar wird noch viel C++03 angewandt und das ist auch nicht schlimm, aber man muss auch zukunftsbewusst mithelfen, C++11 zu etablieren, schließlich soll sich die Programmierung im allgemeinen weiterentwickeln.

asc

It0101 schrieb:

Wobei der Begriff "schönes C++" ohnehin subjektiv ist.

Gewisse Sachen sind meines Erachtens durchaus sehr gut auf eine Definition zu bringen, unabhängig vom Sprachstandard.

Wichtig ist meines Erachtens in erster Linie die Lesbarkeit (und damit in der Regel auch die Wartbarkeit). Sprich nicht kilometerlange Funktionen, die noch dazu zu viel machen, nicht zu tiefe Verschachtelungsebenen...

Das ist mit RAII beispielsweise häufig leichter zu erreichen als ohne, nicht desto trotz geht es auch ohne RAII und C++11.

Marthog

asc schrieb:

Das ist mit RAII beispielsweise häufig leichter zu erreichen als ohne, nicht desto trotz geht es auch ohne RAII

Jein. Früher bei C ging das in vielen Fällen, in C++ gibt es aber so viele Möglichkeiten, bei denen exceptions geschmissen werden, dass man es meistens gar nicht realisiert.
Andere Programmiersprachen haben keine exceptions, nutzen final-Blöcke, die ja auch Nachteile haben, weil jeder Scope mit Nicht-RAII-Elemente im Grunde ein eigenes try-catch-final braucht, oder verwenden auch RAII.

Wenn man genau weißt, dass keine Exceptions ausgelöst wird, dann kann man schonmal auf RAII verzichten.

Nexus

Marthog schrieb:

Wenn man genau weißt, dass keine Exceptions ausgelöst wird, dann kann man schonmal auf RAII verzichten.

Klar kann man, aber es ist dumm. Exceptions sind nicht der einzige Grund für RAII, mit mehreren Rückgabepfaden hast du genau das gleiche Problem. Wenn man manuell Speicher verwaltet, kommt man sehr schnell in eine Situation, wo man bei jeder kleinsten Änderung der Ablaufpfade genau aufpassen muss. Das braucht nicht nur mehr Entwicklungs- und Debugzeit, sondern führt auch zu unübersichtlicherem Code.

Bedenke, dass du dir bei konsequenter Einhaltung von RAII sogar Checks für Memory-Leaks sparen kannst. Bzw. nur noch auf Low-Level-Klassen, die abgekapselt Speicher verwalten, beschränkst.