Fashion Sale Öle & Betriebsstoffe für Ihr Auto calendarGirl Cloud Drive Photos Sony Learn More sommer2016 saison Hier klicken Fire Shop Kindle PrimeMusic Lego NYNY
Kundenrezension

11 von 18 Kunden fanden die folgende Rezension hilfreich
1.0 von 5 Sternen inkompetent, grundsätzlich fehlerhaft, unbrauchbar, 28. Juli 2013
Von 
Rezension bezieht sich auf: C von Kopf bis Fuß (Taschenbuch)
Das Buch hat eindeutig seinen Anspruch verfehlt, Zitat: "bestes C Buch aller Zeiten" zu sein, wie es euphorisch auf dem Buchdeckel heißt; hierbei ist gleich mal zu bemerken, dass die im Buch genannten 'technischen Gutachter' auch gleichzeitig als Euphoriker auf dem Buchdeckel fungieren; verlagsexterne Aussagen waren wohl Mangelware.
Diese 'technischen Gutachter' Zitat: "...sichern, dass alles was wir hier behandelt haben, seine Richtigkeit hat".
Nach Lektüre des Buches haben aber für jeden halbwegs C-Kundigen sowohl Autoren wie auch die 'technischen Gutachter' einen Grundkurs in praxisnaher C-Programmierung dringend nötig.

Das Buch wendet sich an Programmierer, die schon einschlägige Erfahrungen haben, will aber ein reines Lehrbuch sein und nicht als Referenz betrachtet werden.
Neueste wissenschaftliche Erkenntnisse aus Metakognition und Lerntheorie sollen die Basis für die Gestaltung des Buches liefern; alles in allem ist auch dieser Ansatz gescheitert, neben vielen fachlichen Fehlern ist auch die Gestaltung des Buches eher unbrauchbar, krampfhaft den nun mal trockenen C-Lehrstoff mit vielen Bildern,Zeichnungen,Lückenquelltexten u.ä. anzureichern reicht nicht, wenn die zugrunde liegende fachliche Basis des Autorenpaares offensichtlich unzureichend ist.

Insgesamt ist die Lektüre des Buches aufgrund vielen verschiedenen Gestaltungmittel auf jeder Seite sehr unrythmisch zu lesen, ständig fragt man sich, was die jeweilige Gestaltungform denn nun bedeuten soll;
ebenfalls fällt auf, dass die Lücken-quelltexte nochmal anschließend komplett mit Lösung wiederholt werden, was auch zum offensichtlich angestrebten Füllungsgrad des Buches beiträgt damit der Leser auch wirklich nicht auf die Idee kommt, hier eine kurze Einführung in C vorzufinden;
Leser mit solchen Ansprüchen sind von den Autoren explizit nicht erwünscht, ebenso wie solche
Zitat: "würden sich lieber von 15 kreischenden Affen die Zehennägel ziehen lassen als einmal etwas Neues auszuprobieren".

Wenn das alles ist, was das Autorenpaar inkl. zweier technischer Gutachter anbieten kann, darf man getrost auch die anderen genannten Fachbücher der Autoren vergessen:
Zitat: "Er kann in über 10 Sprachen programmieren, schreibt aber nur in einer."; hier kann definitiv aber nicht C gemeint sein, vielleicht ja Englisch.

Jemand der in über 10 Sprachen programmieren kann, kann naturgemäß nur wenig Praxiserfahrung in jeder dieser Sprachen besitzen, so ist es auch beim
Autorenpaar; schon zu Beginn beschreiben sie C als 'komplexe' Programmiersprache, was sie eindeutig aber gerade nicht ist; es war bekanntlich
Anliegen bei C, ein kleine, überschaubare und somit leicht portierbare Sprache zu erstellen und eben gerade keine komplexe.
Die Autoren haben das Grundanliegen von C nicht verstanden.

Reichlich eigenwillig arbeitet auch der Übersetzer, wenn er das Stringendezeichen '\0' eigenwillig mit 'Wächterzeichen' übersetzt.
Rätsel geben ebenfalls die durchgängig mit Copyright 2014 gekennzeichneten Quelltexte auf.

Das Buch enthält tatsächlich keinerlei tabellarische Übersichten über Sprachumfang und Standardbibliothek, die Operator-Vorrangtabelle
und eine (sortierte) Übersicht über die Bibliotheksfunktionen gehören in JEDES C-Buch, egal ob nun 'wissenschaftlich' oder nicht.

Das Buch konzentriert sich ausschließlich am Compiler gcc für Unix/Mac/Windows; IDE werden nicht verwendet oder vorgestellt.
Es ist wenig motivierend für einen C Einsteiger, sich noch mit Entwicklungsumgebungen auseinanderzusetzen oder sich gar direkt mit Editor
und Compileroptionen auf Kommandozeilenebene herumzuschlagen.

Nach 36 einführenden Seiten mit den üblichen Danksagungen und Eigenlob (immerhin ist eine Widmung an D.M.Ritchie dabei) geht es dann auch schon los.

Und mit den ersten Fehlern,
- wiederholt wird statt einfach 'make programm' nur 'gcc programm.c -o programm' gezeigt, die einfache make-Variante ohne Makefile
kommt sogar in dem Extrakapitel zu make nicht vor
Auch behaupten die Autoren, der Compiler erstelle das Programm, obwohl sie sich dann selbst widersprichen indem sie feststellen, dass der Compiler
lediglich die Objekt-Dateien erstellt; hier fehlt die Aussage zum Linker, der das Programm endgültig aus Objekt- und Bibliotheksdateien erzeugt.

Auch die ersten konkreten Codezeilen zeigen die Praxisferne des Autorenteams, indem sie bei
char ex[20];
scanf("%19s",ex);
- vergessen, auf den Abbruch von scanf beim 1. Whitespace hinzuweisen (erst viel später im Buch weisen die Autoren darauf hin, s.u.)
- und den return-Wert von scanf nicht auswerten (das passiert dann erst viel später im Buch bei fscanf)
Dies ist auch wieder ein Inkonsequenz: es gibt keine klare Linie, die die Autoren bei der Verwendung von Funktionen zeigen und auch über das gesamte Buch hinweg einhalten; im vorletzten Kapitel sagen sie dann, man solle den Funktions-Returnwert beim Aufruf externer Systemfunktionen (execl,...) verwenden; d.h. für andere also nicht.
Für ein (selbsternanntes) Lehrbuch sind solche 'verzögerten' Informationen an den Leser absolut nicht zu tolerieren.
Überhaupt scheitern die Autoren auch bei anderen Gelegenheiten am simplen Einlesen von Strings.
So zeigen sie wiederholt

char name[80];
fgets(name,sizeof(name),stdin);

und arbeiten dann mit diesem String weiter ohne dem Leser zu erklären, dass zwar hier gegenüber scanf nicht beim 1. Whitespace abgebrochen wird dafür aber das endende '\n' mit enthalten ist (meistens), d.h. der String enthält also "Max Mustermann\n" und nicht wie ein C-Einsteiger erwarten würde "Max Mustermann". Dies hätten die Autoren selbst erkennen können, wenn sie ihre eigenen Aussagen im Buch verstanden hätten, wie unten erwähnt, beschreiben
sie "fgets hängt immer '\n' an"; die Übersicht der Autoren über ihr eigenes Werk ist also ebenso nicht gegeben.
Das sind alles Basics, die einem mit der täglichen C-Praxis vertrauten Entwickler bekannt sind, wozu die Autoren wie auch bei ihren vielen anderen
Fehlern, definitiv nicht Anlaß geben.

Reichlich naiv sind auch die wenigen Antworten zum allgemeinen Programmaufbau/design:
"Woher weiß ich, welchen Standard mein Compiler unterstützt?" -> "Schauen Sie in der Compilerdoku nach"
anstatt hier konkret die standardisierten Funktionalitäten zu zeigen
(__STDC__,__STDC_VERSION__)
Diese Verständnislosigkeit der Autoren zu den Standards führt dann dazu, dass sie nicht dokumentieren, welchen C-Standard sie selbst in diesem
Buch anwenden (C89/C99/C11); wahrscheinlich ist es aber C99, da Variablendefinitionen mitten im Anweisungsblock vorkommen; noch wahrscheinlicher
ist aber, dass die Autoren überhaupt keinen der Standards strikt befolgen und den gcc-Default gnu99 (erweitertes C99 plus gcc-Erweiterungen) benutzen.
In der Auflistung der wichtigen gcc-Optionen fehlen dann auch (konsequenterweise) die entsprechenden standardkonformen Optionen
-pedantic bzw. -pedantic-errors, die eine strikte Verwendung des jeweiligen Standards absichern (-std=c89/c99/c11).

Gängige Fachbegriffe werden nicht vermittelt, bei
"was passiert wenn sie versuchen, ein Element eines Stringliterals zu ändern?"
wird der Leser auf die Programmausgabe "Bus-Error" fokussiert, anstatt genau hier den passenden Fachbegriff undefiniertes Verhalten/undefined behavior (UB) einzuführen.

Die Werte true/false (ab C99) werden vorgestellt ohne deren Typ (_Bool) zu nennen, sowas ist mehr als ein Flüchtigkeitsfehler für ein Lehrbuch mit so hohen eigenen Ansprüchen.

Die ab C99 mögliche for-interne Variablendefinition ( for(int i=0;..;..) ) vergessen die Autoren ebenso zu zeigen, obwohl sie sonst ausschließlich C99 Code verwenden.

Praxisferne beweisen sie weiterhin mit
- in void-Funktionen ist return sinnlos => sehr wohl sinnvoll, z.B. zum Beenden der void-Funktion aus Schleifen heraus
- fgets hängt immer '\n' an => falsch, nicht immer
- scanf liest nur bis zum 1. Leerzeichen => falsch und ungenau, es muss 1. Whitespace heißen
- long double vergessen bei Vorstellung der Fließkommadatentypen
- LNG_MAX/LNG_MIN statt richtig LONG_MAX/LONG_MIN
- Liste reservierter Wörter falsch dargestellt mit 'entry'
- max. gleichzeitig geöffnete Datenströme falsch mit Absolutzahl genannt => richtig ist FOPEN_MAX
- Behauptung, strdup wäre eine Standardfunktion => falsch, ist keine
- Behauptung, Zeiger wären im 64Bit-Betriebssystem 64 Bit lang, bei 32Bit 32 Bit lang => falsch, die Bitlänge von Datentypen hängt vom Compilat ab und NICHT
von der Laufzeitumgebung; bspw. sind Zeiger in 32-Bit compilierten Programmen nach wie vor 32 Bit lang (meistens), auch wenn sie unter einem 64Bit Betriebsystem laufen
- die Behauptung, switch/case vergleiche nur Einzelwerte => da die Autoren den gcc als das Mittel ihrer Wahl auserkoren haben, fehlt hier der Hinweis, dass
der gcc case ranges unterstützt (als spezifische Compilererweiterung), also 'case 1 ... 99:' möglich ist
- die Behauptung, dass keine Binärliterale möglich seien da die Autoren den gcc als das Mittel ihrer Wahl auserkoren haben, fehlt hier der Hinweis, dass
der gcc Bereiche verarbeiten kann (0b01010101)
Die Autoren kennen also nicht nur die C-Standards nicht und verwechseln hierbei ständig sondern sie kennen auch die gcc-Features offensichtlich nicht, d.h.
sie haben auch den gcc-Featuremodus (gnu99) gegenüber dem gcc-strict Modus nicht verstanden
- ständige Verwechslung von Deklaration mit Definition
- Datentyp der Rückgabe von sizeof ist implementierungsabhängig => falsch, ist immer size_t
Prinzipielle Verständnisschwierigkeiten bei size_t offenbaren die Autoren auch weiterhin:
- sizeof wird während der Compilierung berechnet => falsch, beim von den Autoren favorisierten C99 gibt es die Ausnahme VLA
- weiterhin machen sie auch noch den printf-Fehler mit %z => richtig ist %zu
bzw. sie benutzen sogar einen Cast printf("%u",(unsigned int)sizeof(wert));
Cast zeigen bis auf ganz wenige Ausnahmen (die die Autoren nicht nennen/kennen) immer an, dass das Programmdesign nicht stimmt, und gehört ganz gewiss nicht in ein Lehrbuch.
Ungeniert casten die Autoren auch mal ein const weg, sowas geht GAR NICHT, schon GAR NICHT in einem Lehrbuch:

int cmp(const void *a,const void *b)
{
int x=*(int*)a;
int y=*(int*)b;
return a - b;
}
Bei dieser Callback-Funktion für qsort zeigt sich auch wieder das grundlegende Unverständnis der Autoren zu C und ihre Praxisferne, denn neben dem Wegcasten
von const begehen sie hier 2 weitere Anfänger-Fehler:
- liegen a und/oder b an den int-Grenzen, liefert die Funktion ein falsches Ergebnis (wegen int-Über/Unterlauf)
- ein signed int-Über/Unterlauf ist auch gleichzeitig UB ( den Autoren aber wohl unbekannt, wie schon erwähnt, kommt dieses wichtige Kriterium bei den
Autoren nie vor, ein weiteres Index für deren Inkompetenz und Praxisferne )

Beim wichtigen Thema Pointer und Arrays scheitern die Autoren auch wieder kläglich, indem sie den weit verbreiteten Anfängerglauben aufsitzen und behaupten,
"Im Prinzip arbeitet eine Array-Variable wie ein Zeiger"; "im Prinzip" heißt ja wohl, dass es Ausnahmen gibt, welche, bleiben die Autoren schuldig.
"Adresse einer Array-Variablen ist die Array-Variable selbst" d.h. array == &array ; was absoluter Unsinn ist, aus mehreren Gründen, die alle den
Autoren nicht bekannt sind, sonst würden sie diese sinnfreie Aussage nicht machen.
Verständnis über Pointer ist DIE essentielle Grundlage bei C, die Autoren haben dieses Verständnis nachweislich eindeutig nicht.

Ein ganzes Kapitel verwenden die Autoren auf Funktionen, die angeblich zuvor nicht deklariert werden brauchen, aber trotzdem verwendet werden dürfen.
Der C99 Standard schreibt eindeutig vor, dass dies NICHT (mehr) erlaubt ist, alle Versuche der Autoren, in dem Kapitel aufzuzeigen, wie der Compiler in diesem Fall vorgeht und was zu beachten ist, sind also standardinkonform und somit falsch, gehören nicht in ein Lehrbuch usw...
Zumal sie bei ihren 'Erklärungen' auch nur auf die Promotion des Rückgabewertes solcher Funktionen eingehen; die viel wichtigere weil häufiger (unter C89) angewendete default argument promotion erwähnen, erklären und zeigen sie nicht.
Das ganze Kapitel ist unbrauchbar, dabei hatten die Autoren doch zu Beginn des Buches versprochen, jeweils darauf hinzuweisen, wenn Features bestimmter C-Standards (C89/C99/C11) verwendet werden. Es spricht vieles dafür, dass die Autoren aufgrund ihres eigenen fehlenden Standard-Wissens den Überblick in ihrem eigenen Werk verloren haben, wenn sie ihn denn jemals besessen haben.

Im Kapitel über Multithreading empfehlen sie für die Windows-Plattform cygwin, ohne den Leser auf win32-pthreads hinzuweisen, die die POSIX pthreads nahezu identisch abbilden, der Leser kommt damit also ohne die aufwändige Abhängigkeit von cygwin aus und kann die Quelltexte direkt anwenden.

Beim Thema Datenstrukturen werden ausschließlich die praxisuntauglichen verketteten Listen behandelt,
Beispiele zu den aufgelisteten Maps findet der Leser nicht.

Allgemeine Hinweise zum Programmdesign sucht man im Buch vergebens, lapidare Empfehlungen wie
'verwenden sie globale Variablen möglichst wenig' => statt (verwenden sie nie globale Variablen)
tragen ebenfalls wenig zur Praxistauglichkeit der vorgestellten Quelltexte (welche häufig davon unnötig Gebrauch machen) bei.
Ebenfalls fehlen Hinweise zum Umgang mit const/volatile/inline und zu assert für die Absicherung von Bedingungen; alles bekannte Hilfsmittel, die bei einer praxisorientierten C-Programmierung bzw. beim Design unumgänglich sind, und frühzeitig (schon zur Compilezeit) auf Designfehler hinweisen.

Fazit:
Die Autoren haben ein unbrauchbares Buch mit vielen grundsätzlichen Fehlern abgeliefert, welches utopisch weit vom selbstgesteckten Ziel "bestes C-Buch aller Zeiten" entfernt ist. Sie und ihre 'technischen Gutachter' haben kläglich versagt beim Versuch, dem Leser einen fundierten und belastbaren Einstieg in C zu ermöglichen.
Die Autoren verstecken ihr mangelndes Grundlagenwissen, ihr laienhaftes Verständnis vom Programmdesign und ihr nachweislich praxisuntaugliches Coding hinter selbsternannten 'wissenschaftlichen Lernmethoden'.
Ein marodes Fundament lässt sich von einer blendenden Fassade bestenfalls kaschieren und wird bei jeder Belastung zusammenbrechen.
626 Seiten geballte Unsicherheit bei Grundlagen+Coding sind auch mit 'wissenschaftlichem' Deckmantel niemandem zu empfehlen.
Helfen Sie anderen Kunden bei der Suche nach den hilfreichsten Rezensionen 
War diese Rezension für Sie hilfreich? Ja Nein

[Kommentar hinzufügen]
Kommentar posten
Verwenden Sie zum Einfügen eines Produktlinks dieses Format: [[ASIN:ASIN Produkt-Name]] (Was ist das?)
Amazon wird diesen Namen mit allen Ihren Beiträgen, einschließlich Rezensionen und Diskussion-Postings, anzeigen. (Weitere Informationen)
Name:
Badge:
Dieses Abzeichen wird Ihnen zugeordnet und erscheint zusammen mit Ihrem Namen.
There was an error. Please try again.
">Hier finden Sie die kompletten Richtlinien.

Offizieller Kommentar

Als Vertreter dieses Produkt können Sie einen offiziellen Kommentar zu dieser Rezension veröffentlichen. Er wird unmittelbar unterhalb der Rezension angezeigt, wo immer diese angezeigt wird.   Weitere Informationen
Der folgende Name und das Abzeichen werden mit diesem Kommentar angezeigt:
Nach dem Anklicken der Schaltfläche "Übermitteln" werden Sie aufgefordert, Ihren öffentlichen Namen zu erstellen, der mit allen Ihren Beiträgen angezeigt wird.

Ist dies Ihr Produkt?

Wenn Sie der Autor, Künstler, Hersteller oder ein offizieller Vertreter dieses Produktes sind, können Sie einen offiziellen Kommentar zu dieser Rezension veröffentlichen. Er wird unmittelbar unterhalb der Rezension angezeigt, wo immer diese angezeigt wird.  Weitere Informationen
Ansonsten können Sie immer noch einen regulären Kommentar zu dieser Rezension veröffentlichen.

Ist dies Ihr Produkt?

Wenn Sie der Autor, Künstler, Hersteller oder ein offizieller Vertreter dieses Produktes sind, können Sie einen offiziellen Kommentar zu dieser Rezension veröffentlichen. Er wird unmittelbar unterhalb der Rezension angezeigt, wo immer diese angezeigt wird.   Weitere Informationen
 
Timeout des Systems

Wir waren konnten nicht überprüfen, ob Sie ein Repräsentant des Produkts sind. Bitte versuchen Sie es später erneut, oder versuchen Sie es jetzt erneut. Ansonsten können Sie einen regulären Kommentar veröffentlichen.

Da Sie zuvor einen offiziellen Kommentar veröffentlicht haben, wird dieser Kommentar im nachstehenden Kommentarbereich angezeigt. Sie haben auch die Möglichkeit, Ihren offiziellen Kommentar zu bearbeiten.   Weitere Informationen
Die maximale Anzahl offizieller Kommentare wurde veröffentlicht. Dieser Kommentar wird im nachstehenden Kommentarbereich angezeigt.   Weitere Informationen
Eingabe des Log-ins
  [Abbrechen]

Kommentare

Kommentare per E-Mail verfolgen
Von 2 Kunden verfolgt

Sortieren: Ältester zuerst | Neuester zuerst
1-4 von 4 Diskussionsbeiträgen
Ersteintrag: 04.09.2014 17:41:17 GMT+02:00
Zuletzt vom Autor geändert am 04.09.2014 17:58:39 GMT+02:00
Alternative meint:
Aus der Rezension:

int cmp(const void *a,const void *b)
{
int x=*(int*)a;
int y=*(int*)b;
return a - b;
}

Der vorstehende Code ist totaler Schrott.
Es werden zwei void-Pointer voneinander subtrahiert.
Das geht schon mal garnicht.
Dann entstünde der Typ ptrdiff_t, der aber nicht
dem Return-Typ entspricht.
Weg-casten von const ist unfein, man kann es aber machen,
wenn nachfolgend garantiert kein Schreibzugriff erfolgt.
Einen vernünftigen Grund dafür gibt es aber nicht.

Falls
. return x - y;
gemeint ist, wäre weg-casten von const tolerabel, denn
beispielsweise *(int*)a = k;
liegt ja nicht vor.
(Mit x oder y ist kein Schreibzugriff auf *a oder *b möglich.)

return -30000 - 25000;
ergibt natürlich nicht -55000 bei 16bit-int, weshalb
eine Subtraktion hier eine beknackte Operation ist.
Ich habe seit 1978 noch nie eine Subtraktion bei
qsort-cmp verwendet, sondern meist if-else kombiniert
mit return 1 : 0 : -1.

Veröffentlicht am 20.02.2015 13:21:46 GMT+01:00
rhedev meint:
Man beachte: fast alle - bis auf eine - der derzeit fünfundzwanzig (25) von "MAX" vorliegenden Rezensionen zum Thema C-Programmierung enden mit nur einem Stern unter bevorzugtem Gebrauch von Schlagwörtern wie "inkompetent, unbrauchbar, veraltet, oberflächlich, fehlerhaft, schlecht, katastrophal, lückenhaft, widersprüchlich, laienhaft, inhomogen, unbrauchbar ..." etc., und besonders gern "NAIV". Die Kritik ist ja jeweils auch mit Beispielen untermauert, scheint es so von außen, also mag sie durchaus gerechtfertigt sein. Aber: wenn von 25 Büchern zum Thema C-Programmierung nur ein einziges mit - man glaubt es kaum - vollen zwei Sternen, alle Anderen mit nur einem Stern bewertet werden, fragt man sich doch als Suchender: gibt es denn überhaupt deutschsprachige Titel zum Thema C-Programmierung, die nicht "Naiv, inkompetent, unbrauchbar, veraltet, ..." usw. sind? Oder sind deutschsprachige Akademiker letztendlich einfach nicht in der Lage einen qualitativ akzeptablen Titel zum Thema C-Programmierung zu verfassen?

Ein kleiner Tipp oder Hinweis von "MAX" - oder eventuell mal eine positive Rezension? - wären hier für den Leser sehr sehr hilfreich, deshalb lese ich kritische Rezensionen ja bevorzugt, denn wer letztendlich permanent streng mit anderen in's Gericht geht kennt doch sicher auch die positiven Beispiele? So es sie gibt... Also: welchen C-Prog.-Titel würde "MAX" denn für den professionellen Einstieg empfehlen? [gern auch mehrere...]

Danke-Danke an "MAX" im Voraus!!!

Antwort auf einen früheren Beitrag vom 20.02.2015 17:26:45 GMT+01:00
Alternative meint:
Die Top 100 der C-Bücher durchsuchen, nach Titeln, die eben nicht
von 'Max' rezensiert wurden.
Finde ich logisch.
Dabei nicht nach möglichst vielen Sternen suchen.

Antwort auf einen früheren Beitrag vom 08.06.2015 09:34:03 GMT+02:00
Max bewertet wohl extrem gerne Bücher über Programmiersprache "C" - siehe http://www.amazon.de/gp/pdp/profile/A2P0DS0HZIAYM2/ref=cm_cr_dp_pdp
- per Copy Paste Logik was die Überschrift angeht.

Danke für den Hinweis zur Person!
‹ Zurück 1 Weiter ›

Details

Artikel

Rezensentin / Rezensent


Top-Rezensenten Rang: 22.973