Existiert schönes C++ in der Praxis?

[Marthog]

nwp3 schrieb:

Ich meine mal den Vorschlag gehört zu haben, dass Programmiere in den ersten 5 Jahren keine eigenen Projekte anfangen dürfen. Nachdem sie 5 Jahre unter miserablem Code leiden mussten schreiben sie ordentlichen.

Ich habe bei mir die Erfahrung gemacht, dass es sich durchaus lohnt, Projekte anzufangen, solange man sich jederzeit der Tatsache bewusst ist, dass man es wahrscheinlich nicht schafft. Solange man ein Ziel vor Augen hat, arbeitet man motiviert weiter. Irgendwann kommt man an den Punkt, dass man es einfach nicht mehr weiterschafft. Dann erkennt man seine Fehler und bemerkt, dass z.B. modularer Aufbau hilft, die Übersicht zu wahren, dass man sich bei exceptions die andauernden Abfragen error-flag-abfragen spart, dass RAII die Aufräumblöcke erspart, vor allem wenn es mehrere returns gibt.
Man darf als Programmierer natürlich nicht zu sehr am Projekt hängen. Ich habe mein erstes 2 weitere Male völlig von vorne angefangen und es letztendlich doch aufgegeben, weil ich eingesehen habe, dass es viel zu viel Arbeit ist, es mich nicht mehr interessiert und im Grunde eine blöde Idee ist, aber ich bereue das überhaupt nicht, denn ich habe dabei die ganze Sprache von Anfang an gelernt.

[Skym0sh0]

nwp3 schrieb:

Jetzt, wo ich deutlich mehr Plan habe könnte ich alles viel besser, aber nun ist der Code wie er ist und einen Monat (Zeit ist geraten) mit "Codeaufhübschung" zu verbringen kann ich nicht rechtfertigen.

Ich hab mal irgendwo gelesen, dass jeder erste Entwurf inklusive der ersten Umsetzung, die Probe ist. Danach sollte man eigentlich nochmal die ganze Software neu aufbauen, weil man nun weiß, was wie wo verlangt ist und wie das umgesetzt werden kann.

Nachteil: Das ist absolut nicht praktikabel. Z.B. 2 Jahre etwas entwickeln und danach dasselbe innerhalb von 6 Monaten neu zu schreiben ist aus betriebswirtschaftlicher und zeitlicher Sicht nicht machbar.

[otze]

Skym0sh0 schrieb:

Nachteil: Das ist absolut nicht praktikabel. Z.B. 2 Jahre etwas entwickeln und danach dasselbe innerhalb von 6 Monaten neu zu schreiben ist aus betriebswirtschaftlicher und zeitlicher Sicht nicht machbar.

Wenn du das Projkt die nächsten 10 Jahre warten musst, dann schon.

[Bashar]

Hat das wirklich mal jemand gemacht? Ein 2jähriges Projekt wegwerfen und komplett neumachen? Schafft man das wirklich in 6 Monaten? Und wird es wirklich besser?

[tntnet]

Mechanics schrieb:

Eisflamme schrieb:

mit typedef s und auto kommt man doch ganz gut klar, finde ich. Und bei den ganzen unique_ptr -Einsätzen spart man sich doch auch das delete an Schreibarbeit.

Allein das ist schon etwas praxisfern. Wie lange gibts C++11 schon? Noch nicht so lang. Im Gegensatz dazu gibts viele C++ Projekte schon seit Jahrzehnten. Wir benutzen in der Arbeit kein C++11 (und keinen C++11 fähigen Compiler) und es wird sicher noch Jahre dauern, bis wir umsteigen. Und irgendwie hab ich das Gefühl, als ob jetzt alle so tun würden, als ob C++ erst mit C++11 eine schöne Sprache geworden wäre, obwohl sie auch davor immer C++ Fans waren.
Ansonsten hab ich mich natürlich auch schon öfter gefragt, warum man in der Praxis so wenig schönen C++ Code findet. Ich könnte wahrscheinlich tausend Gründe finden, warum unser Code nicht besonders schön ist und warum ich ihn trotzdem ganz brauchbar finde, aber mich würd trotzdem mal interessieren, warum die meisten anderen keinen schönen Code schreiben ^^

Da kann ich nur voll zustimmen. Bis Du zufällig ein Kollege von mir ? Auch wir haben kein C++11 und werden es lange nicht haben. Und auch ich denke, dass C++ vor C++11 auch eine großartige Sprache war. Sicher ist C++11 ein Fortschritt. 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. Die meisten Projekte haben lange vor C++11 angefangen.

[SeppJ]

Bashar schrieb:

Hat das wirklich mal jemand gemacht? Ein 2jähriges Projekt wegwerfen und komplett neumachen? Schafft man das wirklich in 6 Monaten? Und wird es wirklich besser?

Zwar nur an einem Projekt, das ich größtenteils alleine betreue, aber ja: Ein 5 Jahre altes Projekt nach Übernahme erst ein halbes Jahr verschlimmbessert, bis ich einsah, dass es unwartbar war. Dann alles weggeworfen und in ein paar Monaten alles sauber neu gemacht, mit mehr Features und einem Code, den ich selbst heute noch (ein paar Jahre später) nur kurz ansehen muss, um ihn zu verstehen.
War eine gute Entscheidung. Hätte ich gleich so machen sollen.

[Bashar]

Hm, Respekt. Aber ich meinte eigentlich, was selbstentwickeltes wegzuwerfen und selbst neu zu machen.

[It0101]

Marthog schrieb:

Es gibt ja sogar noch Leute, die Strings mit strcmp, strcpy etc bearbeiten.

Unglaublich, dass es sowas gibt... Aber das lässt sich wohl nicht vermeiden. Bisher hat man es in der STL nicht mal hinbekommen einen std::string Konstruktor für die fstreams zu basteln.

Von Sockets und anderen lustigen Dingen ( ja, ich weiß, die sind nicht Teil der STL ), mal ganz zu schweigen...

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. Seit den Shared-Pointern ist es wieder etwas leichter, weil man die auch mal ohne Kopfschmerzen in einen Container kopieren kann ( in den STL-Container ist ja praktisch immer alles mit Kopieroperationen verbunden ), während man es vielleicht mit dem Objekt selbst nicht tun wollen würde.

Es vergeht kein Tag wo ich nicht Gott ( in case he exists ) für die Shared_Pointer ( und die anderen ) danke

[manni66]

It0101 schrieb:

Unglaublich, dass es sowas gibt... Aber das lässt sich wohl nicht vermeiden. Bisher hat man es in der STL nicht mal hinbekommen einen std::string Konstruktor für die fstreams zu basteln.

It0101 schrieb:

in den STL-Container ist ja praktisch immer alles mit Kopieroperationen verbunden

Du solltest dir vielleicht mal den aktuell gültigen Standard ansehen

[It0101]

Hmm falls sich da inzwischen was getan hat, sollte ich mir den wirklich mal ansehen Wurde ja wirklich mal Zeit. Die fstream-Konstruktoren waren ja schon fast peinlich

[nwp3]

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.

So geht es mir mit boost.
Q: Wie löse ich ein Problem?
A: Benutze boost::solve::problem.

It0101 schrieb:

Marthog schrieb:

Es gibt ja sogar noch Leute, die Strings mit strcmp, strcpy etc bearbeiten.

Unglaublich, dass es sowas gibt... Aber das lässt sich wohl nicht vermeiden.

Ich benutze bei nicht-trivialen Anwendungen immernoch fprintf und fscanf. Diese Funktionen sind so viel einfacher und mächtiger als die istringstream-Varianten (nicht wieder löschen bitte ). Und jedesmal wenn ich mir vornehme es doch nochmal zu versuchen kommt Werner und klatscht mir nen 1000-Zeilen-Template vor die Nase, wo sowohl ich, als auch mein Compiler nur noch Syntaxerror schreien (Scheiß VS2010).

[SeppJ]

Bashar schrieb:

Hm, Respekt. Aber ich meinte eigentlich, was selbstentwickeltes wegzuwerfen und selbst neu zu machen.

Nun, prinzipiell auch. Aber das was ich das erste Jahr lang mit C++ produziert habe, kann man zum Glück nicht als richtiges Projekt bezeichnen, sondern nur als kleine Hilfsprogramme^*. Aber die habe ich ebenfalls mit Freude weggeworfen und die Nachfolger benutze ich heute noch.

^*: Denn zum Glück ahnte ich schon, dass dieser Tipp richtig ist:

nwp schrieb:

Ich meine mal den Vorschlag gehört zu haben, dass Programmiere in den ersten 5 Jahren keine eigenen Projekte anfangen dürfen. Nachdem sie 5 Jahre unter miserablem Code leiden mussten schreiben sie ordentlichen.

Mag für große Projekte 5 Jahre sein, aber gilt allgemein für alle Programme im ersten Jahr, dass die nur zur Übung taugen (was wichtig ist!) und danach als schrottreif gelten können.

[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.

[upvote]

[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.