Wie lernt man gutes C++ zu schreiben?

dachschaden

Gast3 schrieb:

hört sich für mich eben nach goto + kleine #ifdef-Party in 2 Funktionen an - und das ist an sich auch nicht so schön

Klein ist da nicht wirklich was, die Initialisierungsfunktion ist 300 LOCs groß, die rekursive Funktion 200 LOCs. 50 LOCs einfach mal komplett entfernen zu können ist da schon was. Zumal man dann auch weiß, wo man nach Speicherlecks zu suchen hat.

Gast3 schrieb:

ich hab hier auch eine solche Funktion(en) nur eben für 5 Platformen (Win,Linux,WinCE,Solaris und VxWorks) und habe auch schöne Fehlerbehandlung/Verarbeitung…

Zeigen.

Gast3 schrieb:

das ganze ohne Redundanz, goto und viele #ifdefs

Zeigen. Ich verwende das WinAPI für Windows ( FindFirstFile , FindNextFile ) und das Directory-API für Linux ( opendir , readdir - was eigentlich auch alle POSIX- und BSD-Systeme einbezieht, nur hab ich's da halt nicht getestet), da verwende ich keine externe Library, die wieder Schindluder treiben könnte. Den Pfad baue ich über einen Buffer, die über die komplette Rekursion mitübergeben wird, um den für die derzeitige Ausführung wichtigen Pfadteile bauen zu können. Und der Grund, warum ich dies über eine zweite Funktion mache, ist um den Footprint auf den Stack zu verringern, weil sonst jede Ausführung wieder ein bisschen was vom Stack wegfrisst. Und natürlich in C, nicht C++.

Wenn du das toppen kannst, bei aller Liebe - korrigiere mich.

Gast3 schrieb:

WEIL ich sonst keine sauberen Test mit 100% Coverage dafür schreibe kann - ohne das mir die Hände bluten

Wieso dat denn? Noch nie was von Error-Codes gehört, auf die man prüfen kann, ob ein spezieller Test jetzt fehlgeschlagen hat? Oder übersehe ich da nur grad fett was?

Gast3 schrieb:

aber dein Code ist bestimmt trotzdem nicht so schlecht wie ich es habe klingen lassen

Um meinen Code geht es mir dabei eigentlich gar nicht mal so. Sondern dass goto ein mächtiges Werkzeug ist, welches deinen Code besser lesbar machen kann. Das heißt ja nicht, dass man es auch dann verwenden soll, wenn es keinen Sinn ergibt.

Ach, und das ist ja nicht das einzige Beispiel gewesen. Ich habe hier einen Webcrawler mit rund 30 Fehlerpfaden, von denen einige kritisch, andere nicht so kritisch sind. Da nicht goto für Sub-Funktionen zu verwenden bringt einen so dermaßen in eine Welt des Schmerzes, dass ich über Alternativen gar nicht erst nachdenken will.

Andromeda schrieb:

Der Mensch hat irgendwie einen Hang dazu, alles zu verallgemeinern. Dadurch fühlt er sich schlauer als die anderen. Doch Hinzufügen von Komplexität ist selten gut.

Kommt darauf an, sage ich. Einige Konzepte von C++ sind definitiv gut gemeint. Aber meines Erachtens wurde versucht, zu viel Kontrolle aus der Hand des Programmierers zu legen.

Jetzt stellt sich mir die Frage, ob es nicht leichter ist "gutes" C anstellen von "gutem" C++ zu lernen?

Ich habe mich ein wenig querbeet dazu eingelesen und mir stellt sich die Frage: Braucht man fest eingebaute Klassen in einer Sprache um jeden Preis, oder reicht es nicht einfach aus mit Strukturen, und Funktionen die damit arbeiten, was zu bauen? Also reicht C nicht völlig aus? Sind die Fehler die mit C gebaut werden schwerer zu finden als die die man mit C++ oft macht? Sind die vielen Präprozessoranweisungen, Callbacks, Voidzeiger und Gotos wirklich soooo übel im Vergleich zu dem was man mit C++ verbocken kann?

Gibt es überhaupt eine Programmiersprache die man heute wirklich für fast alles empfehlen kann. Ich bin echt total unentschlossen was die Sprache angeht. Soll ich mir das wirklich antun? Habe ich überhaupt eine Chance je C++ richtig zu lernen?

dachschaden

GoodCpp schrieb:

Jetzt stellt sich mir die Frage, ob es nicht leichter ist "gutes" C anstellen von "gutem" C++ zu lernen?

Persönliche Meinung: Ja.
Aber: ich habe irgendwann aufgegeben, C++ zu lernen, ich bin also möglicherweise nicht qualifiziert dafür, darüber zu schreiben. Auf der anderen Seite habe ich bei C nicht aufgegeben ...

GoodCpp schrieb:

Also reicht C nicht völlig aus? Sind die Fehler die mit C gebaut werden schwerer zu finden als die die man mit C++ oft macht? Sind die vielen Präprozessoranweisungen, Callbacks, Voidzeiger und Gotos wirklich soooo übel im Vergleich zu dem was man mit C++ verbocken kann?

Das kommt darauf an, was du machen willst. Es gibt ein paar Bibliotheken da draußen, die nur ein C++-Interface exportieren, das kannst du dann nur über ekeligen Glue-Code ans Laufen bekommen. Habe ich mal gemacht, als Spaßprojekt für die Irrlicht-Engine.

Aber an sich reicht C so für alles aus, was du machen willst. Manchmal sogar logischer als in C++. In C hast du einfach mehr Kontrolle über das, was du machen willst, während dir diese Kontrolle in C++ abgenommen wird. Das ist nicht notwendigerweise etwas schlechtes, weil da draußen auch nicht die besten Leute programmieren. C fängt da halt nichts ab, C++ schon. Dafür fängt C halt auch nichts ab, wenn du gerade genialen Code schreibst, der in C++ über zig Klassen gelöst werden würde.

Aber auf der anderen Seite - wie wahrscheinlich ist es, dass du genialen Code schreibst?

GoodCpp schrieb:

Gibt es überhaupt eine Programmiersprache die man heute wirklich für fast alles empfehlen kann. Ich bin echt total unentschlossen was die Sprache angeht. Soll ich mir das wirklich antun? Habe ich überhaupt eine Chance je C++ richtig zu lernen?

Da kannst du genauso fragen, ob es nicht ein Werkzeug gibt, welches bei der Schreinerei fast alles machen kann. Nein, gibt es nicht. Jede Sprache hat Vor- und Nachteile.

Und ich kann dir nicht sagen, welche Programmiersprache die beste ist. Weil es kein "Bestes" gibt.
Aber vielleicht hilft dir das hier bei der Entscheidung. Vielleicht solltest du dich auch gar nicht festlegen, erst mal ein bisschen Python oder Perl lernen. Ein Gespür dafür bekommen, was Programmieren eigentlich bedeutet. Später kannst du dann immer noch C oder C++ in Angriff nehmen.

Werner Salomon

manni66 schrieb:

GoodCpp schrieb:

Noch eine Frage an diejenigen die schon eine Weile auf dieser Reise sind. Wie lange braucht es im Durchschnitt um gutes C++ zu lernen?

Ein Leben lang.

Nach ein paar Jahren bist du vielleicht kein Grünschnabel mehr ...

GoodCpp schrieb:

Ist das wirklich so heftig?

Ja

GoodCpp schrieb:

Wenn dem so wäre, dürften nur extrem wenige gutes C++ beherrschen ...

Ja

GoodCpp schrieb:

... und das wäre ein Desaster für so ziemlich jedes C++-Projekt da draußen.

Ja ...

na ja - nicht ganz. IMHO haben viele Leute in den vergangenen Jahrzehnten gelernt, wie man auch größere Software-Projekte stemmt. Und auch viele Entwickler haben 'ihren Stil' gefunden, was vielleicht nicht das schönste und modernste C++ ist, aber einfach funktioniert und einigermaßen sicher und wirtschaftlich ist.

GoodCpp schrieb:

Also jetzt mal im ernst. Wenn jemand schon programmieren gelernt hat, welche Zeit sollte er mindestens einplanen um guten C++ zu beherrschen?

ca. 10 Jahre - so wie bei den meisten Dingen, für die man wirklich Kompetenz entwickeln will - siehe http://www.purl.org/stefan_ram/html/21-tage.

Wobei es IMHO extrem hilfreich ist, wenn man ein Talent für Mathematik hat! Das gilt für Programmieren im Allgemeinen und für C++ erst recht.
Umgekehrt wird auch ein Schuh draus. Wenn Du Dich mit Mathe wirklich schwer tust, wirst Du nie gute C++-Programme schreiben können (ist meine persönliche Meinung).

Gruß
Werner

die frage sollte doch eher heißen, wie man lernt, schlechtes C++ zu vermeiden.

was ist schlechtes C++?
schlechtes C++ kompiliert nicht.
schlechtes C++ enthält "undefiniertes verhalten".
schlechtes C++ enthält bugs, die dazu führen, dass ein programm abbricht.
schlechtes C++ enthält bugs, die manchmal dazu führen, dass ein programm abbricht.
schlechtes C++ enthält bugs, die selten dazu führen, dass ein programm abbricht.
schlechtes C++ enthält bugs, die dazu führen, dass sich ein programm nicht so benimmt, wie man als entwickler will.
schlechtes C++ enthält bugs, die dazu führen, dass sich ein programm nicht so verhält, wie es ein benutzer will.
schlechtes C++ ist schlecht lesbar.
schlechtes C++ ist schwer verbesserbar.
schlechtes C++ ist langsam.
schlechtes C++ ist frustrierend.

dann gibt es noch eine einfache regel:
je mehr C++ man schreibt, desto mehr schlechtes C++ schreibt man. (klar, denn: wer am schnellsten läuft, kommt auch als erstes ans ziel)

gutes C++ zeichnet sich vor allem dadurch aus, dass die oben angeführten dinge fehlen.

Mein Bauchgefühl sagt mir, ich sollte meine Zeit nicht mit dem Lernen von "gutem" C++ vergeuden. Ich danke euch für die rege Teilnahme und die beantwortungen meiner bestimmt sehr merkwürdigen Fragen.

Mein Ziel war irgendwann mal Grafik- und und Audioprogramme zu schreiben. Aber das ist den ganzen Aufwand mir dann doch nicht wert. Ich werde weiterhin lieber schon vorhandene Programme nur benutzen und vielleicht mal ein wenig scripten.

Ich danke für eure Zeit.

Naja, man kann auch den umgekehrten Weg gehen: beherrsche dein Grafik-/bzw. Audiotoolkit und lerne nur genau so viel C++, dass du es benutzen kannst. Ich kenne mich zum Beispiel im Grafikbereich ziemlich genau gar nicht aus.

Aber wenn du dir z.B. mal die Tutorials zu Cinder oder Irrlicht anschaust und guckst, ob du damit klarkommst, dann wär's doch auch gut.

Vielleicht wäre C++ dann nur nötiges Zusatzwissen, um diese Bibliotheken zu benutzen. Dazu braucht man sich z.B. nicht mit Template-Metaprogrammierung auszukennen.

Andromeda

GoodCpp schrieb:

Mein Bauchgefühl sagt mir, ich sollte meine Zeit nicht mit dem Lernen von "gutem" C++ vergeuden.

Jein, - wenn du ein bestimmtes Ziel anvisierst, zu dessen Erreichung du unbedingt C++ nehmen willst, dann können dir C++-Detailkenntnisse sehr nützlich sein. Du musst dir einfach Zeit nehmen, lernen und üben, bis du genügend C++ kannst.

Kann aber auch sein, dass du bei C++ eine flachere Lernkurve hast als bei anderen Sprachen. Aber hey, vor die Programmiererei hat der Liebe Gott immer das Lernen gesetzt.

volkard

dachschaden schrieb:

Ich habe C gelernt. Heftig C gelernt. Die letzten 8 Jahre. C ist weniger komplex als C++, aber ein paar Sachen hast du in beiden Sprachen halt so drin.

Ich finde noch heute Sachen in meinen Codes von vor 9 Monaten, wo ich mich frage, was zum Teufel ich mir dabei gedacht habe. Vielleicht bin ich in der Hinsicht aber auch nur Nazi.

Nee. Nee. Du musst lebenslang Code-Nazi gegen Dich selber bleiben.

dachschaden schrieb:

void foo()
{
    if(bla)
    {
        /*Code*/
        /*Mehr Code*/
        /*Ganz viel Code*/
        /*Coooooooooode*/
    }
    else
    {
        return;
    }
}

Würde ich so einen Code bei einem Audit sehen, würde ich fragen, welcher Suffkopp das so geschrieben hat.

void foo(void)
{
    if(!bla)
        goto END;

    /*Code*/
    /*Mehr Code*/
    /*Ganz viel Code*/
    /*Coooooooooode*/

END:
    return;
}

In allen Sprachen gilt: return ist stärker als if. Es drückt direkt mal aus, was auszudrücken war.

dachschaden schrieb:

Und das sage ich dir, der C macht statt C++. C++ ist noch mal eine Ecke komplexer.

Naja, manchmal auch einfacher.

void foo()
{
    if(bla)
    {
        /*Code*/
        /*Mehr Code*/
        /*Ganz viel Code*/
        /*Coooooooooode*/
    }
    else
    {
        return;
    }
}

macht man zu

void foo(void)
{
    if(!bla)
        return;

    /*Code*/ //egal, welche Ressourcen, die Destruktoren geben sie zeitnah frei. 
    /*Mehr Code*/
    /*Ganz viel Code*/
    /*Coooooooooode*/
}

Also um in C die Richtung Sofort-Return-Wenn-Ergebnis-Feststeht einzuschlagen, muss man über seinen Schatten springen. C++ bettelt quasi darum, daß man es sofort macht.

Ich mache sehr gute Erfahrungen damit, daß ich in allen Sprachen C++ schreibe¹, und dabei C++ nicht als Sprache verstehe, sondern als bis ins extremste übertriebenen (und stets an C++ angelehnten, wenns um konkrete Implementierungen geht) Programmierstil, der dafür sorgt, daß möglichst viele Fehler den eigenen Schreibtisch nicht verlassen.

¹ Gerne auch bis runter zu ASM oder hoch zu Lisp, die sind sehr verkuschelt gegenüber brutal fehlervermeidendem Stil: sie danken es ebenso Zeichen für Zeichen wie die anderen. Allein in Brainfuck habe ich das Problem, daß ich es nicht über Forth heben kann.

dachschaden

volkard schrieb:

Nee. Nee. Du musst lebenslang Code-Nazi gegen Dich selber bleiben.

Habe nicht gesagt, dass ich aufhören werde, Code-Nazi zu sein. :p

volkard schrieb:

In allen Sprachen gilt: return ist stärker als if. Es drückt direkt mal aus, was auszudrücken war.

Lies dir mal die Diskussion bezüglich Ressourcenfreigabe auf der vorherigen Seite durch. Das, was ich da geschrieben habe, war jetzt minimaler Beispielcode. In der Realität mache ich vor dem goto das Setzen eines Fehlercodes, dann muss an der Stelle, zu der ich springe, Ressourcen freigegeben werden, dann muss im Debugmodus der Error-Code auf der Konsole ausgegeben werden. Da bin ich pro Fehlerpfad mit 5 Zeilen+ dabei. Implementiere so was mal in einem Zero-Copy HTTP-Parser, oder einem MZ-/PE-/ELF-Parser, in dem du etliche Fehlerquellen hast, und sage mir, dass ein direktes return besser ist.

Nein, brauchst du nicht, ich habe es bereits gemacht.
Wenn ich nicht aus Erfahrung sprechen könnte, würde ich hier gar nicht erst was schreiben.

volkard schrieb:

Also um in C die Richtung Sofort-Return-Wenn-Ergebnis-Feststeht einzuschlagen, muss man über seinen Schatten springen. C++ bettelt quasi darum, daß man es sofort macht.

Selbst dann noch habe ich die Ausgabe des Error-Codes, der ein paar Zeilen kostet (die verstecke ich aber hinter einem Makro, bläht den Code also nicht so sehr auf). Ressourcenfreigebung ist dann nicht mehr das Argument, aber du hast eventuell immer noch Code, der bei jedem return ausgeführt werden soll.

Wenn das dann allerdings auch nicht mehr gegeben ist, dann hast du recht; return ist direkter und bringt es auf den Punkt.

EDIT: Rechtschreib- und Satzbaufehler.

volkard

dachschaden schrieb:

…

Wir beide ziehen doch zu 100% am selben Strang und in der selben Richtung.
Schau Dir dein Posting vielleicht noch mal in neun Monaten an.