“Der C++ Programmierer“ schwierig?



  • Ich weiß der Thread ist schon ne Weile her, aber ich wollte auch mal meinen Senf dazu geben:

    Ich finde es überhaupt nicht schlimm, sogar normal, wenn man beim Durcharbeiten eines (C++) Buches Dinge nicht auf Anhieb versteht. Vor allem, wenn man allgemein mit dem Programmieren erst anfängt. Ich persönlich musste bei meinem ersten Buch einige Kapitel mehrmals durchgehen, bevor ich den Inhalt komplett verstanden hatte und anwenden konnte.

    Das Zeug lernt man nicht über Nacht. Gib Dir ein paar Jahre Zeit... Die Personen hier wo sich richtig gut auskennen beschäftigen sich bestimmt auch schon länger mit der Materie. Also mach Dir keinen Stress. Du kannst das Buch auch mal weglegen, Dich mit eigenen Projekten beschäftigen und ein paar Wochen/Monate später nochmals damit anfangen. Wichtig ist nur, dass man am Ball bleibt.



  • Ich habe auch einen Versuch C++ zu lernen vor ein paar Jahren mit "Der C++ Programmierer" angefangen. Das Buch lesen und C++ lernen funktionierte bei mir nicht. So schnell ich da was gelernt habe, so schnell war das Wissen auch wieder weg. Und bei dem meisten Zeug wusste ich nicht wozu das überhaupt jemals gut sein soll.

    Erst jetzt, wo ich ein reales GUI Projekt angefangen habe, beginne ich richtig zu lernen und zwar nicht durch lesen des Buches als erstes, sondern aus Fehlern, die ich mache, Zum Ausbügeln der Fehler recherchiere ich im Web und lese mir Hintergrundinfos im Buch an.

    Für mein Projekt reicht mir ca 2% der Sprache. Mein Ziel ist es aber auch nicht das so elegant wie möglich zu programmieren(das kann ich eh nicht), sondern das Projekt überhaupt zum funktionieren zu bringen. Wenn alles fertig ist, kann ich analysieren was ich hätte besser machen können und dann fange ich die Sache vielleicht noch mal von vorne an oder nutze das Wissen für ein anderes Projekt. Vielleicht probieren ich auch, das Projekt mal in anderen Sprache umzusetzen und zu schauen was besser, was schlechter läuft.

    tldr;
    C++ nur aus einem Buch zu lernen funktionierte bei mir nicht.



  • nur durch lesen des buches kann niemand lernen. es gehört immer dazu, a) die übungsaufgaben zu programmieren und b) zu experimentieren.



  • Jein, also allein von abstrakten Übungsaufgaben habe ich nicht viel behalten. Am besten festigt sich Wissen bei mir wenn ich konkret an einem praktischen Problem fest hänge und dann irgendwann zur Lösung komme, damit das Projekt weiter geht. Aber das mag bei jedem anders sein. C++ sollte man meiner Meinung nach immer an Projekten lernen, gleich von Anfang an.

    C++ empfinde ich schon als extreme Herausforderung und hätte ich die Wahl, würde ich was anderes nehmen. Aber so was wie Qt und dann noch extrem performant gibt es nur in Verbindung mit C++, leider leider leider also muss man da durch.



  • ja also wenn die aufgabe lautet, dass man eine zahl einlesen und dann entweder "die zahl ist gerade" oder "die zahl ist ungerade" oder "die zahl ist gar nichts" ausgeben soll, dann hat das den zweck, die verwendung von verzweigungen einzuüben. man arbeitet keine 10 kapitel am tag durch, sondern eher so ein kapitel pro woche, bis man die übungsaufgaben auswendig kann.

    @chris4cpp sagte in “Der C++ Programmierer“ schwierig?:

    Aber so was wie Qt und dann noch extrem performant gibt es nur in Verbindung mit C++, leider leider leider also muss man da durch.

    nimm doch die windows-api, wenn es performant sein soll. das geht auch mit C.



  • Ja, bei so ganz simplen Basics wie Schleifen, Verzweigungen, etc. gebe ich dir ja Recht. Das ist ganz schnell erklärt. Aber so Sachen wie OOP mit all den Möglichkeiten der Übergabe und dem Management von Objekten, das ist doch ein ganz anderer Schuh. Dann die oft kryptischen Compiler Fehlermeldungen, das ist schon hart. Erst Google spuckt dann irgendwann aus was wirklich los ist.

    WinAPI und C, funktioniert dann nur unter Windows. Ich hätte das schon gern Crossplattform.

    Rust mit Qt wäre vielleicht was schönes.



  • @chris4cpp sagte in “Der C++ Programmierer“ schwierig?:

    Ja, bei so ganz simplen Basics wie Schleifen, Verzweigungen, etc. gebe ich dir ja Recht. Das ist ganz schnell erklärt. Aber so Sachen wie OOP mit all den Möglichkeiten der Übergabe und dem Management von Objekten, das ist doch ein ganz anderer Schuh. Dann die oft kryptischen Compiler Fehlermeldungen, das ist schon hart. Erst Google spuckt dann irgendwann aus was wirklich los ist.

    stufe 1: objektorientierte modellierung lernen
    stufe 2: c++ lernen

    andersherum geht natürlich auch, aber wie willst du vernünftig vererben, wenn du eigentlich gar nicht richtig weißt, was vererbung eigentlich ist?

    WinAPI und C, funktioniert dann nur unter Windows. Ich hätte das schon gern Crossplattform.

    ich bin nicht so der linux-fan, also für unix würde ich eher ncurses benutzen. 😃



  • Hehe Ncurses, da lief damals unser Backend für die Webentwicklung mit. Heute würde man Application Layer oder so dazu sagen. Ne ich brauche leider eine richtige GUI, bei mir läuft Audio und Grafik in Echtzeit. Wenn da irgendwas zickt oder unnötig kopiert wird etc. merke ich das sofort an Aussetzern oder höhere CPU-Last.

    Ich nutze nicht sooo viel Vererbung, nur wenn es unbedingt nötig ist. Mein komplexestes ist ein Observer Pattern was ich für meine Logger Klasse nutze. Ansonsten nutze ich OOP nur als Kapselung von Daten und Methoden. Bei einer Klasse arbeite ich mit Vererbung einer abstrakten Basisklasse(also alle Methoden sind virtuell und ich spreche dann die abgeleiteten Objekte per Polymorphie an)

    Ansonstn wie gesagt so wenig OOP wie möglich. Nichts ist schlimmer als sich später durch ein Gedöns an Klassen wurschteln zu müssen um durchzublicken was passiert. Lieber auf Eleganz verzichten und dafür lesbaren Code erhalten.



  • @chris4cpp sagte in “Der C++ Programmierer“ schwierig?:

    Ne ich brauche leider eine richtige GUI, bei mir läuft Audio und Grafik in Echtzeit. Wenn da irgendwas zickt oder unnötig kopiert wird etc. merke ich das sofort an Aussetzern oder höhere CPU-Last.

    Ich bin mir nicht sicher ob ich dich richtig verstehe, aber... was hat das mit der GUI zu tun? Grundsätzlich sollte das Audio-Gedöns in einem eigenen high-priority Thread laufen. Und der sollte idealerweise nur non-blocking mit anderen Threads kommunizieren. Bzw. wenn man doch mal was locken muss dann:

    • kurz halten (in allen Threads)
    • in allen non-audio Threads die die selbe Mutex locken müssen die Prio vorher auf die des Audio-Threads anheben (und nach dem Unlock natürlich wieder rückgängig machen)

    Die GUI darf dann zicken und CPU fressen wie sie lustig ist, Aussetzer darf das keine verursachen.

    Ansonstn wie gesagt so wenig OOP wie möglich.

    Ich glaub du hast ne komische Vorstellung davon was OOP bedeutet. OOP != sinnlos rumvererben.



  • Die GUI erwähnte ich weil von Ncurses gesprochen wurde.

    Wie man das sonst löst weiß ich nicht. Ich mache das so, wie ich denke, dass es funktionieren könnte und das tut es auch. Eigene Threads nutze ich bis jetzt nicht, da kein Bedarf. Ich habe eine Crossplattform Audiolib RTAudio, der ich eine Callback Funktion, mit dem zu füllenden Soundbuffer, übergebe. Ich glaube, dass die Audiolib einen Thread nutzt. Ab da an mache ich alles selbst, also das Audioprocessing. Die GUI arbeitet mit Qt. Sobald irgendwas nicht rund läuft höre ich das als Knackser / Aussetzer etc. und sehe das auch an der CPU Last, da konnte ich schon einige unnötige Kopien von Objekten vermeiden.

    Ist ein großes Lernprojekt, was bestimmt noch ein Jahr dauern wird bis es fertig ist. Am Ende weiß ich was ich alles von C++ und OOP brauche und auf was ich getrost verzichten kann.

    Ich habe eine komische Vorstellung von OOP? Bitte kläre mich auf warum. Ich setze von OOP folgendes derzeit ein:

    • Kapselung von Daten und Methoden und deren Sichtbarkeit
    • Polymorphie. also Basisdatentyp aufnehmen und je nach konkreter abgeleiteten Klasse werden dann die spezifischen Methoden aufgerufen.
    • Observer Pattern(was ja Kapselung und Polymorphie einsetzt)
    • RAII z.B. in der Loggerklasse um ein Filestream wieder zu schließen. Vorher hatte ich noch RAII mit new im Konstruktor und delete im Destruktor. Das ist komplett weg und ich nutze nur noch Smartpointer und std::array

    Mehr nutze ich von OOP nicht. Ich habe mir auch vorher keinerlei Plan gemacht wie die Objekte miteinander kommunizieren. Was ich brauche und wie was miteinander kommuniziert hat sich ,während des Projekt wuchs, ergeben. Alles so einfach und übersichtlich wie möglich und weniger auf alle möglichen späteren Erweiterungen ausgelegt.

    Mein Ziel ist es mit meinem Kenntnisstand so schnell wie möglich etwas funktionierendes zu entwickeln, wo ich nicht den Überblick verliere. Bis jetzt ist das rund 500kb Quellcode und alles funktioniert wie gewünscht. Wenn ich an Grenzen stoße muss ich selbstverständlich meine Art an das Projekt, C++ oder OOP ran zu gehen ändern, aber bis hierhin ist alles recht machbar.

    Aber bitte man lernt ja nie aus. Was ist an meiner Auffassung von OOP komisch? (Weil ich nur einen Bruchteil davon nutze?)


Log in to reply