Der habilitierte Autor ist mit seinem Anspruch, ein kompaktes, prägnantes und kompetentes Werk zu schaffen gründlich gescheitert. Das Buch ist niemandem der ernsthaft C erlernen möchte zu empfehlen.
Der Autor offenbart grundsätzliche Unkenntnis und Naivität in Sachen C aber auch beim eigenen Abstrahierungsvermögen und Didaktik.
Der Autor wendet sich an erfahrene Programmierer, die die Sprache C erlernen wollen. Dabei verweist er auf die 'hunderte' von Studenten, die bei ihm C 'erfolgreich' gelernt haben sollen.
Das naive, praxisferne C-Verständnis des Autors offenbart sich schon am Ignorieren des ANSI-C Standards.
Weder erklärt der Autor, dass er sein Buch nach diesem Standard und damit allgemeingültig ausrichtet, noch erklärt er überhaupt, was der ANSI-C Standard ist und welchen Anspruch dieser hat noch seine Bedeutung in der Praxis (Portabilität, Plattformunabhängigkeit,...).
Das hindert den Autor aber nicht daran, das Wort ANSI-C mehrfach zu verwenden. Was ist eigentlich so schwer daran, in einem selbsternannten kompetenten Fachbuch ZU BEGINN eine Begriffsdefinition vorzunehmen und diese dann zu verwenden?
Auch bei konkreten C-Sachverhalten lässt sich diese Didaktikschwäche des Autors erkennen: den Fachbegriff Whitespace führt er erst in ca. der Mitte des Buches (und dann auch noch fehlerhaft s.u.) ein, zu Beginn jedoch zählt er die 6 Zeichen einzeln auf ohne den Begriff zu nennen. Überhaupt verwendet der Autor die eingeführten englischen Fachbegriffe wenig bis gar nicht, sequence point, evaluation, expression, statement, assignment, promotion, behavior, scope, callback u.v.m. sucht man vergebens und findet sie bestenfalls manchmal als deutsche Übersetzung nebenbei.
Gleich am Anfang des Buches macht der Autor den typischen Fehler der Auflistung von angeblichen Wertebereichen und Größenangaben der Basistypen. Er versucht, dieses Unverständnis zu kaschieren, indem er voranstellt, dass es sich um 'typische' Werte handele: Der Standard schreibt bekanntlich nur (absolute) Mindestgrenzen für Wertebereiche vor, die konkrete Implementierung und Besetzung der symbolischen Grenzen (INT_MAX,INT_MIN) ist Sache des Compilerherstellers. Zu Größenangaben macht der Standard (außer char==1) keinerlei Vorgaben, was den Autor aber nicht daran hindert, wieder bitgenaue Größenangaben für jeden Typ zu machen. Später im Buch korrigiert sich der Autor dann (offenbar unwissentlich) selbst, indem er die im Standard formulierten Mindestgrenzen (ausnahmsweise mal korrekt) aus dem Standard abschreibt. Diese Widersprüche sprechen auch nicht gerade für den Überblick des Autors über sein eigenes Werk.
Ebenso nicht die Unbestimmtheit, die ANSI-C zum Datentyp char macht:
- Wertebereich char: -128...127 -> später im Buch und nebenbei wird dann erwähnt, dass ANSI-C hier nichts vorgibt, d.h. weder signed noch unsigned
- sämtliche Integraltypen werden jeweils mit UND ohne Typ-Specifier aufgelistet, also long und long int jeweils extra, short und short int, usw. ohne Hinweis des Autors über die Äquivalenz
- Variablennamen dürfen beliebig lang sein -> falsch, das logical sourceline-Limit liegt bei ANSI-C bei 509 Zeichen, auch 'vergisst' der Autor hierbei die standardgemäße Signifikanz (31/6) der initial-chars bei Bezeichnern zu benennen
Bei symbolischen Konstanten
> #define MAX 100
> const int max = 100;
'vergisst' der Autor wiederum auf den wichtigen Unterschied ( Compilezeit/Runtime-Konstante ) zu verweisen, Hinweise zum Gebrauch von enum-Elementen als Konstanten unterbleiben vorsichtshalber gleich ganz
- bei getchar() u.ä. spricht der Autor häufig von RETURN-Taste und ASCII-Wert 10, statt korrekt vom standardgemäßen '\n'
- bei sizeof 'vergisst' der Autor dessen Returntyp size_t einzuführen (geschieht erst nebenbei viele Kapitel später) und verwendet ihn auch mit falschem Formatspecifier bei printf("%d", was undefined behavior (UB) für das Programm bedeutet
- der Fachbegriff 'undefiniertes Verhalten' wird ohne Erklärung verwendet, obwohl der Standard hier konkrete Vorgaben macht, insbesondere die Abgrenzung zu unspezifiziertem und implementierungsabhängigem Verhalten
- "%n" bei printf liefert Zeiger auf Ganzzahl -> falsch Zeiger auf int
Unerklärlich für einen Autor, der auch Fachbücher zu Linux schreibt ist, dass er ANSI-C Vorgaben auf das hosted environment, sprich das Betriebssystem ableitet indem er behauptet, dass Kommandozeilenparameter-Strings (main-argv) an Whitespaces separiert werden, was falsch ist. ANSI-C macht überhaupt keine Vorgaben an das hosted environment (z.B. eine Linux-Shell), das würde dem allgemeingültigen Charakter eines Standards auch widersprechen; die Separierung der Argumente und Übergabe an den Prozess wird von der Shell selbst vorgenommen, oftmals sogar konfigurierbar ( IFS= u.ä. je nach Shell).
Bei der Vorstellung von scanf erfolgt zwar der Hinweis über den vorhandenen Returnwert, aber nicht, dass man dieser sehr komfortabel zur Fehlerbehandlung der Eingabe nutzen kann, konsequenterweise verwendet der Autor diesen Wert dann auch niemals in einem seiner Beispielcodes.
Im Abschnitt 'Reihenfolge der Abarbeitung von Eingaben bei scanf' unterlässt der Autor den hier passenden und wichtigen Hinweis zur Unbestimmtheit der Reihenfolge der Evaluierung der einzelnen Parameter; dies geschieht wiederum erst sehr viel später in einem anderen und vor allem allgemeineren Zusammenhang.
- 'signed/unsigned overflow - ANSI C schreibt hierfür nichts vor' -> falsch, ANSI C schreibt hier sehr wohl etwas vor, nämlich für unsigned wrap-around und für signed-arithmetic-overflow UB und signed-assignment-overflow Implementierungsabhängigkeit
- Erklärung von TRUE/FALSE Semantik, aber keine Erklärung der Evaluierung von logischen Ausdrücken immer zu 0 oder 1 durch den C-Standard
- beim condition-operator ?; erfolgt kein Hinweis zur Promotion des Ergebniswertes auf den "höchstwertigen" Typ
- 'eine leere Parameterliste bei Funktionsprototypen (ohne explizites void) kennzeichnet eine leere Parameterliste' -> falsch , kennzeichnet eine unbekannte aber feste Anzahl von Parametern (also auch kein variadic)
- Nennung 'call by reference' bei Funktionen mit Beispiel obwohl unmittelbar zuvor gesagt wurde: 'in C gibt es nur Wertübergabe'
- wie schon falsch bei size_t/"%d" verwendet der Autor auch häufig falsch "%lf" für double bei printf, auch wieder UB
- char s[]="abc" wird wie bei vielen anderen Stellen auch sowohl als Deklaration wie als Definition bezeichnet, ohne Hinweis auf die Unterschiede beider Fachbegriffe hinzuweisen
- Unterschiede Arrayname vs. Zeiger: unvollständige Auflistung der Unterschiede gemäß Standard
- toupper/tolower(char-var) -> UB, weil hierbei immer unsigned char verlangt wird
- scanset bei scanf vorgestellt scanf("%[ABCDEFGHIJKLMNOPQRSTUVWXYZ]") statt einfacher scanf("%[A-Z]")
- Unsicherheit bei clock_t/clock(), indem er CLOCKS_PER_SEC als double-Typ ansieht, was aber nicht standardkonform ist, der Standard sagt nichts darüber aus, deswegen auch hier wieder UB
> printf("%f",(ende-start)/CLOCKS_PER_SEC);
- sinnfreie Unterteilung von Arrays in statisch und dynamisch -> falsch, der Autor selbst hat zuvor in seinem Werk (richtig) erkannt, dass Arrays bei ihrer Definition durch eine KONSTANTE Anzahl Elemente gekennzeichnet ist, widerspricht dem nun aber wenig später schon wieder
Im Kap. 'Konvertierung von void-Zeigern' zeigt der Autor beispielhaft an char *s=(char*)malloc(...); ohne auf die ohnehin in C schon vorhandene implizite verlustfreie Promotion solcher Zeigertypen hinzuweisen, die in C++ notwendig ist aber nicht in C ; bei dieser Kapitelüberschrift lässt dies schon auf vorhandenes Unverständnis dieser C-Grundlage schließen. Diese überflüssigen Typecasts bei malloc/calloc/realloc benutzt der Autor bei jeder Gelegenheit.
- Größe einer struct in Bytes ergibt sich aus der Summe der Bytegrößen aller Einzelelemente; -> falsch, Summe ergibt sich genau aus sizeof(struct type), d.h. also inkl. evtl. inner und trailing padding bytes
- Größe einer union richtet sich nach der Größe des größten Einzelelements -> falsch, Größe einer union ist ausschließlich sizeof(union type)
- 'sscanf arbeitet wie fscanf statt mit FILE auf Strings' -> unzulässig verallgemeinernd, da fscanf den Filepointer/Inputstream verändert, sscanf den String/Inputstream jedoch nicht
- 'unter Linux kein Unterschied zw. Text/Binärdateien, deswegen fopen(...,"r""rb") uninteressant; unkonkret und praxisfern, da durchaus auch unter Linux MSDOS-formatierte Textdateien vorkommen können; wie gesagt: der Autor schreibt auch Bücher für Linux(!), da sollte ihm sowas auffallen
- remove liefert im Fehlerfall -1 -> falsch, liefert ungleich 0
- 'für Verzeichnisse ist remove identisch zur Funktion rmdir' -> falsch, ANSI C kennt keine Verzeichnisse, demzufolge unspez. Verhalten
- fflush:
'Wenn fflush auf eine Datei angewendet wird, von der zuletzt gelesen wurde, liegt ein undefiniertes Verhalten vor.' Im unmittelbar folgenden Satz dann: 'Um z.B. alle noch im Standardeingabepuffer befindlichen Zeichen zu entfernen, muß nur fflush(stdin) aufgerufen werden'. Der Autor weiß also nicht mehr, was er im Satz zuvor gesagt hat, nämlich dass fflush(stdin) zu UB führt; was ihn auch nicht daran hindert, wie schon gesagt, fflush(stdin) häufig in seinen Beispielen einzusetzen und explizit zu empfehlen
- im Kapitel 'Elementare E/A-Funktionen' erfolgt die übergangslose Auflistung von Nicht-ANSI-C Funktionen open/close/read/write ohne jeglichen Hinweis auf deren POSIX Konformität, auch hier wieder bemerkenswert, dass POSIX zwar verwendet aber nirgendwo erklärt wird und dass wie schon erwähnt, von einem Linux-Fachbuchautor
- normales Beenden der Funktion main auch ohne return möglich; falsch -> nicht ANSI-C konform
- Beenden des Prozesses auch mit _exit() möglich ; -> kein ANSI-C, in C99 heißt es korrekt _Exit()
- wieder keine saubere Trennung zw. ANSI-C und POSIX bei
> extern char **environ;
- Auflistung der Konstanten in Standard-Headerdateien ist fehlerhaft, z.B. NAME_MAX,PATH_MAX,OPEN_MAX,SSIZE_MAX (nur POSIX), dafür fehlt z.B. FILENAME_MAX, auch falsche Minimalwerte aufgeführt, z.B.
INT_MIN -32768 (statt richtig -32767)
LONG_MIN -2147483648 (statt richtig -2147483647)
Der Autor hätte hier einfach nur Kap. A.4 auf dem Standard richtig abschreiben müssen, das kann eigentlich nicht so schwer sein.
- scanf mit Format "%c" liefert nicht wie vom Autor genannt eine Zeichenkette, sondern eine Folge von char OHNE terminierendes '\0'
- viele Seiten mit identischem Inhalt, beispielsweise zu nahezu allen Funktionen aus der Standardbibliothek erfolgt deren Erläuterung mehrfach, z.B. im Kapitel zu Dateien und dann noch mal beim Kapitel zur Headerdatei <stdio.h>; offenbar will der Autor mit dieser Inhalts-Doppelung den Umfang seines Buches erhöhen; soviel zum Anspruch des Autors für sein Buch 'kurz und prägnant'
- im Kapitel 4 'Wichtige Algorithmen' werden bei Quicksort wieder die zuvor schon genannten Texte und Beispielcodes kopiert
Über 100 Seiten widmet sich der Autor dem Thema Suchen/Sortieren im Kapitel 'Wichtige Algorithmen', fertige Algorithmen/Datenstrukturen inkl. Beispielcodes zusammenzusuchen und dann aufzulisten liegen dem Autor eindeutig mehr als konkrete C-Grundlagen; leider vermisst man hier die in der Informatik wichtigen Baumstrukturen (diese werden nur in einfachster Form auf 6 Seiten dargestellt) und den Algorithmen dafür; die Beispiele sind die üblichen Kandidaten wie ggT, Türme von Hanoi, Primzahlen; dabei scheint er aber die Beispielcodes 1:1 kritiklos übernommen zu haben, und macht dabei dann auch prompt den Anfängerfehler bei der cmp-Funktion zu qsort:
> int cmp(const void *x,const void *y) {
> return *(const int*)x - *(const int*)y;
> }
die bekanntlich bei größeren (Absolut)Werten leicht overflows erzeugt.
Die häufige Verwendung von globalen Variablen und auch wieder der unsicheren Funktion gets statt fgets/scanf spricht wiederum für die Praxisferne des Autors.
Ob überhaupt und wenn ja in welchem Umfang eine Detailübersicht über Such/Sortieralgorithmen in eine 'kurz prägnante' C Kompaktreferenz gehört, ist zumindest zweifelhaft.
Im dann wieder konkreteren Kapitel 'Nützliche Programme und Hilfsroutinen' geht dann schon wieder einiges schief, z.B.
> long z;
> ...
> if( z>=LONG_MAX || z<=LONG_MIN ) ...
ist das '>' bzw. '<' redundant und zeugt nicht vom Überblick des Autors über seinen Code.
Zum Thema 'Sichere Zahleneingabe' via strtol,strtoul,strtod vermeidet der Autor u.a. das zwingend notwendige errno/ERANGE und fragt auch den returnwert falsch ab, sodass dieser vorgestellte Code wenig sinnvoll ist und nicht in allen Varianten richtig arbeiten kann.
Müßig zu erwähnen, dass der Autor seine eigenen Routinen zur 'sicheren' Zahleneingabe in den folgenden Codebeispielen NICHT verwendet, wie im ganzen Buch vermeidet er einfachste Fehlerbehandlungen wie die Auswertung des Returnwertes von scanf u.ä.
Mühsam versucht der Autor in einem Beispiel seiner 'nützlichen' Tools, deutsche Kommazahlen einzulesen um damit zu rechnen; dazu bemüht er eine struct
> struct k_zahl {
> long vorkomma;
> unsigned long nachkomma;
> } zahl;
und Stringfunktionen zur Aufteilung in Vor- und Nachkommateil, um dann in ca. 40 Codezeilen zum gleichen Ergebnis zu kommen wie z.B.
> if ( setlocale(LC_NUMERIC,"german") && scanf("%lf",&doublevar)==1 )
>
Kein Wunder, locales kommen im ganzen Buch auch nirgends vor. Dass der Standard für Sprach/Umgebungsabhängigkeit durchaus etwas anbietet, ist dem Autor offenbar unbekannt.
Im Kapitel "Semigrafik" stellt der Autor conio.h aus Turbo-/Borland-C vor, anstatt die vom ihm selbst im Folgekapitel vorgestellte plattformübergreifende ncurses-Lib zu verwenden; wie schon gesagt, ein Autor der auch Linux-Bücher schreibt, sollte diese UNIX-basierende Bibliothek inkl. der Portierung auf MSDOS/Windows basierende Systeme kennen (conio.h ist bekanntlich kein C-Standard und somit nicht plattformunabhängig).
Das Kapitel 'Programmierung der Maus unter DOS' kann man nur noch als antiquiert bezeichnen, so was gehört bestimmt nicht in eine 'kurze prägnante' C Kompaktreferenz.
Der Autor offenbart mit seinem Werk grundlegendes Unverständnis zu wesentlichen Grundlagen der C-Programmierung, und präsentiert in der immerhin schon 3. Auflage seines Buches (1999,2002,2005) große Lücken, Fehler bei Sachverhalten und Fachbegriffen wie bei konkreten Beispielcodes. Er präsentiert widersprüchlich und didaktisch unsicher.
Der Autor präsentiert weder C-Styleguides noch beschreibt der den praktischen Umgang der C-Programmierung im Umfeld von IDE, Compiler, Debugger, Lint, Testframeworks und Sourcecode-Verwaltungstools.
Ein Literaturverzeichnis sucht man vergebens, das Manöver des Autors, dieses Buch als 'Kompakt'referenz zu präsentieren und für konkretere Dinge dann auf seine eigene, weiterführende Literatur in 3 (bestellbaren) Bänden verweist um damit eventueller Kritik an diesem Werk zu begegnen, ist leicht durchschaubar.
Das Buch ist der o.g. Zielgruppe der erfahrenen Programmierer wie auch niemandem sonst zu empfehlen, die 'erfolgreich' nach diesen Unterlagen ausgebildeten 'hunderte' Studenten dürften in der Praxis eher mit negativen Überraschungen rechnen, falls sie versuchen, das hier vermittelte Wissen anzuwenden.
Das Buch ist aus oben geschilderten Gründen weder kurz, noch kompakt, noch kompetent, und prägnant nur in negativer Hinsicht und kann deswegen keinesfalls als 'Referenz' weder im allgemeinen noch im konkreten Sinn dienen.
Das Buch ist niemandem zu empfehlen.
Lade die kostenlose Kindle-App herunter und lese deine Kindle-Bücher sofort auf deinem Smartphone, Tablet oder Computer – kein Kindle-Gerät erforderlich.
Mit Kindle für Web kannst du sofort in deinem Browser lesen.
Scanne den folgenden Code mit deiner Mobiltelefonkamera und lade die Kindle-App herunter.
Dem Autor folgen
Ein Fehler ist aufgetreten. Wiederhole die Anfrage später noch einmal.
Informationen zum Autor
Spitzenrezensionen aus Deutschland
Es gab ein Problem beim Filtern der Rezensionen. Bitte lade die Seite neu.
- Bewertet in Deutschland am 22. April 2012Formatieren: Taschenbuch
