Fashion Sale Hier klicken Strandspielzeug calendarGirl Cloud Drive Photos Philips Multiroom Learn More sommer2016 fissler Hier klicken Fire Shop Kindle PrimeMusic Lego Summer Sale 16

Kundenrezensionen

2,3 von 5 Sternen4
2,3 von 5 Sternen
5 Sterne
1
4 Sterne
0
3 Sterne
0
2 Sterne
1
1 Stern
2
Format: Kindle Edition|Ändern
Preis:28,00 €

Ihre Bewertung(Löschen)Ihre Bewertung
Sagen Sie Ihre Meinung zu diesem Artikel

Derzeit tritt ein Problem beim Filtern der Rezensionen auf. Bitte versuchen Sie es später noch einmal.

am 16. Dezember 2013
Der Autor springt "als Guru" wild durch die C Programmiersprache. Er schreibt ständig, was in anderen Büchern stehen würde und kommt dann zu seinen eigenen Ideen.
So schlägt er beispielsweise vor, statt Enumerationen Strings zu verwenden. Statische Typsicherheit erachtet er als unwichtig.
Statt dem int-großen enum-Datentyp schlägt er als Ersatz char vor, da "bei einem char nur 8 [Bits] verglichen werden müssen". Das soll geschwindigkeitseffizienter sein!
Er schlägt vor, ein .h File mit allen Includes des Projektes zu inkludieren, ohne zirkuläre Referenzen zu erwähnen. Ständig stolpert man über solche wilden Konstrukte.
Am schlimmsten, weil gefährlich, finde ich die Aussage (zum Thema valgrind), dass man "ein Speicherleck unter 100 KByte als unwichtig ansehen und es ignorieren" soll. Natürlich gibt es einen Grund: Die Zeit zur Suche nach einem Fehler dauert länger als die Auswirkung eines Fehlers normalerweise auf die "Effizienz des Programms" hat.
Mich wundert und enttäuscht, dass ein Verlag wie O'Reilly ein solches Buch publiziert, und ich hoffe, dass möglichst wenige Leser den Inhalt des Buches unkritisch übernehmen.
11 Kommentar|27 Personen fanden diese Informationen hilfreich. War diese Rezension für Sie hilfreich?JaNeinMissbrauch melden
am 25. Juli 2014
Vorab zu meiner Person: Ich bin kein C-Programmierer sondern noch am Erlernen der Sprache. Außerdem arbeite ich beruflich unter Windows, privat unter Linux/BDS.

Eigentlich könnte man es sich mit einem Urteil über dieses Buch ganz leicht machen: Wenn ein Autor über die Programmiersprache C schreibt und nicht zwischen "Deklaration" und "Definition" unterscheidet, dann ist "die Sache erledigt". Streng genommen. Diese Unterscheidung ist dermaßen simpel und zugleich dermaßen fundamental, dass es nicht akzeptabel ist, wenn sie nicht gelingt oder nicht getroffen wird. Entweder kennt der Autor den Unterschied nicht oder er ist ihm egal - beides ist haarsträubend. Leider ist es mit einem Urteil aber doch schwerer, weil das Buch nicht nur schlecht ist. Dazu aber unten mehr.

Unterscheidungen - und zwar als fehlende oder als falsche - sind generell ein roter (oder doch ein schwarzer?) Faden (oder Zwirn, oder doch ein Strang oder was denn nun, egal...), der sich durch das Buch zieht.

POSIX und Unix: Statt von UNIX/Unix/Unix-ähnlich spricht Klemens ständig von POSIX. Wieder: Kennt er den Unterschied nicht oder ist er ihm egal oder ist das seine besondere Innovation, dass er von POSIX spricht, wo jeder andere Unix meint. POSIX ist ein Standard - Unix(-Ähnlichkeit) ist ein Betriebssystem bzw. die Eigenschaft eines solchen. Man sagt: Linux ist ein Unix-Klon oder unixoid oder Unix-ähnlich und es setzt den POSIX/SUS-Standard im Wesentlichen um. Niemand aber sagt, Linux ist eine POSIX-Variante. Kurioserweise kann bei Klement "POSIX" auch für die Command Line stehen (S. 14). Ein echtes Wunderding, dieser neue POSIX-Begriff.

Das mag pedantisch wirken, aber wer bei Begriffen nicht genau ist, der ist auch im Denken unscharf. Und wer es dort ist, wird auch in den Produkten seines Denkens Windschiefes, zufällig Passendes, ad-hoc-Lösungen udgl. liefern. Das passt alles zur Welt der Scripting-Sprachen, nicht aber zu C und auch nicht zu Unix.

Auch die Unterscheidung Betriebssystem/Dateisystem gelingt dem Autor nicht. Nicht einmal das! Er unterteilt auf Seite 6 die "Dateisysteme" in "zwei Klassen": POSIX und Windows. Ich muss sagen, so etwas habe ich noch in keinem IT-Buch gelesen und ich habe doch ein paar davon. Vielleicht ist das ein Übersetzungsfehler, was die Sache aber (für das deutsche Buch) nicht besser macht. Denn dann wäre der Übersetzer ein (ich kann's nicht anders sagen:) Vollstümper. Man fragt sich nach nur wenigen Seiten: Was kommt als nächstes? Die Gleichsetzung von DOS und BIOS oder von RAM mit DMA oder von Dennis Ritchie mit Lionel Richie?

Schließlich fragt sich der Leser, wie er den Autor einsortieren soll: Ist es nur einer, der sich um C nicht recht kümmert, weil er es nur vage kennt, oder sind ihm die ganzen peinsamen Begriffe und Fakten in der EDV selbst ein bisschen lästig, weil er sie nicht präzisieren könnte oder schlicht nicht versteht oder sich mit einem Begriffshof udgl. begnügt. Wenn man untergriffig sein will, kann man sagen, dass sich sehr viel durch die Ausbildung des Autors erklärt. Für mich steht der Begriff "Sozialwissenschaften" für Relativismus, für Sprachverschwurbelung, für mangelnde Präzision im Sprachlichen und Intellektuellen, letztlich dafür, dass bei der Kombination "Sciences" und "Social" genau eines der beiden Wörter überzählig ist. Das ist freilich nur mein persönliches und etwas/ziemlich böses Vorurteil - ich sehe es hier allerdings zum Teil bestätigt. Natürlich gibt es keine korrekte Ausbildung für einen Programmierer oder Autor oder beides - aber Social Sciences sind doch eine Last, die nicht jeder erfolgreich abstreifen kann.

Das Besondere ist allerdings, dass wie gesagt das Buch nicht nur Müll ist. Es gibt (zumindest dann, wenn man nicht alles weiß - und das ist bei mir eine ganze Menge), doch eine Reihe von Ideen und Infos, die für sich genommen recht gut sind (oder sein könnten). Da aber fast jedes 2. Faktum, das man verifizieren kann, grotesk falsch ist, ist man unsicher, ob das Neue, das man nicht kennt, nun doch vielleicht richtig oder erneut verschärfter Blödsinn ist. Oder ob es wohl einen wahren Kern hat, aber halt "nur" unpräzise ist.

Man muss das Buch also auf eine ganz spezielle Art lesen. Jeder Satz könnte grober Unfug sein, und deshalb ist alles zu hinterfragen. Eigentlich eine (post)moderne und "aufgeklärte" Leseart, nur: So kann man generell nicht verfahren, weil man dann die 20fache Zeit und Energie zum Lesen bräuchte. Man überlegt sich dann dreimal, ob man ein Buch aufschlägt ("Habe ich heute Zeit und Nerven dazu?") Aber wie gesagt: Ein sehr eigentümliches Abenteuer, bei dem der Leser Leser, Lektor und Korrektor und Rechercheur in Einem und somit immer bereit zur Verifikation jedes einzelnen Faktums sein muss. Es kann eigentlich nicht einfach nur gelesen sondern muss zusätzlich gegengelesen werden. Nach dem Motto: "Ich weiß, dass ich nichts weiß und der Autor weiß auch nichts. Und hier weiß ich sicher, dass er nichts weiß. Aber vielleicht weiß er da was, ich weiß es leider nicht." Also muss ich alles Neue nachprüfen und das Buch im Kopf selber ein zweites Mal schreiben." Seufz.

Was ein weiterer Irritationspunkt dieses Buches ist: Man kann nicht nur den Autor noch die Qualität oder Richtigkeit von unbekannten Infos des Buches selbst beurteilen - es gelingt auch nicht, zu erkennen, wen der Autor als Zielgruppe eigentlich ansprechen will. "Alte" C-Programmierer, die den "neuen hippen Style" verwenden oder "junge" XXX-Programmierer, die mal das "neue, punkige" C versuchen sollten? Unix (POSIX/Ubuntix)-User, für die die Shell Neuland ist, Windows-GUI-Jünger, die sich mal POSIX (Unix/Linux/GNU) mit POSIX (hier: die Shell) anschauen sollten?

Besonders bizarr finde ich in diesem Zusammenhang, dass er Windows-Nutzern ironiefrei vorschlägt, sich mit Unix auseinander zu setzen, weil Windows den C99-Standard nicht oder nur zum Teil unterstützt. Das kann doch nicht ernst gemeint sein, oder?!? Damit jemand nun _BOOL verwenden kann, soll er gleich von seiner geliebten GUI auf die Shell (POSIX) wechseln und komplett auf eine IDE verzichten? Es gibt wohl einen Grund, warum C99 (angeblich) unter Windows (tw.) fehlt, weil es die dortigen User offenbar nicht ausreichend nachfragen. C ist (mittlerweile) nunmal eher mit der Unix-Welt verknüpft und weniger mit Windows. Wieviele Windows-User werden also überhaupt für den C99-Standard brennen? Warum sollten sie sich die wirklich heftige Umstellung auf die Unix-Shell antun? Ich meine, das geht komplett an der Zielgruppe vorbei. Und ehrlich gesagt tut mir jemand, der nur die GUI kennt, leid, wenn er gezwungen wird, sich hier komplett umzustellen, denn es ist ein großer Aufwand. Geht der arme Tropf später wieder zu Windows und zur GUI zurück, dann war das ein unfassbarer Overhead, der niemals gerechtfertigt ist. Steigt er aber auf "POSIX" um, dann muss er nur noch mit den Unbilden von POSIX zurecht kommen, was - wie ich als POSIX/BSDIX/GNUIX-User zugeben muss - auch seine Tücken hat.

Zielgruppe, continued: Umgekehrt ist es peinlich, wenn für Unix-Leute die simpelsten Dinge erklärt werden - zudem von einem, der nicht zwischen Unix und POSIX und Datei- und Betriebssystem unterscheiden kann, erkennbar also keinen Sinn für Unix hat. Was soll man sagen, wenn Klemens den "Trick" mit der Commando-Substitution der Shell "verrät"? Wow! Was kann diese Shell denn noch alles? Kann ich auch rechnen damit? ImPOSIXant! Das ist also für ein virtuelles Publikum, eine Schnittmenge aus Windows-Usern, die bitte endlich an die Shell möchten, und aus Unixern, die ihre Konsole bislang nur für "startx" verwendet haben, es aber doch noch einmal wissen möchten.

Was man auch nicht einordnen kann, ist die Zeitebene: Wann ist etwas, das der Autor als neu bezeichnet, auch wirklich neu? Die Nutzung von Make ist neuer Stil? Ach ja? Kann es nun auch sein, dass nicht einmal die Unterscheidung zwischen den Jahrhunderten gelungen ist? Was versteht er unter "jung" und "alt", was unter "21. Jahrhundert"? Man hat manchmal den Eindruck, dass der Autor die Worte wahllos verwendet, irgendwas werden sie schon im Kontext bedeuten. Und wenn das Gegenteil rauskommt, was soll's!

Es hat eben nichts mit dem 21. Jahrhundert zu tun, wenn man "make" oder die "bash" (bitte aber im POSIX-Modus!) entdeckt und verwendet. Make ist nicht aus den 90ern oder den 80er sondern aus der Anti-Zeit der Vision des Autors, aus den dunklen, vergilbten 70ern, als Punk eben noch kein Punkrock war - beide Musikstile sind übrigens schwer zu ertragen: Punk ist mit seinen 3 Akkorden nie mehr als ein paar Jahre lebensfähig gewesen und Punkrock lebt zwar dank Rock-Komponente, ist aber grauenhaft wegen des Punk-Elements. Make und die Shell: Dinosaurier also. Die Shell als Konzept ist sogar noch älter als Unix, da Ken Thompson die MULTICS-Idee übernommen hat (so wie die FSH). Die CLI mit ihren Tools wie eben make war immer Teil der Unix-Kultur, im Grunde ihr Kern. Und Windows mit seiner GUI war und ist die Gegenthese dazu. Die Textkonsole selbst hat mit modern überhaupt gar nichts zu tun, im Gegenteil. Sie ist meines Erachtens einer GUI zwar himmelweit überlegen, aber sie ist die Verkörperung des Unmodernen in der IT.

Das einzige Fixum des Buches ist "C" - man kann jeden Käufer beruhigen. Es geht wirklich um C. Nicht C# oder C++ oder D oder was weiß ich. Das ist für manchen vielleicht nicht viel an festem Grund, aber man lernt es im Laufe des Lesens zu schätzen, dass wenigstens das gesichert ist.

Der technische Teil:

Wo will der Autor mit der Sprache überhaupt hin? Einmal ist ihm Speicherplatz restlos schnuppe. Sollen diese öden Bytes doch verbrennen - im 21. Jahrhundert ist RAM so billig, dass man den Usern noch heimlich ein paar Gigabyte mit einpackt. Und an anderer Stelle, bei den Bits nämlich, die scheinbar viel knapper sind, verrät er, dass Enums ein Problem sind, weil sie Bit-Schleudern sind. Es tut auch ein 8-Bitter, ein char halt. Was denn nun? Sinn macht es keinen, es geht wohl nur darum, mit Zwang was Neues zu erfinden, das je nach Bedarf auch logisch inkonsistent sein darf. Die Regel gilt immer, dass man Speicher sparen soll, denn es kann immer sein, dass er knapp wird. Auf OS-Ebene macht es sicherlich keinen Sinn, lieber RAM rauszuhauen, weil sich das doch aufsummiert, im embedded-Bereich wahrscheinlich auch nicht so sehr. Andererseits sollte man doch bei der Frage "int vs. char" bedenken, dass ints vom Register-Zugriff besser sind, da sie ja auf die Registerbreite abgestimmt sein sollten. Der char-Zugriff muss also nicht schneller sein als der int-Zugriff, da ja der Speicher nicht bitweise in die Register gezogen wird sondern mit der ganzen Registerbreite. Ich bin kein CPU-Experte, aber mir scheint, dass das Kapitel mit den Enums technisch einfach Quatsch ist.

Dasselbe gilt für die Empfehlung, "float" zu vergessen, weil zu klein. Jeder Datentyp kann zu klein werden. Man muss eben immer bedenken, was wo gespeichert wird. Immer zur Sicherheit den größten Typ zu verwenden, ist nicht modern sondern hirnverbrannt.

Bei dem Abschnitt "Enums und Strings" zeigt sich auch schön, wie die begriffliche Wirrnis die intellektuelle widerspiegel. Ein Enum müsse "global" sein, da er andernfalls nicht nützlich wäre. Und "globale Variablen" erfordern "Verantwortung". Darum sind Enums laut Klement problematisch. Die Gefährlichkeit globaler Variablen ist eine Binsenweisheit in jeder Programmiersprache. Der Schönheitsfehler mit den Enums ist nun aber, dass sie keine Variablen sind sondern entweder Bezeichner für Konstanten oder Typen, die Konstanten enthalten. Das Problem mit globalen Variablen ist ja eben nicht die Sichtbarkeit sondern die Veränderbarkeit. Darum ist der Vergleich mit Enums völlig fehl am Platz. Ein Enum kann nicht verändert werden, darum greift diese Problematik hier nicht. Namespace-Probleme kann ich immer bekommen, ob mit Enums oder mit den Strings, die der Autor vorschlägt. Natürlich mag er recht haben, dass ein Bezeichner wie "p" keine Namespace-Probleme bringen wird, weil kein Library-Autor so verrückt ist, einen solchen Bezeichner zu wählen. Best Practice kann es aber nicht sein, so vorzugehen, da ein Variablenname immer sprechend sein sollte. "p" oder "i" passt nur für lokale Variablen. Aber es hindert ja niemand den Autor, seine "Ein-Zeichen"-Doktrin auch bei Enums zu verwenden. Hier spielt der Speicherplatz nämlich wirklich keine Rolle. Denn es wird niemand in einem Projekt Abertausende Enums definieren - es ginge auch nicht, da der Autor mit einzelnen Zeichen arbeiten möchte. Meiner Meinung nach handelt es sich bei der "Idee" des Autors um eine absolut sinnlose, die er wohl nur gehabt hat, um irgendetwas anders, neu, New-Millenium-mäßig zu machen.

Kurios ist auch, dass der Autor auf "inline" und "restrict" verzichten will. Er mag faktisch recht haben, aber damit entsorgt er gleich 2/5 der tollen neuen Schlüsselwörter des so wunderbar neuen C99-Standards.

Der "Trick beim Lesen von Deklarationen": Hier öffnet der Autor seine Schatzkiste. Man müsse einfach von rechts nach links lesen. Die ganze Komplexität mit einem Kniff weggewischt. Richtig ist, dass man die Präzendenz- und Assoziativität-Regeln der Operatoren kennen muss sowie den Umstand, dass Klammern diese "overrulen". Dann klappt das auch, aber richtig. Denn einfach alles von rechts nach links kann klappen, muss aber nicht. Aber wie so oft in diesem Text: Daumen mal PI, meistens funktionierts, das reicht. Da spielt wohl die Statistik rein, die das Steckenpferd des Autors ist. Die paar Randfälle in der Normalverteilung, wo seine Supertricks verfehlen, jucken den Statistiker freilich nicht. Im konreten Einzelfalls schaut's aber naturgemäß ganz anders aus.

Ähnlich ist es im Kapitel über "const". Natürlich ist "const" in Verbindung mit Zeigern knifflig, aber gerade hier zeigt sich die Qualität einer Erklärung. Während "C in a nutshell" das knapp und präzise erklärt, resümiert Klemens nur, dass "const" mehr dem Code-Leser diene als dem Compiler, dass es also mehr eine Frage der Lesbarkeit als eine der Sprachnormativität wäre. Und das ist kompletter Quatsch. Entweder ist man modern, flapsig und ad hoc - oder man liefert eine tiefer gehende Erklärung, die das Verständnis für eine Sprache (nachhaltig) schärft. Man muss eben unterscheiden zwischen einem konstanten Zeiger, einer konstanten Variablen und einem konstanten Zugriff eines Zeigers auf eine (mitunter nicht-konstante) Variable (mit einem nicht unbedingt konstanten Zeiger). Das IST komplex und auch potentiell verwirrend. Aber wenn man eine ordentliche (old style, d.h. mit Hirn versehene) Erklärung bekommt, versteht man es auch. Ein kursorisches "Das mit dem const ist komisch, vergiss es einfach" "hilft" nur einem Wirrkopf. So eine Herangehensweise ist einfach (so leid es mir tut, das zu sagen:) Schrott.

Und genau das ist so sehr der Stil dieses Buches. Drauf los klopfen auf die Tasten (mit oder ohne T-Shirt - siehe die Anleitungen zum schnelleren Tippen) und modern sein und rockig sein und alles nur an der Oberfläche kapieren. Das ist ein furchtbarer Denkstil. Und damit komme ich auch zum (überfälligen) Schluss: Das was so aufregt, ist der unbekümmerte Stil, der Sorglosigkeit (womöglich leider zu Recht) mit Modernität verwechselt. Der Unix verwendet, es aber im Grunde für alten Mist hält und das nur nicht sagt, weil es halt auch praktisch ist; der C verwendet, damit er daraus eine moderne Script-Sprache basteln kann. Der "moderne" Schwung hat auch seine Meriten, aber es ihm aus 100 Metern Entfernung anzusehen, dass er nur eines kann: Modernisieren - dass aber die intellektuelle Reichtweite zu gering ist, um etwas zu schaffen, das man als Ballast empfindet, weil man nicht mehr die Nerven hat, es zu durchdringen, und das man doch nutzt, weil man selber nichts Vergleichbares zu Stande bringt. Diese Modernität könnte eben Unix oder dessen Sprache (C) nicht noch einmal erschaffen. Diese Zeiten scheinen vorbei zu sein, da immer mehr Leute Unix nicht verstehen wollen, es aber trotzdem verwenden und verändern.

Kann man das Buch empfehlen? Das ist schwer zu sagen. Wie oben erwähnt: Mir fehlt das Wissen, um alle Infos zu prüfen. Diese könnten Unfug oder gar grober Unfug sein, möglicherweise aber auch nicht. Was man aber sicherlich beim Lesen beachten muss, ist der Umstand, dass jedes Faktum hinterfragt werden muss. Man kann dem Text nicht einen Millimeter trauen. Das ist anstrengend, es könnte aber auch lohnend sein (eventuell aber auch nicht).

Was ich als posititiv empfunden habe, ist dass der Autor sich bemüht hat, alle möglichen nützlichen Hilfsprogramme zusammenzusammeln sowie dass er generell versucht, einen guten Überblick über den aktuellen Stand der Entwicklung in der Open-Source-Gemeinde zu geben und dass er zum Programmieren anregen will, durchaus auch mit einem gewissen Elan. In dieser kompakt Form findet man die Tool-Zusammenschau andernorts nicht so leicht. Außerdem gibt es die eine oder andere Anregung, die nützlich ist. Letztlich muss man dem Autor auch zugute halten, dass er es "gut meint". Eine gewisse Frische hat der Text. Wenn man bereit ist, alles nicht für bare Münze zu nehmen, ist das Buch nicht so schlecht gelungen. Mehr als zwei Sterne verdient es aber nicht, da die Fehlerfülle einfach zu groß ist.
0Kommentar|10 Personen fanden diese Informationen hilfreich. War diese Rezension für Sie hilfreich?JaNeinMissbrauch melden
am 18. November 2013
Das Buch ist eine einzige Mogelpackung.

Zitat: "Werfen Sie Ihre Vorstellungen von C über Bord und lernen Sie eine Programmiersprache neu kennen...
Mit 'C im 21.Jahrhundert werden Sie aktuelle Techniken entdecken, die in keinem anderen Buch über C zu finden sind".
Diesem Anspruch wird das Werk eindeutig nicht gerecht, kein Leser wird nach Lektüre dieses Buches grundlegend Neues erfahren haben.
Das Buch ist niemandem zu empfehlen, auch wegen der Inkompetenz des Autors zu Fragen der C-Standards und Fehlern in seinen Beispielcodes.

Die ersten 100 Seiten befassen sich ausschließlich mit allgemeinen Betrachtungen zum Handling von C-Programmen/Projekten, autotools, make, Git usw. werden vorgestellt, nicht ohne das schon genannte Eigenlob des Autors.
make gibt es bekanntlich schon seit es Unix gibt, und verschiedene VCS als Git-Vorgänger gab es schon in den 80ern, es kann also keine Rede von Neuigkeiten aus dem 21.Jahrhundert sein.
Als Standard setzt der Autor C99 voraus.
Für Windows empfiehlt der Autor cygwin/MSYS, als Compiler gcc und clang. (wobei er richtig darauf hinweist, dass mit cygwin1.dll auch die Quelltexte ausgeliefert werden müssen, es sei denn, man erwirbt eine (kostenpflichtige) Lizenz).
Praxisunkenntnis offenbart sich schon hier:
- "für fork und popen benutzen Sie unter Windows MinGW" -> MinGW unterstützt kein fork
- int x[20]={}; -> Syntaxfehler gemäß Standard wegen leerer Initialisierer-Liste

Der Autor setzt ausschließlich auf die Kommandozeile, IDE nennt er zwar, ist aber offensichtlich der Meinung, dass man im 21.Jahrhundert keine IDE (mit konfigurierbaren Kommandozeilentools oder eigener Projekt- und Sourcecodeverwaltung) einsetzen sollte; vielfach wird das Makefile mit aufgeführt.

Allgemeine Weisheiten wie "benutzen Sie einen Debugger" oder "benutzen Sie valgrind" (wobei er verschweigt, dass valgrind für Windows nicht existiert) tragen ebenso wenig zur Seriösität der Autor-Aussagen bei.
Allseits (und schon im 20.Jahrhundert bekannte) 'Tipps' werden gegeben, wie
./configure
make
make install
ebenso der Hinweis auf
LD_LIBRARY_PATH
zur Runtime-Konfiguration: alles bekannte Details und durchaus "auch in anderen Büchern zu finden".

Allgemeine Ratschläge des Autors, man solle vor Beginn eigener Projekte zunächst nach schon vorhandenen C-Bibliotheken suchen (der Autor zählt z.B. auf: pthreads, GLib, GNU libiberty, GSL, cURL, libxml, SQLite) und diese dann vorzugsweise vor eigenen Implementierungen verwenden, haben schon im 20.Jahrhundert gegolten und stellen auch keine 'neue Technik' dar.
Im Kapitel "Ein Dictionary implementieren" hält sich der Autor dann selbst nicht daran; nachdem er zuvor GHashTable aus GLib gezeigt hat, nimmt er doch wieder eine eigene Implementierung vor, und die dann auch noch mit Verwendung laienhafter globaler Variablen.

Weiterhin kündigt der Autor im ersten Teil des Buches MEHRFACH an, dass er später im Buch 'ultimative' Verfahren zum Stringhandling zeigen wird und dass malloc dabei und auch sonst vollkommen unnötig ist;
nichts von diesen Versprechungen kann der Autor einhalten, da er in nahezu jedem Beispielcode doch wieder malloc usw. verwendet.
Er führt auch selbst 5 Ausnahmen auf, wo doch der Einsatz von malloc notwendig ist;
dabei ist eine obskure Beschreibung, dass man für größere Speicherbereiche, deren Größe man erst zu Laufzeit kennt, doch malloc einsetzen muss, dies aber 'meistens in eigene Funktionen kapselt'; ein malloc-Aufruf in einer eigenen Funktion ist nach Ansicht des Autors offenbar kein-malloc Aufruf.
"...Auch hier werden Sie vermutlich Ihre Daten in einer Art Objekt speichern, sodass dies in der Praxis zu einem Aufruf der Funktion object_new führen wird und weniger zum Aufruf von malloc selbst".
Äußerst unüblich ist es auch, bei malloc von 'manueller' Speicherreservierung zu sprechen (wie es der Autor im ganzen Buch nennt): gängig ist hier, von 'dynamischem' Speicher zu reden.

Überhaupt verwendet der Autor sehr wenig konkreten Code in seinem Werk (was er auch so beschreibt und offensichtlich so beabsichtigt).

Auch in den wenigen Beispielcodes offenbart sich die Unsicherheit und Praxisferne des Autors, noch nicht mal simple Grundlagen kann er vermitteln, weder im Code selbst noch in seinen umfangreichen Erläuterungsversuchen:

- er verwechselt ständig Deklaration mit Definition (greift auch schon mal fehl, indem er beschreibt, wie man eine deklarierte Variable initialisiert, was unmöglich ist)
- "der Typ size_t ist dazu gedacht, Adressen als Integer-Wert zu speichern" -> Unsinn, size_t soll Längen/Größenangaben aufnehmen, siehe sizeof, strlen
- zeigt sorglos Gleichheitsvergleiche von double mit ==, ohne Hinweis der Besonderheiten
- setzt häufig assert ein (ohne jeglichen Hinweis auf NDEBUG; bei vielen Compilern wird assert im Release-Modus ignoriert, d.h. der Code nicht ausgeführt)
- der Autor zeigt den Vergleich von struct-Variablen mit memcmp, ohne auf die Risiken der (implementierungsabhängigen) padding-Bytes hinzuweisen; das Padding erwähnt er erst später
- übergangslos werden VLA eingeführt ohne die Unterschiede zu herkömmlichen Arrays oder den Begriff VLA selbst zu nennen und ohne Erwähnung, dass diese in C11 nur noch optional vorhanden sind
- im ganzen Buch werden die Fachbegriffe String-Literal und undefined behavior (UB) nicht genannt
- String-Literale werden vom Autor niemals mit const char *s="hello"; verwendet, sondern nur ohne const; und das, obwohl der Autor später empfiehlt, oft const einzusetzen: warum setzt er es dann selbst nicht ein?
- Nachteile von Verwendung von static wird am Beispiel von strtok mit C11 _Thread_local abgetan, die neben den Thread-Problemen ebenso vorhandenen Reentranz-Probleme werden vom Autor überhaupt nicht erwähnt; der lapidare Hinweis geht nur auf strtok_r,strtok_s,strsep ein
- auch Alternativen zu strtok( "\t\r\n") 'vergisst' der Autor zu erwähnen, wie sscanf(string,"%s",s), wobei hier der Ausgangsstring nicht zerstört wird, was meistens vorteilhaft ist
- er verwechselt auch schon mal POSIX mit ISO-C, z.B. bei fopen/open POSIX/ISO statt richtig ISO/POSIX
- der Autor verwendet grundsätzlich strcasecmp (POSIX) statt das gebräuchliche ISO-konforme strcmp
- der Autor behauptet, CHAR_BIT sei in C89 impl.abh. und in C99/C11 == 8 -> falsch, in jedem Standard ist CHAR_BIT >= 8 vorgeschrieben
- get_opt wird vom Autor gezeigt, ohne Hinweis, dass dies nur POSIX vorhanden ist (und dort getopt heißt und nicht get_opt)
- der Autor behauptet, IEEE 754 sei nicht vom Standard definiert -> falsch, C99 definiert __STDC_IEC_559__, womit sogar ein Test auf IEEE-754 Konformität erfolgen kann
- auch mit den Grundlagen Array/Pointer hat der Autor (ebenso wie mit Deklaration/Definition) seine Schwierigkeiten, indem er behauptet:

double *plist = (double[]){1,2,3};
plist sei ein Zeiger auf ein Array (von double) -> falsch, plist ist ein Zeiger auf double

Der Autor ist sich auch nicht zu schade, konkrete angebliche Vorgaben aus dem Standard zu nennen:
"... der Standard legt fest, dass der Inhalt von konstanten Strings (so nennt der Autor String-Literale) auf jeden Fall schreibgeschützt sein muss..."
das ist auch wieder falsch interpretiert, der Standard spricht nur von undefiniertem Verhalten bei Änderung eines Elementes eines String-Literals.

In Kapitel "Das Problem mit char const**" offenbart sich dann die Naivität des Autors im Umgang mit Selbstverständlichkeiten wenn er schreibt:

int *var;
int const **constptr = &var;
"Bei einer Folge von Zeigern konvertieren alle mir bekannten Compiler den 'obersten' Zeiger nach const..."

Der Autor praktiziert also Programmieren durch Ausprobieren, anstatt die klaren Vorgaben aus dem Standard zu begreifen und zu präsentieren.
(in diesem Fall wird nichts 'konvertiert', der Compiler warnt, weil der einem Zeiger zugrundeliegende Datentyp 'hier also int const*' nicht kompatibel zu 'int *' ist, und der Standard vorschreibt, dass Zeiger nur kompatibel sind, wenn der basierende Datentyp kompatibel ist;
'const int' und 'int' sind kompatible Typen, also wären 'const int*' und 'int*' kompatibel, und der Compiler warnt nicht)

Alle möglichen String-Problematiken in C möchte Autor mit asprintf (weder ISO noch POSIX, nur GCC-Extension) erschlagen, häufig mit variadischen Makros.
Er meint dadurch malloc/free umgehen zu können (wie er es ja am Beginn des Buches versprochen hat), muss aber dann doch in seinen präsentierten Makros zumindest free einsetzen (für das erste Argument bei asprintf) um Speicherlecks zu vermeiden, und beim ersten praktischen Anwendungsfall eines Stringarrays verwendet er dann doch wieder ganz ungeniert malloc/realloc;
(also auch hier wieder entgegen dem ursprünglichen 'Versprechen', immer ohne malloc auszukommen und 'neue' Programmiertechniken in C für das 21.Jahrhundert vorzustellen, die noch in keinem anderen Buch vorkommen).
Solche Stringarrays sind in C schon seit Bestehen üblich, hier ist nichts 'neu'.

Beim Beispiel zur printf-Ausgabe von struct-Variablen stellt der Autor umständlich eine eigene, wieder mal auf Makros basierende Variante vor, und nicht die GCC-Extension register_printf_function, die genau diese Aufgabe übernimmt; schließlich ist des Autors allumfassende asprintf-Funktion zum Stringhandling auch nur eine GCC-Extension und kein Standard, offensichtlich besitzt der Autor auch keinen Überblick über die GCC-Features außerhalb von asprintf.

Simple kurze Beispiele gelingen oft nicht, z.B. beim Beispielprogramm zu rekursiven Dateinamenausgabe

if (entry->d_name[0]=='.') continue; // hier werden fehlerhaft Verzeichnisse mit '.' beginnend ignoriert, z.B. .ssh/

oder

if (entry->d_type==DT_DIR) // hier verstößt der Autor gegen die POSIX-Portabilitätsvorgaben, die S_ISDIR vorschreiben

Bei Datenstrukturen verweist der Autor auf GHashTable aus glib.h und verwendet auch hier in seinem Beispielprogramm auch wieder malloc (was doch angeblich 'niemals' gebraucht wird).

Weiterhin verweist der Autor beim Thema "anonyme Strukturelemente" auf C11, um dann im praktischen Beispiel doch wieder auf die herkömmlichen unions zurückzugreifen, die gewiss kein neues Feature des 21.Jahrhunderts darstellen, sondern seit Bestehen von C existieren und auch vielfach in anderen Büchern vorkommen.

Fazit:
Der Autor macht falsche Versprechungen, die er in seinem Buch nicht hält; der Autor verfügt über mangelndes Grundlagen- und Standardverständnis in C, was dazu führt, dass seine vorgestellten Beispielcodes oftmals fehlerhaft sind, ebenso wie seine Erläuterungen.
Keinesfalls führt der Autor 'neue Programmiertechniken des 21.Jahrhunderts' auf, die man 'in keinen anderen Büchern' finden kann.
Seine 'Tipps' sind überwiegend schon seit langem bekannt, entweder seit Bestehen von C, zumindest aber im 20.Jahrhundert.
Das Buch ist von vorn bis hinten eine dreiste Mogelpackung und da hat der Autor mal recht: so etwas ist nicht oft in anderen Büchern zu finden.
Das Buch ist niemandem zu empfehlen.
22 Kommentare|27 Personen fanden diese Informationen hilfreich. War diese Rezension für Sie hilfreich?JaNeinMissbrauch melden
am 9. November 2013
Der Autor ist offensichtlich ein Vollblut-Programmierer, der den Leser an seinem reichen Erfahrungsschatz teilhaben lässt. Alle Vorschläge und Hinweise werden sachkundig begründet, oft unterstützt durch einen (nicht zu ausgedehnten) Hinweis auf historische Hintergründe. Der Inhalts-Bogen wird äußerst praxisorientiert von aktuellen Tool-Fragen, über reichhaltige, konkrete Coding- und Konzept-Vorschläge bis hin zu Test- und Dokumentations-Fragen gespannt. Dabei gelingt dem Autor gekonnt der Spagat, das richtige Mass an fachlichen Details mit einem gut lesbaren, fast amüsanten Stil zu verbinden. Wer seine Jugend im letzten Jahrhundert zum großen Teil mit dem Programmieren und Verfolgen der einschlägigen Szene zugebracht hat, wird in diesem Buch die meisten seiner eigenen Erfahrungen in einer Neubewertung wiederfinden, die den Gegebenheiten des laufenden Jahrhunderts gerecht wird und die Affinität der meisten "echten" Software-Artisten zu dieser schönen und immer noch (oder wieder) hochaktuellen Programmierspache begründet finden. Programmier-Anfänger finden in dem Buch zwar sicher einige sinnvolle Tips, doch wird sich ihnen der inherente Charme der meisten hier skizzierten Themen wohl eher nicht erschließen. Zusammenfassend kann ich bestätigen, das der Autor seinem Anspruch gerecht geworden ist und hier ein C-Buch abliefert, das anders ist als alle anderen und oft da anfängt wo die anderen eben aufhören.
11 Kommentar|2 Personen fanden diese Informationen hilfreich. War diese Rezension für Sie hilfreich?JaNeinMissbrauch melden