Von Christopher Roy Bratusek am Do, 8. Oktober 2009 um 18:32 #
Nicht das ich wüsste, war eher Wunschdenken. Gut, das wäre ein Wälzer von 35.000 Seiten (wir-bleiben-kompatible-bis-in-die-Steinzeit-Ideologie sei Dank), aber egal. Nicht das so ein Buch notwendig wäre, schön wärs halt trotzdem.
Es gibt ältere Bücher dazu, die aber nicht mehr aufgelegt werden. Hier kann man sich durchklicken: http://oreilly.com/openbook/ (unter "Out-of-Print Books")
"MH & xmh: Email for Users & Programmers" klingt ganz nach einer Alternative zu mutt. Benutzt jemand zufällig das Programm von euch? Wie kommt es so mit UTF-8 und Attachments zurecht?
Ja, sehe ich auch so. Hoffentlich können wir uns irgendwann mal komplett von dem nervigen X.org-Ballast trennen. KMS ist schon ein guter Anfang und läuft mit meiner Intel-GMA-Karte bestens. Schade nur, dass das Projekt, Wayland, in welches wir unsere ganze Hoffnung gesteckt haben, nicht mehr weiterentwickelt wird. Der Code ist jedenfalls zum Glück noch überschaubar, sodass ein Fork vorstellbar wäre. Wenigstens ging der Wayland-Entwickler gleich den richtigen Weg, irrsinnige Ideen wie Netzwerktransparenz gar nicht erst zu implementieren.
Von Anonymous Coward am Do, 8. Oktober 2009 um 22:47 #
Wo hast Du denn her, dass Wayland nicht weiterentwickelt wird? In Kristian Hogsbergs Blog steht nichts davon, und in der Newsgroup auch nicht. Ach, btw: Ich schreibe das gerade in einer Firefox-Instanz, die auf meiner großen Kiste läuft, während ich selbst mit dem Netbook im Bett liege. Dreimal darfst Du raten, wie das funktioniert.
Von Joerg Zweier am Fr, 9. Oktober 2009 um 04:05 #
Dass es nicht mehr weiterentwickelt wird, habe ich dem letzten Commit aus seinem Repository entnommen, welcher schon etwas laenger zurueckliegt.
Fuer den Remote-Zugriff benutzt du wahrscheinlich x11vnc. Ist schnell eingerichtet und man braucht kein ueberladenes OpenSSH. Tunneln kann man die Verbindung aber trotzdem, wenn man denn will.
Sicher, Thin Clients braucht ja keiner... Ist dir überhaupt bewusst was du da sagst?
Jährlich werden Milliarden in Lizenzen für Citrix, Windows Terminal Server, Nomachine NX etc. investiert und du willst die freie Lösung dafür abschaffen?
Ich würde mich gerne mit der C-Programmierung beschäftigen, von daher wäre es schön, wenn sich jemand mal etwas zur Qualität des Buches äußert. Vermittelt es die C-Programmierung so, wie das heute "state-of-the-art" ist, oder werden da veraltete Inhalte gelehrt? Gerade bei Programmierbüchern scheint es ja viel Schrott zu geben, nachdem, was ich bisher so gelesen habe....
Wenn man wirklich C lernen möchte ist es sicher die beste Investition die man machen kann. In der neuen Auflage diese Buch befindet sich auch eine genaue Einführung in den C Headerdateien sowie den aktuellen C99 Standard.
> Programmieren von Anfang an — von Helmut Erlenkötter
Achtung! Dieses Buch ist aus fachlicher Sicht absolut nicht empfehlenswert. Es hält sich zumindest überhaupt nicht an gängige Standarts. Es mag aus didaktischer Sicht okay sein. Ich habe zweimal reingeschaut und mit ekel wieder weggelegt.
Und anders als andere Fachbücher die ich gelesen habe steht nicht nur viel drin, sondern der Stil des Autors ist auch flüssig zu lesen. Das ist zumindest meine Meinung. Hilft beim Einstieg und ist auch später noch als Nachschlagewerk zu gebrauchen.
Das ist ja didaktisch der grösste Müll der je verbrochen wurde, von den fachlichen Mängeln gar nicht erst zu reden. Das A-Z Buch ist ja schon schelcht aber im Vergleich zu dem Wikibuch ist es Gold.
Und wer hier wie weiter oben oder unten den K&R empfiehlt, der hat auch schon lange den Schuss nicht mehr gehört.
Es gibt ja auch Leute die an allem was aus zusetzten haben Ich hab mir zumindest rudimentäre Kenntnisse in C mit dem Buch angeeignet und fand es sehr gut aufgebaut. Und dazu lässt es sich wirklich sehr angenehm lesen. Daher werde ich mich auch die anderen Werke von ihm zu C++ und Qt4 zulegen.
Von sind meiner Meinung nach seine Werke für alle Einsteiger und als Nachschlagwerk sehr gut geeignet. Und die Bewertungen auf bspw. Amazon sind auch sehr gut. Also so schlecht kann es nicht sein ...
Naja, Fehler und unsaubere Formulierungen sind schon ärgerlich. Für einen anspruchslosen Hobbyprogrammierer, der nur mal reinschnuppern will, mögen das Spitzfindigkeiten sein. Ein Informatiker oder Berufsprogrammierer verlässt sich dann besser auf andere Literatur. Für den Einstieg in C ist der K&R samt Übungsbuch noch immer das Maß der Dinge und dabei auch gut verständlich. Die Fülle an Themen bietet der K&R sicher nicht, dafür ist das was er bietet die Referenz schlechthin.
Okay, für hardwarenahe Sachen führt wohl kein Weg an C vorbei. Aber schon bei GUI-Anwendungen C zu wählen finde ich ziemlich daneben. Und Webanwendungen in C? Wer kommt denn auf so eine Idee?
Warum? Ist doch eine gute Idee? Ich kann nicht ganz deine Aversion nachvollziehen.
Webanwendungen werden schließlich auch gerne in C++ geschrieben, wenn es darauf ankommt, dass viele AJAX-Anfragen in kurzer Zeit bearbeitet werden müssen. Dass Spawnen eines großen Interpreters ist schon ziemlich Ressourcen-intensiv und verwendet nur unnötige CPU-Zeit.
Schon mal was von kleinen ARM/MIPS/Whatever-Boxen und dergleichen gehört? Hast Du vielleicht sogar eine FritzBox oder etwas ähnliches zu Hause? Das Webinterface will irgendwie laufen.
Von Anonymous Coward am Fr, 9. Oktober 2009 um 13:31 #
Ja, ich habe hier einen WRT54G mit OpenWrt-Firmware. Beim Webinterface (Lua Configuration Interface, kurz LuCI) sind gerade die Arbeiten im Gange, den CGI-Mist loszuwerden und durch einen in Lua geschriebenen Webserver zu ersetzen.
Von Joerg Zweier am Fr, 9. Oktober 2009 um 04:38 #
So genial das Konzept von FastCGI auch sein mag, ist es dennoch nicht das Effizienteste. Als Vergleich bringe ich immer ganz gerne den RAM-Verbrauch: Stelle dir eine virtuelle Maschine mit KDE4 vor, die 512 MB benoetigt. Du hast 100 Clients und willst die alle auf so wenig Servern wie moeglich unterbringen. Bei 100 Clients waeren das demzufolge ~51 GB RAM. Jetzt kommt jemand her und schafft es, KDE4 so zu optimieren, dass bei gleicher Benutzung nur noch 128 MB erforderlich sind. Das haette demzufolge eine grosze Auswirkung auf die gesamte Anzahl an benoetigtem RAM. Auf einmal kann man das Fuenf-fache (!) an Anwendern auf einem Server unterbringen! So sieht es auch bei FastCGI aus. Es ist effizient, keine Frage, aber es hat auch Probleme. Momentan reicht es mir auch fuer meine Beduerfnisse, weil es einfach zu konfigurieren ist und sehr gut funktioniert, aber wenn ich eine grosze Webseite fuehrte, ist ganz klar FastCGI eben nicht die erste Wahl. Warum haben denn die Python'ler ein eigenes, effizienteres FastCGI - SCGI - entwickelt? Was man letztendlich benutzen sollte, haengt immer vom Einzelfall ab. Genauso wie beim KDE4-Beispiel oben. In der Praxis sieht es doch eher so aus, dass man von vornherein einen Fenstermanager nimmt oder wenigstens eine leichtgewichtige Desktopumgebung. Fuer Desktop-Computer kann die Entscheidung jedoch trotzdem auf KDE4 treffen, weil die Beduerfnisse und Anforderungen sind nun mal ganz andere sind. Wo es beim Servereinsatz (Virtualisierung) KDE4 vielleicht unangebracht ist (haengt jedoch auch wieder vom Einzelfall ab), kann es woanders ideal sein.
Was ich damit sagen moechte: Von vornherein bestimmte Loesungen ganz pauschal zu verdammen, bringt niemandem etwas. Weder den Mitlesern hier, die einen falschen Eindruck bekommen, noch den Entwicklern solcher Frameworks, den es als Folge an Anwendern und Kunden mangelt.
"Und Webanwendungen in C? Wer kommt denn auf so eine Idee?"
Komplette Webanwendungen wird auch niemand in C schreiben, aber wenn du z.B. PHP neue Funktionalität spendieren möchtest z.B. Verarbeiten eines spezielle Binärdateiformats, so biste hier z.B. mit C genau richtig. Ich hab einige Erweiterungen für PHP mit C geschrieben, ist ne feine Sache.
Hab mir das Buch gerade mal flüchtig angeschaut. Ich rate dringend davon ab, es zu kaufen oder auch nur ernsthaft durchzulesen. Das Werk strotzt nur so vor Fehlern!! Von der Qualität her kann's in etwa mit "Bullschildt" mithalten.
Von Joerg Zweier am Fr, 9. Oktober 2009 um 04:09 #
Immer gleich alles pauschalisieren...
Nur wegen ein, zwei Fehlern gleich das ganze Buch zu kritisieren, ist voellig unangebracht. Der Rest des Inhalts wird schon stimmen und wenn die Fehler so offensichtlich sind, wird (hoffentlich) selbst der Leser nicht darueber hinweglesen. Ein bisschen Verstand sollte man schon voraussetzen duerfen und grundsaetzlich ist das Mitdenken beim Lesen mitzudenken durchaus zu empfehlen.
Davon das diese Buch nichtmal einen Monat im handel ist kann man solche fehler ruhig melden zumal dann Buchupdates rausgegeben werden zum Download und das bietet nicht jeder verlag.
Also ich finde dne Autor "Jürgen Wolf" genial! Das Buch C von A bis Z hat in meinen Augen kaum bis gar keine Fehler und für Einsteiger ist es wirklich das Beste Buch auf dem Markt. Ich kann es nur empfehlen, genauso wie die ganzen andren Bücher von Herrn Wolf.
> Zuerst benötigen Sie einen beliebigen ASCII-Texteditor. Überhaupt scheint der Autor nur ASCII zu kennen, und so tolle Zeichensätze wie EBCDIC zu ignorieren. > Zunächst wird in C zwischen dem Basic-Zeichensatz, dem Ausführungszeichensatz und den Trigraph-Zeichen unterschieden. Falsch. Es wird in "source character set" und "execution character set" unterteilt, diese beiden jeweils in "basic" und "extended". > die zehn Dezimalziffern: 1 2 3 4 5 6 7 8 9 0 Nicht falsch, aber die 0 gehört vor 1. Erwähnenswert wäre auch, dass die Zeichen-Werte von 0 bis 9 direkt in einer Reihe liegen, die von anderen Zeichen (außer \0) aber nicht näher spezifiziert sind. (Siehe auch EBCDIC.) > Den Begriff Bezeichner verwendet man für Namen von Objekten im Programm. Dazu gehören Variablen, Funktionen usw. Funktionen sind keine Objekte. > Schlüsselwörter [..] »int« Nein, int ist kein Schlüsselwort, sondern ein Typ. > zwei Hochkommata " ist gemeint. Man kann die als double quotes, Anführungszeichen oder gerne auch als doppelte Hochkommata bezeichnen. aber ''foo'' wird hier nicht funktionieren. > Standardfehlerausgabe (stderr), die laut ANSI C niemals vollgepuffert sein darf. Das ist mir neu. Es ist beim Programmstart unbuffered, das lässt sich aber mit setbuf o.ä. ändern. > fflush(stdin); Es wird darauf hingewiesen, dass das nicht überall geht. Der Standard sagt auch explizit, dass dies undefined behaviour verursacht. Warum wird diese "Möglichkeit" dann überhaupt erwähnt? > do {scanf("%c",&a);} while ( getchar() != '\n' ); xy[return] > Die Funktion scanf() ist nicht gegen einen Pufferüberlauf (Buffer-Overflow) geschützt char x[20]; scanf("%19s", x); /* muss man halt die Puffergröße spezifizieren. */ > Auch mit printf() kann es einen Pufferüberlauf geben, sollte der Text länger sein als erlaubt. Nö. C99 sagt nur: The number of characters that can be produced by any single conversion shall be at least 4095. Mit Buffer Overflows hat das erstmal gar nichts zu tun. > Größe von short 2 Byte = 16 Bit (und diverse andere Beispiele für Größen und Wertebereiche). C spezifiziert die Größen nicht, nur Minimalwerte des Bereichs. Auch sollte das Buch auf unterschiedliche Darstellungen von negativen Zahlen eingehen. > Die ASCII-Code-Tabelle ist eine Tabelle, an die sich alle Programmierer der Welt halten müssen. Sie enthält alle Zeichen, die der Computer darstellen kann. *löl* > weil in C nicht festgelegt ist, ob dieser Datentyp [unsigned char] mit oder ohne Vorzeichen interpretiert wird. Da steht das doch schon: unsigned char. > Unicode 0 ... 65535 Für UCS-2 mag das stimmen, für Unicode nicht.
Ach, ich hab keine Lust mehr. Hier noch ein Highlight von einer zufällig gewählten Seite: > Einige Vorteile von CGI-Anwendungen, die in C erstellt wurden [...] Da der Quelltext bei Executables nicht offen ist, lassen sich Sicherheitsfunktionen hervorragend verstecken. Gerade diesen Sicherheitsaspekt gilt es besonders hervorzuheben. Ohne Kommentar.
Die Buecher sind im Grunde verstaendlich, aber es gibt einige Fehler darin die der Author ueberarbeiten sollte. (ich denke ueber Mails an ihn sollte das in weiteren Auflagen machbar sein)
Aber zum Einstieg ist das eh nur bedingt relevant.
Ich stoeber gern durch die www.c-faq.com und natuerlich K&R C - Programming Language um mein C Wissen zu erweitern. Gehoert zwar weniger hierher und ist reine Geschmackssache, doch zum Programmierstil kann ich nur die linux-2.6/Documentation/CodingStyle empfehlen.
Kann ich nicht nachvollziehen. Wenn ich mir die Fehler anschaue, die durch den Coding-Style (Klammerung beispielsweise) im Kernel gelandet sind, dann frage ich mich teilweise schon recht oft, warum daran immer noch festgehalten wird. Ah, stimmt - weil es ja LT so macht
> Mindestens 3/4 deiner "Kritik" ist Haarsplaterei...
Mindestens 100% der Sprache C sind Haarspalterei. Die Beispiele von Programmierung mittels C gegen Implementierungen sind ja recht nett für Übungen und erste Gehversuche. Als eine Referenz zu C ist das Buch definitiv kontraproduktiv.
Sorry, ich war vielleicht etwas ungenau mit meiner Frage. Die erste Zeile mit dem Einlesen bis zum return-Zeichen war soweit klar. Nur verstehe ich irgendwie den Zusammenhang mit 'xy[return]' nicht. Ist das äquivalent, oder habe ich irgend einen Witz nicht verstanden?
Falsch. Es werden in jedem Schleifendurchlauf jeweils zwei Zeichen eingelesen, erst mit scanf(), dann mit getchar(). Das erste Zeichen wird in der Variablen a gespeichert, das zweite wird darauf überprüft, ob "Return" gedrückt wurde.
Bei xy[return] läuft das jetzt so ab: x landet in a, y wird mit '\n' verglichen (ist !=), [return] landet in a, das Programm wartet aufs nächste Zeichen. Wulf wollte damit wohl ein Eingabebeispiel geben, bei dem der Code eben nicht das tut, was du und wahrscheinlich viele andere geglaubt haben, dass er das tut.
Ich kann dem Code überhaupt keinen Sinn entlocken. Einen String bis zum Zeilenumbruch einlesen funktioniert jedenfalls ganz anders. Und wenn man nur auf die Eingabetaste wartet, sollte man das scanf() weglassen und nur getchar() verwenden oder den in a eingelesenen Wert mit '\n' vergleichen statt mittels getchar() das darauf folgende Zeichen einzulesen.
Das Codebeispiel dyn_array3.c in Kapitel 14.7 (Dynamische Arrays) ist beispielsweise ein einziges Memory-Leak, was dir auch jeder Memory-Profiler wie valgrind bestätigen wird. Es wird nach dem Umkopieren in den neuen Speicherbereich der alte nicht freigegeben. Und das, nachdem in Kapitel 14.5 die Funktion free() erklärt wurde. Zudem wird zweimal umkopiert, was unnötig ist, da es ausreicht, die Zieladresse des Zeigers nach der Freigabe das alten Speicherbereiches auf den neu angelegten Speicherbereich umzubiegen.
Von Anders Seher am Mo, 12. Oktober 2009 um 15:47 #
>> Also: Finger weg von diesem Mist. <<
Sehe ich nicht so. Das Buch ist sehr gut. Die hier angesprochenen Fehler sind keine. Wenn es Ungenauigkeiten gibt, kann man sie dem Autor / Autorenteam mailen.
Ich habe das Buch und schaue gerne mal rein, wenn ich C-Probleme habe.
> Sehe ich nicht so. Das Buch ist sehr gut. Die hier angesprochenen Fehler sind keine. Wenn es > Ungenauigkeiten gibt, kann man sie dem Autor / Autorenteam mailen.
Sehe ich nicht so. Das Buch ist ja schon mehrere Jahre auf dem Markt und wesentliche Fehler sind noch immer nicht korrigiert obwohl sie bekannt sind und auch schon oft genannt wurden.
Hier kann man sich durchklicken:
http://oreilly.com/openbook/
(unter "Out-of-Print Books")
Ja, sehe ich auch so. Hoffentlich können wir uns irgendwann mal komplett von dem nervigen X.org-Ballast trennen. KMS ist schon ein guter Anfang und läuft mit meiner Intel-GMA-Karte bestens. Schade nur, dass das Projekt, Wayland, in welches wir unsere ganze Hoffnung gesteckt haben, nicht mehr weiterentwickelt wird.
Der Code ist jedenfalls zum Glück noch überschaubar, sodass ein Fork vorstellbar wäre. Wenigstens ging der Wayland-Entwickler gleich den richtigen Weg, irrsinnige Ideen wie Netzwerktransparenz gar nicht erst zu implementieren.
Ach, btw: Ich schreibe das gerade in einer Firefox-Instanz, die auf meiner großen Kiste läuft, während ich selbst mit dem Netbook im Bett liege. Dreimal darfst Du raten, wie das funktioniert.
Commit aus seinem Repository entnommen, welcher schon etwas laenger
zurueckliegt.
Fuer den Remote-Zugriff benutzt du wahrscheinlich x11vnc. Ist
schnell eingerichtet und man braucht kein ueberladenes OpenSSH.
Tunneln kann man die Verbindung aber trotzdem, wenn man denn will.
Fasch, es war per ssh.
Sicher, Thin Clients braucht ja keiner... Ist dir überhaupt bewusst was du da sagst?
Jährlich werden Milliarden in Lizenzen für Citrix, Windows Terminal Server, Nomachine NX etc. investiert und du willst die freie Lösung dafür abschaffen?
1.116 S.
ISBN 3-89842-643-2
In der neuen Auflage diese Buch befindet sich auch eine genaue Einführung in den C Headerdateien sowie den aktuellen C99 Standard.
Programmieren von Anfang an von Helmut Erlenkötter
hat mir bei meinen C Anfängen sehr geholfen.
Grüße
Achtung! Dieses Buch ist aus fachlicher Sicht absolut nicht empfehlenswert. Es hält sich zumindest überhaupt nicht an gängige Standarts. Es mag aus didaktischer Sicht okay sein. Ich habe zweimal reingeschaut und mit ekel wieder weggelegt.
Und anders als andere Fachbücher die ich gelesen habe steht nicht nur viel drin, sondern der Stil des Autors ist auch flüssig zu lesen. Das ist zumindest meine Meinung. Hilft beim Einstieg und ist auch später noch als Nachschlagewerk zu gebrauchen.
Und wer hier wie weiter oben oder unten den K&R empfiehlt, der hat auch schon lange den Schuss nicht mehr gehört.
Ich hab mir zumindest rudimentäre Kenntnisse in C mit dem Buch angeeignet und fand es sehr gut aufgebaut.
Und dazu lässt es sich wirklich sehr angenehm lesen. Daher werde ich mich auch die anderen Werke von ihm zu C++ und Qt4 zulegen.
Von sind meiner Meinung nach seine Werke für alle Einsteiger und als Nachschlagwerk sehr gut geeignet. Und die Bewertungen auf bspw. Amazon sind auch sehr gut. Also so schlecht kann es nicht sein ...
Gruß
Embedded mit Web-Gui.
Webanwendungen werden schließlich auch gerne in C++ geschrieben, wenn es darauf ankommt, dass viele AJAX-Anfragen in kurzer Zeit bearbeitet werden müssen. Dass Spawnen eines großen Interpreters ist schon ziemlich Ressourcen-intensiv und verwendet nur unnötige CPU-Zeit.
nicht das Effizienteste. Als Vergleich bringe ich immer ganz gerne
den RAM-Verbrauch: Stelle dir eine virtuelle Maschine mit KDE4 vor,
die 512 MB benoetigt. Du hast 100 Clients und willst die alle auf so
wenig Servern wie moeglich unterbringen. Bei 100 Clients waeren das
demzufolge ~51 GB RAM. Jetzt kommt jemand her und schafft es, KDE4
so zu optimieren, dass bei gleicher Benutzung nur noch 128 MB
erforderlich sind. Das haette demzufolge eine grosze Auswirkung auf
die gesamte Anzahl an benoetigtem RAM. Auf einmal kann man das
Fuenf-fache (!) an Anwendern auf einem Server unterbringen! So sieht
es auch bei FastCGI aus. Es ist effizient, keine Frage, aber es hat
auch Probleme. Momentan reicht es mir auch fuer meine Beduerfnisse,
weil es einfach zu konfigurieren ist und sehr gut funktioniert, aber
wenn ich eine grosze Webseite fuehrte, ist ganz klar FastCGI eben
nicht die erste Wahl. Warum haben denn die Python'ler ein eigenes,
effizienteres FastCGI - SCGI - entwickelt? Was man letztendlich
benutzen sollte, haengt immer vom Einzelfall ab. Genauso wie beim
KDE4-Beispiel oben. In der Praxis sieht es doch eher so aus, dass
man von vornherein einen Fenstermanager nimmt oder wenigstens eine
leichtgewichtige Desktopumgebung. Fuer Desktop-Computer kann die
Entscheidung jedoch trotzdem auf KDE4 treffen, weil die Beduerfnisse
und Anforderungen sind nun mal ganz andere sind. Wo es beim
Servereinsatz (Virtualisierung) KDE4 vielleicht unangebracht ist
(haengt jedoch auch wieder vom Einzelfall ab), kann es woanders
ideal sein.
Was ich damit sagen moechte: Von vornherein bestimmte Loesungen
ganz pauschal zu verdammen, bringt niemandem etwas. Weder den
Mitlesern hier, die einen falschen Eindruck bekommen, noch den
Entwicklern solcher Frameworks, den es als Folge an Anwendern und
Kunden mangelt.
Komplette Webanwendungen wird auch niemand in C schreiben, aber wenn du z.B. PHP neue Funktionalität spendieren möchtest z.B. Verarbeiten eines spezielle Binärdateiformats, so biste hier z.B. mit C genau richtig. Ich hab einige Erweiterungen für PHP mit C geschrieben, ist ne feine Sache.
schau dir mal den verfügbaren sourcecode von diversern routern an, also DD-WRT, Tomato, ...
Auf einem Gerät mit nur 4MB Speicher und 16MB ram lässt sich nicht einfach mal ein p* interpreter inkl. MVC-Framework unterbringen.
Von der Qualität her kann's in etwa mit "Bullschildt" mithalten.
Also: Finger weg von diesem Mist.
Nur wegen ein, zwei Fehlern gleich das ganze Buch zu kritisieren, ist voellig unangebracht. Der Rest des Inhalts wird schon stimmen und wenn die Fehler so offensichtlich sind, wird (hoffentlich) selbst der Leser nicht darueber hinweglesen. Ein bisschen Verstand sollte man schon voraussetzen duerfen und grundsaetzlich ist das Mitdenken beim Lesen mitzudenken durchaus zu empfehlen.
Das Buch C von A bis Z hat in meinen Augen kaum bis gar keine Fehler und für Einsteiger ist es wirklich das Beste Buch auf dem Markt. Ich kann es nur empfehlen, genauso wie die ganzen andren Bücher von Herrn Wolf.
Überhaupt scheint der Autor nur ASCII zu kennen, und so tolle Zeichensätze wie EBCDIC zu ignorieren.
> Zunächst wird in C zwischen dem Basic-Zeichensatz, dem Ausführungszeichensatz und den Trigraph-Zeichen unterschieden.
Falsch. Es wird in "source character set" und "execution character set" unterteilt, diese beiden jeweils in "basic" und "extended".
> die zehn Dezimalziffern: 1 2 3 4 5 6 7 8 9 0
Nicht falsch, aber die 0 gehört vor 1. Erwähnenswert wäre auch, dass die Zeichen-Werte von 0 bis 9 direkt in einer Reihe liegen, die von anderen Zeichen (außer \0) aber nicht näher spezifiziert sind. (Siehe auch EBCDIC.)
> Den Begriff Bezeichner verwendet man für Namen von Objekten im Programm. Dazu gehören Variablen, Funktionen usw.
Funktionen sind keine Objekte.
> Schlüsselwörter [..] »int«
Nein, int ist kein Schlüsselwort, sondern ein Typ.
> zwei Hochkommata
" ist gemeint. Man kann die als double quotes, Anführungszeichen oder gerne auch als doppelte Hochkommata bezeichnen.
aber ''foo'' wird hier nicht funktionieren.
> Standardfehlerausgabe (stderr), die laut ANSI C niemals vollgepuffert sein darf.
Das ist mir neu. Es ist beim Programmstart unbuffered, das lässt sich aber mit setbuf o.ä. ändern.
> fflush(stdin);
Es wird darauf hingewiesen, dass das nicht überall geht. Der Standard sagt auch explizit, dass dies undefined behaviour verursacht. Warum wird diese "Möglichkeit" dann überhaupt erwähnt?
> do {scanf("%c",&a);} while ( getchar() != '\n' );
xy[return]
> Die Funktion scanf() ist nicht gegen einen Pufferüberlauf (Buffer-Overflow) geschützt
char x[20]; scanf("%19s", x); /* muss man halt die Puffergröße spezifizieren. */
> Auch mit printf() kann es einen Pufferüberlauf geben, sollte der Text länger sein als erlaubt.
Nö. C99 sagt nur: The number of characters that can be produced by any single conversion shall be at least 4095. Mit Buffer Overflows hat das erstmal gar nichts zu tun.
> Größe von short 2 Byte = 16 Bit (und diverse andere Beispiele für Größen und Wertebereiche).
C spezifiziert die Größen nicht, nur Minimalwerte des Bereichs. Auch sollte das Buch auf unterschiedliche Darstellungen von negativen Zahlen eingehen.
> Die ASCII-Code-Tabelle ist eine Tabelle, an die sich alle Programmierer der Welt halten müssen. Sie enthält alle Zeichen, die der Computer darstellen kann.
*löl*
> weil in C nicht festgelegt ist, ob dieser Datentyp [unsigned char] mit oder ohne Vorzeichen interpretiert wird.
Da steht das doch schon: unsigned char.
> Unicode 0 ... 65535
Für UCS-2 mag das stimmen, für Unicode nicht.
Ach, ich hab keine Lust mehr. Hier noch ein Highlight von einer zufällig gewählten Seite:
> Einige Vorteile von CGI-Anwendungen, die in C erstellt wurden [...] Da der Quelltext bei Executables nicht offen ist, lassen sich Sicherheitsfunktionen hervorragend verstecken. Gerade diesen Sicherheitsaspekt gilt es besonders hervorzuheben.
Ohne Kommentar.
> Nein, int ist kein Schlüsselwort, sondern ein Typ.
Es ist tatsächlich ein Schlüsselwort.
Aber zum Einstieg ist das eh nur bedingt relevant.
Ich stoeber gern durch die www.c-faq.com und natuerlich K&R C - Programming Language um mein C Wissen zu erweitern.
Gehoert zwar weniger hierher und ist reine Geschmackssache, doch zum Programmierstil kann ich nur die linux-2.6/Documentation/CodingStyle empfehlen.
> beispielsweise) im Kernel gelandet sind,
Äh, gibt es da Beispiele?
http://www.schreibfabrik.de/txt/html.htm
Nach seiner Argumentation sind dann schon configs mit simpler Schlüssel-Wert Zuweisung 'Programme'.
Mindestens 100% der Sprache C sind Haarspalterei. Die Beispiele von Programmierung mittels C gegen Implementierungen sind ja recht nett für Übungen und erste Gehversuche. Als eine Referenz zu C ist das Buch definitiv kontraproduktiv.
xy[return]
Das verstehe ich nicht ganz. Kann mich jemand aufklären?
Das erste Zeichen wird in der Variablen a gespeichert, das zweite wird darauf überprüft, ob "Return" gedrückt wurde.
Bei xy[return] läuft das jetzt so ab:
x landet in a, y wird mit '\n' verglichen (ist !=), [return] landet in a, das Programm wartet aufs nächste Zeichen.
Wulf wollte damit wohl ein Eingabebeispiel geben, bei dem der Code eben nicht das tut, was du und wahrscheinlich viele andere geglaubt haben, dass er das tut.
Ich kann dem Code überhaupt keinen Sinn entlocken. Einen String bis zum Zeilenumbruch einlesen funktioniert jedenfalls ganz anders. Und wenn man nur auf die Eingabetaste wartet, sollte man das scanf() weglassen und nur getchar() verwenden oder den in a eingelesenen Wert mit '\n' vergleichen statt mittels getchar() das darauf folgende Zeichen einzulesen.
Zudem wird zweimal umkopiert, was unnötig ist, da es ausreicht, die Zieladresse des Zeigers nach der Freigabe das alten Speicherbereiches auf den neu angelegten Speicherbereich umzubiegen.
Ich habe gerade reingeschaut, und war geschockt. Besser kein Buch als so etwas. Fehler über Fehler.
Sehe ich nicht so. Das Buch ist sehr gut. Die hier angesprochenen Fehler sind keine. Wenn es Ungenauigkeiten gibt, kann man sie dem Autor / Autorenteam mailen.
Ich habe das Buch und schaue gerne mal rein, wenn ich C-Probleme habe.
> Sehe ich nicht so. Das Buch ist sehr gut. Die hier angesprochenen Fehler sind keine. Wenn es
> Ungenauigkeiten gibt, kann man sie dem Autor / Autorenteam mailen.
Sehe ich nicht so. Das Buch ist ja schon mehrere Jahre auf dem Markt und wesentliche Fehler sind noch immer nicht korrigiert obwohl sie bekannt sind und auch schon oft genannt wurden.