Die Leseprobe und der Blick ins Inhaltsverzeichnis hinterlässt einen zwiespältigen Eindruck. Zum einen scheint der Autor eine Vielzahl an wichtigen Themen aufzugreifen; andererseits wirkt das Buch total überladen! Von der einfachen Einführung, über Themen rund herum um die Programmierung (IDEs, Projektverwaltung, usw) bis hin zu Rezepten und einen Überblick über die Standardlibrary. Imho viel zu viel für ein Buch und viel zu viel, um den einzelnen Themen auch nur annähernd gerecht zu werden.
Dazu kommt, dass man dem Buch imho sein Alter anmerkt. Ich denke, dass die "C++11-Überarbeitung" sich oftmals in neuen Abschnitten ausdrückt, statt alte zu streichen oder vollständig zu überarbeiten. Allerdings bleiben andere Abschnitte davon offenbar unberührt. Das könnte zu dem Effekt führen, dass man erst Dinge "falsch" lernt und dann später umlernen muss. Etwas, das ich hasse!
Auch schon beim Umfang der Einführung rattert der Autor (wie so oft in solchen Büchern) alles an Kontrollstrukturen ab, was es so gibt. Wieso zeige ich bei einer while
-Schleife ein Beispiel, bei dem man die Anzahl der Durchläufe schon kennt? Wieso gibt es keinen Hinweis, dass man dafür immer eine for
-Schleife nutzen sollte? Wieso muss man unbedingt eine do...while
-Schleife zeigen? Wer mit dem Buch gelernt hat, sollte später in der Lage sein, dieses Konstrukt selber zu verstehen - oder man packt es in einen Anhang.
Wer möchte sich schon durch zig Seiten quälen, in denen einem jeder atomare Datentyp vorgestellt wird? Ist doch ziemlich sinnfrei! Es reicht kurz zu erwähnen, welche es gibt und die üblicherweise wichtigen für die Beispielprogramme (int, float und std::string) vorzustellen. Andere kann man entweder auch in einen Anhang packen oder diese bei Bedarf (für Beispiele o.ä.) immer mal wieder mit einschieben.
Wieso ist ein std::shared_ptr
für den Autor anscheinend wichtiger als ein std::unique_ptr
? Kann ich nicht nachvollziehen! Aber vielleicht täuscht da die Leseprobe... aber den Abschnitt zu Problemen mit Raw-Pointern (Abschnitt 20.2.18) ist gelinde gesagt lächerlich kurz und wenig aussagekräftig.
Auch das Beispiel zur OO-Analyse ist imho vergeigt. Da wird das veraltete Konzept "Substantiv → Klasse" und "Verb → Methode" angewendet und dann sogar selbst verletzt ("dialog"-Methode 😲 ). Zudem wird das Single Responsability Prinzip verletzt; eine "Manager"-Klasse, die den Datenbestand selber aus einer Datei liest und das auch noch im Konstruktor‽ Das Beispiel ist vollkommen falsch gewählt; aber auch das ist irgend wie typisch für solche Bücher: Kaum hat man Klassen eingeführt, werden anderen Konzepte der Sprache "vergessen" oder ignoriert! Wieso wird nicht einfach eine kleine Factory-Funktion erstellt, die solch eine Personensammlung aus einer Datei läd und ein Exemplar einer PersonalVerwaltung
zurück liefert? Wäre doch ganz einfach gewesen...
Beim Theme OOP fehlt vermutlich der Hinweis auf OO-Prinzipien und Design-Pattern - vielleicht tue ich dem Autor aber auch Unrecht. Dass Polymorphie - imho das wichtigste Konzept der OOP - offenbar viel zu kurz kommt, erscheint mir das aber als sehr wahrscheinlich.
Zum Thema Zeichenkodierung scheint es nicht spezielles zu geben; schade, muss man sich doch gerade als C++-Programmierer mit dem Thema eher auseinander setzen, als bei anderen Sprachen, die das ganze bis zu einem gewissen Grad, vor dem Programmierer verbergen.
Wieso werden Pointer auf Funktionen und Lambda-Ausdrücke nicht im vorderen Teil besprochen?
Löblich sind natürlich Themen wie Unittesting - ob man wirklich das sperrige Boost.Test-Framework nutzen musste, sei mal dahingestellt. Hoffentlich nennt der Autor mögliche Alternativen (googletest bzw. googlemock oder das insbesondere für Anfänger zu empfehlende Catch) oder weist darauf hin, dass der Leser sich selber nach aktuellen Libs umsehen sollte.