C-Lehrbuch aus dem Rheinwerk-Verlag schlecht? Alternative?

Hab einen:

5.2 Der Datentyp »int« (Integer)
Der Datentyp int muss, gemäß ANSI C, mindestens eine Größe von zwei Byte 
aufweisen. Mit diesen zwei Bytes lässt sich ein Zahlenraum von -32768 
bis +32767 beschreiben

Das Minimum ist -32767, nicht -32768, denn C unterstützt auch Systeme 
die das Einerkomplement nutzen. Die allermeisten nutzen aber das 
Zweierkomplement und können bis -32768.

Noch einen:

Das Codebeispiel in 6.5.7 Rezept für Fortgeschrittene:

#define BYTE unsigned char

Ganz schlechter Stil, dafür nimmt man typedef

Noch einen:

15.9 Unions

"Das Verhalten ist in diesem Fall undefiniert."
Es ist implementation-defined, nicht undefiniert. Das trifft nur auf C++ 
zu.

15.12 Attribute von Strukturen verändern (nicht ANSI C)

"Dies hängt vom Betriebssystem ab."
Eher vom Prozessor bzw. Architektur und wie der Compiler diese 
unterstützt. Das OS könnte das höchstens beeinflussen indem es auf ARM 
unaligned Zugriffe abschaltet.

Jim M. schrieb:
> Das verwirrt Anfänger nur.

Weglassen wäre okay, aber eine *Fehl*information verwirrt noch mehr! Es 
wurde nach Fehlern gefragt, nicht nach didaktischen Details, und das ist 
einer. Lässt sich eindeutig im C Standard zeigen.

Jim M. schrieb:
> Nee, dafür nimmt man das fertige uint8_t aus dem stdint.h Header.

Es gibt Situationen wo man Typ Aliase definiert, und dann nimmt man 
typedef.

Das ganze Kapitel "16.17.3 Big Endian und Little Endian" ist falsch, 
denn es gibt noch mehr Formate und durch Pointer Casts die Host 
Reihenfolge zu bestimmen ist unportabel und enorm hässlich. Korrekte 
Programme nutzen Bitshifts und müssen dafür die Host Order gar nicht 
explizit kennen.

Es ist wie bei jedem Thema: DAS Buch gibt es (leider) nicht.
Einfach eins der bei amazon bestbewertesten kaufen und durcharbeiten, 
danach nochmal ein anderes durchkauen.

Dr. Sommer schrieb:
> und durch Pointer Casts die Host Reihenfolge zu bestimmen ist unportabel

nö. Cast auf char* ist explizit nach Aliasingregeln erlaubt.

Ich habe vor 30 Jahren mit C auf AT&T System V Unix begonnen -
da war der "Kernighan & Ritchie" die C-Bibel.

Dieses Standardwerk ist es eigentlich noch immer, es gibt eine 
verbesserte 2. Auflage mit sehr guter Übersetzung von den Professoren 
Schreiner & Janich.

Programmieren in C: Mit dem C-Reference Manual in deutscher Sprache

( Es ist die 2. Auflage aus dem Jahr 1990 vom K&R mit dem ANSI Standard 
)
ISBN-10: 3446154973
ISBN-13: 978-3446154971

MaWin schrieb:
> nö. Cast auf char* ist explizit nach Aliasingregeln erlaubt.

Erlaubt ja, aber das Ergebnis ist Implementation defined, d.h. es ist 
nutzlos wenn man portabel arbeiten möchte. Gerade wenn man C lernt 
sollte man nicht mit plattformspezifischen Hacks anfangen sondern 
erstmal nur Code schreiben, dessen Verhalten wohldefinierte ist. Zumal 
es hier ja auch gar nicht nötig ist.

Rufus Τ. F. schrieb:
> extrem fehleranfällige C-Variante.

Es ist immer gut sich vor Augen zu halten, dass es möglich ist noch 
fehleranfälliger als mit ANSI C zu arbeiten möglich ist.

@Dr. Sommer
Die von dir genannten Beispiele sind aller eher Randthemen für einen C 
Beginner.
Statt also krampfhaft irgendwelche Fehler zu suchen, die es in so einem 
dicken Wälzer praktisch immer gibt wäre es deutlich hilfreicher dem TO 
ein gutes Einsteigerbuch zu nennen.

Ich weiss leider keins, da ich Ansi-C in den 80gern mit dem oben 
erwähnten Kernighan-Ritchie gelernt habe (ich kenne beide Auflagen) und 
woweit ich mich erinnere auch da über zum Teil krasse Fehler gestolpert 
bin.

Der Andere schrieb:
> Die von dir genannten Beispiele sind aller eher Randthemen für einen C
> Beginner.

Schon. Aber bei C steckt der Teufel im Detail. Und simple Dinge sind ja 
auch nicht so oft falsch.

Der Andere schrieb:
> wäre es deutlich hilfreicher dem TO ein gutes Einsteigerbuch zu nennen.

Er hat explizit nach Fehlern gefragt!  Ich kenne auch keins. Hab direkt 
C++ gelernt... allerdings auch nicht wirklich geradlinig.

Der Andere schrieb:
> Ich weiss leider keins, da ich Ansi-C in den 80gern mit dem oben
> erwähnten Kernighan-Ritchie gelernt habe (ich kenne beide Auflagen) und
> woweit ich mich erinnere auch da über zum Teil krasse Fehler gestolpert
> bin.

Beispiel?

Ich würde ein aktuelles C-Buch von Addison-Wesley empfehlen. Ansonsten: 
die Dokumentation zum Compiler durchwälzen, das ist nie umsonst.

Edson schrieb:
> Ansonsten: die Dokumentation zum Compiler durchwälzen, das ist nie
> umsonst.

Ungefähr so hilfreich wie ein Telefonbuch durchzulesen...

Edson schrieb:
> Beispiel?

Das ist >25 Jahre her und ab und an muss ich hier auch arbeiten, die 
Bücher stehen zu Hause.

Edson schrieb:
> Ansonsten:
> die Dokumentation zum Compiler durchwälzen

Schwerlich didaktisch gut für einen Anfänger

Ist das C Wikibook denn nicht gut genug? (Ich habe es nicht gelesen.)

https://en.wikibooks.org/wiki/C_Programming

Stefan schrieb:
> Ist das C Wikibook denn nicht gut genug? (Ich habe es nicht gelesen.)

Ein Fehler:

int ix;
short anArray[]= { 3, 6, 9, 12, 15 };

for (ix=0; ix< (sizeof(anArray)/sizeof(short)); ++ix) {

Mit int durch ein Array iterieren. Der Vergleich sollte sogar eine 
Compiler Warnung produzieren.

Der Text scheint allgemein nur sehr mager und didaktisch schlecht 
aufbereitet.

Dr. Sommer schrieb:
> Der Text scheint allgemein nur sehr mager und didaktisch schlecht
> aufbereitet.

Schade. Da C so alt und so verbreitet ist bzw. so viele Leute sich damit 
wirklich gut auskennen, hätte ich ein recht gutes Wikibook erwartet.

Ubrigens: Kürzlich hatte ich mich nach einem aktuellen C++ Buch 
umgesehen -- was mich zunächst verwirrt hatte, war das es "C++ Primer" 
von Lippman und "C++ Primer plus" von Prata gibt. Und wirklich seltsam 
ist, das das Prata-Buch bei Amazon.com sehr gut bewertet ist, in den 
Foren wie etwa

http://www.cplusplus.com/forum/beginner/106097/

aber durchfällt. So langsam habe ich den Verdacht dass die Amazom-Kunden 
die Bücher teils verwechselt haben.

Ich hätte mir jedenfalls fast Prata gekauft. Das Lippman-Buch scheint 
ganz OK zu sein, ist aber nur C++ 11.

Auf ein aktuelles, gutes C++17 Buch muss ich wohl noch etwas warten. 
Aber ich will eh nicht C++ programmieren, bloß man muss es ja oft 
beherrschen für den Job und so.

Stefan schrieb:
> Schade. Da C so alt und so verbreitet ist bzw. so viele Leute sich damit
> wirklich gut auskennen, hätte ich ein recht gutes Wikibook erwartet.
Tja, gute Arbeit kostet Geld...

Stefan schrieb:
> Ubrigens: Kürzlich hatte ich mich nach einem aktuellen C++ Buch
> umgesehen
Hier eine hilfreiche Liste: https://stackoverflow.com/a/388282

Stefan schrieb:
> aber durchfällt. So langsam habe ich den Verdacht dass die Amazom-Kunden
> die Bücher teils verwechselt haben.
Amazon Bewertungen sind oft völliger Unfug, in beide Richtungen. 
Insbesondere Anfänger können die Probleme eines Buchs nicht sehen und 
bewerten es dann gut, weil es ihnen Erfolgserlebnisse gegeben hat - auch 
wenn die erlernten Arbeitsweisen fragwürdig sind.

Stefan schrieb:
> Aber ich will eh nicht C++ programmieren, bloß man muss es ja oft
> beherrschen für den Job und so.
C++ zu lernen ohne sehr viel Übung hineinzustecken klingt gewagt.

Dr. Sommer schrieb:
> C++ zu lernen ohne sehr viel Übung hineinzustecken klingt gewagt.

Ja mit den Amazon-Bewertungen hast Du wohl recht.

Und zu C++ -- es nicht zu beherschen ist halt eine gewisse 
Bildungslücke, und modernes C++ bietet ja auch einige interessante 
Konzepte wie RAII.

Ich hatte vor ca. 8 Jahren mal mit dem Buch von Bruce Eckel mit C++ 
angefangen, aber er kommt halt aus der Java-Ecke und schwärmt etwas zu 
viel von OOP. Und jetzt ist das Buch eh veraltet.

Ich denke Rust ist eh das modernere C++ -- werde ich aber wohl erst im 
nächsten Winter richtig lernen.

Stefan schrieb:
> modernes C++ bietet ja auch einige interessante
> Konzepte wie RAII.
Na, RAII ist aber schon laange drin.

Dirk B. schrieb:
> Das wird doch so im K&R gelehrt.

Tatsächlich? Das ist bedenklich.

Dirk B. schrieb:
> Und für diesen Zweck reicht es aus (da reicht auch ein char, ist ja das
> Mikrocontrollerforum)
Das Wikibook bezieht sich aber nicht auf Mikrocontroller. Und char? Du 
hast nie Arrays mit mehr als 127 Elementen?

"Reicht aus" ist der Feind von "Gut"... Früher oder später gehts halt 
doch schief, und dann guckt man blöd. Ich finde, gerade Bücher für 
Einsteiger sollten sich pingeligst an den Standard halten, damit man es 
direkt richtig lernt, insbesondere bei solchen Fällen wo die korrekte 
Lösung so einfach ist. Erst recht, wenn sogar der Compiler meckert:

1

test.c: In function ‘main’:

2

test.c:5:15: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]

3

  for (ix=0; ix< (sizeof(anArray)/sizeof(short)); ++ix)

In der konkreten Anwendung kann man sich dann immer noch überlegen ob 
man's anders macht - immer noch besser, als das original falsch gelernte 
zu un-lernen.

Einfach gesagt: Es ist fast scheiß egal, was du nutzt. Wichtig ist 
erstmal, dass du die Grundlagen gut drauf hast und dich dann 
weiterbildest und mit häufigen Fehlern beschäftigst.

So gut wie jedes Buch hat mehr oder weniger grobe Fehler drin, aber so 
erkennst du sie dann selbst. Siehst ja hier, wie sich die Leute nicht 
mal über Fehler einig sind.

Dirk B. schrieb:
> Dr. Sommer schrieb:
>> Mit int durch ein Array iterieren.

Hi Doc Sommer, Du meinst man sollte HIER

http://openbook.rheinwerk-verlag.de/c_von_a_bis_z/011_c_arrays_002.htm

1

/* array2.c */

2

#include <stdio.h>

3

#include <stdlib.h>

4

5

int main(void) {

6

   int test[10];

7

   int i;

8

9

   for(i = 0; i <= 10; i++)  /*  !!Bereichsüberschreitung!! */

10

      test[i] = i;

11

   for(i = 0; i <= 10; i++)

12

      printf("%d, ", test[i]);

13

   printf("\n");

14

   return EXIT_SUCCESS;

15

}

kein int für den Schleifenzähler verwenden?

Übung macht den Meister :-] schrieb:

> Hi Doc Sommer, Du meinst man sollte HIER

Das Dr. steht für Dietrich.

Dr. Sommer schrieb:
> Tatsächlich? Das ist bedenklich.

Im Kernighan Ritchie C gabs noch kein size_t

ISO/IEC 9899:201x

Ist auch voellig umsonst.

Der Andere schrieb:
> Im Kernighan Ritchie C gabs noch kein size_t

In meinem schon.

Übung macht den Meister :-] schrieb:
> kein int für den Schleifenzähler verwenden?

Wenn der Code exakt so aussieht, ist int ok. Aber in ähnlichem Code kann 
so etwas schief gehen - da sollte man dann size_t verwenden. Ich 
persönlich finde es am Einfachsten, wenn man sich die Regel angewöhnt 
"Für Container und Arrays immer size_t nehmen" anstatt jedes einzelne 
Mal nachzudenken "Reicht hier ein int?". Das provoziert nur Fehler, 
insbesondere wenn man den Code später abändert. Es gibt ja auch 
überhaupt keinen Grund, hier int zu nehmen - warum also darauf bestehen, 
nur weil es in manchen Fällen geht?

Der Andere schrieb:
> Im Kernighan Ritchie C gabs noch kein size_t
Ok, dann sind die beiden entschuldigt. Zum Glück gibts das aber 
mittlerweile.

Dr. Sommer schrieb:
> Der Andere schrieb:
>> Im Kernighan Ritchie C gabs noch kein size_t
> Ok, dann sind die beiden entschuldigt. Zum Glück gibts das aber
> mittlerweile.

Ist aber falsch.

Mein Gott, ist das Forum grottenschlecht...
Voll mit knausrigen, halbgebildeten i-Tüpfelreitern
Hat irgendjemand hier mal mehr als ein Hello World geschrieben?

also ich nehme dann doch lieber

ssize_t

falls es mal negativ wird ;-)

udok schrieb:
> Hat irgendjemand hier mal mehr als ein Hello World geschrieben?

Naja, sie haben ein paar Programme mit int-Zähler geschrieben :D

Rolf M. schrieb:
> Abgesehen davon ist auch die Größe eines Bytes in C nicht fix definiert,
Genau. Es war wohl "Oktett" gemeint.

Philipp K. schrieb:
> Ich finde das solche Openbooks schon okay sind, wer da Fehler
> sieht
> braucht das Buch auch nicht mehr.

Es geht nicht darum dass man Fehler sieht, es geht darum dass man es 
falsch lernt, weil man sie als Anfänger eben nicht sieht. Daher sollte 
man halt mal die paar Euro in ein gutes Buch investieren. Höhrere 
Mathematik lernt man auch nicht mit eine paar Online-Tutorials.

Philipp K. schrieb:
> Die Frage ist ob es die Zielgruppen an die das Buch gerichtet ist im
> Gegensatz zu nen paar Oberschlaumeiern überhaupt interessiert.

Wenn der Code nicht funktioniert weil es falsch gelernt wurde, wird es 
denjenigen interessieren. Hier - bei einem anderen Open Book - wird ein 
Beispiel zitiert welches komplett falsch ist und so nie funktionieren 
wird:
https://www.c-plusplus.net/forum/272350-10 . Ist das auch noch 
oberschlau?

Dr. Sommer schrieb:
> Es geht nicht darum dass man Fehler sieht, es geht darum dass man es
> falsch lernt, weil man sie als Anfänger eben nicht sieht.

Man lernt es doch gar nicht "falsch". Man bezieht sich auf eine 
bestimmte Implementierung. Anders geht es doch auch gar nicht. Was nützt 
dir der Hinweis "int" kann 8, 16, 32, 64 oder sonst wie bittig sein? 
Damit kannst du nicht programmieren lernen. Du brauchst EINEN Bezug. Das 
ist im K&R (den ihr Schlauberger fälschlicherweise pauschal als "size_t" 
gab's dort noch gar nicht betitelt habt) 1) auch nicht anders geregelt. 
Er bezieht sich nämlich auf die Implementierung der 16-bit Ära, die 
damals aktuell war. Folglich hat "int" einen Wertebereich von -32768 bis 
+32767. Dies wird beim ersten Nennen von int erwähnt (bei mir S. 9) 
natürlich mit dem Hinweis, dass int mit 32-bit genau so üblich sei 
(damals im Workstation Bereich). Dennoch ist weiter hinten im Auszug 
B.11 einer Tabelle aus limits.h

INT_MIN -32767
INT_MAX +32767

angegeben. Damals halt wegen Einerkomplement.

Damit nimmt das Buch klar Bezug zur Größe von int, so wie es die meisten 
damals auch zu erwarten hatten, die das Buch kaufen. DOS-Ära! Und wer 
bitte hatte schon eine VAX zu Hause stehen?

1) ohne die Ausgabe zu nennen !! Zweite Ausgabe ANSI C kannte size_t 
bereits!

Rolf M. schrieb:
> Man muss nicht jedes Detail in so ein Buch
> reinschreiben, aber das was drin steht, muss auch korrekt sein.

So ein Anspruch SCHEITERT an der Wirklichkeit!

1. Ein fehlerfreies Buch gibt es nicht, gab es nie, wird es nie geben.
2. Ein Buch, dass Eierlegende Wollmilchsau spielt, d.h. sich nicht auf 
eine sinnvolle Auswahl beschränkt (JA, dazu gehört auch im Jahre 2008 
aufwärts das verdammte Einerkomplement in den Orkus zu werfen. Braucht 
keiner mehr!), wird seinem Anspruch nicht gerecht. Der Anspruch ist 
Anfängern beim Lernen zu helfen und nicht Enzyklopädie zu spielen. Das 
überlassen wir den Juristen mit ihren Pamphleten. Die können sich dann 
um Vokabeln kloppen.

Ihr habt vergessen, wie ihr einst in der Schule das Rechnen begonnen 
habt.

3 : 2 = 1 Rest 1

War das exakte Mathematik?

Übung macht den Meister :-] schrieb:
> Ist aber falsch.

udok schrieb:
> Mein Gott, ist das Forum grottenschlecht...
> Voll mit knausrigen, halbgebildeten i-Tüpfelreitern
> Hat irgendjemand hier mal mehr als ein Hello World geschrieben?

Wieder mal ein paar Dummschwätzer die nur Unruhe stiften aber absolut 
nix substanzielles beitragen können.

Wahrscheinlich nie über C64-Basic hinausgekommen ;p

Oh mein Gott wenn man diesen ganzen Genöhle hier liest!

Es gibt nicht DAS perfekte Buch um C zu lernen, wird es auch nie geben, 
speziell bei C oder C++, die Sprachen sind immer "im Flow" und 
wachsweich spezifiziert. Nimm irgendein Buch, deine Wahl fiel auf das 
Buch oben, arbeite das Buch durch und dann ein anderes und lerne aus den 
Unterschieden und vor allem: schreibe selber Code bis zu vergasen und 
lese anderen Code (Open Source sei dank), dann lernste am meisten. Wenn 
du mal pause machst dann liest in entspr. Foren mit da stolpert man auch 
auf das eine oder andere was man noch nicht kennt.

Der Andere schrieb:
> Wieder mal ein paar Dummschwätzer die nur Unruhe stiften aber absolut
> nix substanzielles beitragen können.

Ich weiß nicht wen du hier adressierst. Meine Aussage zu size_t stimmt 
jedenfalls.

Rolf M. schrieb:
> bei welcher konkreten Implementierung ist die
> Größe von int mindestens (und nicht etwa exakt) zwei Bytes groß? Das
> stimmt so weder für irgendeine gängige Implementation, noch für C
> allgemein.

Und welche Formulierungen verwenden andere Druckwerke? Beispiele 
gefällig?

Zitieren wir mal Auszugsweise
1.

"Der Datentyp int (integer) muss, gemäß ANSI C, mindestens eine Größe 
von zwei Byte aufweisen. Damit lässt sich ein Zahlenbereich von -32768 
bis +32768 beschreiben."

Buch Programmieren in C: Programmieren lernen von Anfang an"

Quelle:
https://books.google.de/books?id=S4ShZ_A1QJgC&pg=PT48&lpg=PT48&dq=Der+Datentyp+int+muss,+gem%C3%A4%C3%9F+ANSI+C,+mindestens&source=bl&ots=oqkL35a-cu&sig=qpcvNYRN7zhF1zFfs-80kclqBM0&hl=de&sa=X&ved=0ahUKEwjXzuvqoZfZAhXF_KQKHU52AlIQ6AEIIzAE

2. "int

Mit dem Schlüsselwort int erstellen wir Variablen gewöhnlicher Größe. 
Diese Variante wird auch am Meisten verwendet. Laut Standard hat dieser 
Datentyp mindestens 16 Bit, bei einem 32-Bit Prozessor jedoch 32 Bit."

Quelle:
http://www.c-howto.de/tutorial/variablen/datentypen/ganze-zahlen/

3.
"Der Typ signed short int liefert Werte von mindestens -32.768 bis 
32.767."
"Der Typ short int ist mindestens 16 Bit breit,.."

Quelle:
https://de.wikibooks.org/wiki/C-Programmierung:_Variablen_und_Konstanten

4.
"Die Größe eines Integers ist vom jeweiligen Compiler abhängig, der 
C-Standard garantiert aber eine minimale Größe von 16 Bit."

"int ganzzahl = 3;       /* mindestens 16 Bit, also 65536 mögliche Werte 
*/"

Quelle:
https://de.wikipedia.org/wiki/Datentypen_in_C

5.
"Der Datentyp int muss, gemäß ANSI C, mindestens eine Größe von zwei 
Byte aufweisen. Mit diesen zwei Bytes lässt sich ein Zahlenraum von 
-32768 bis +32767 beschreiben."

Quelle:
http://pronix.linuxdelta.de/C/standard_C/c_programmierung_8.shtml

6. S. 22
"Der ANSI Standard fordert, daß ein Long-Integer mindestens 32 Bit groß 
ist und short oder normale Integer mindestens 16 Bit lang sind."

http://www.dguv.de/medien/ifa/de/pra/softwa/sicherheitssoftware/download/programmierleitfaden_c.pdf

Ihr seht, der "Schuldige" findet sich in bester Gemeinschaft wieder.

Wer möchte also den ersten Stein werfen?

Ich habe das Buch nicht gelesen und will es auch nicht bewerten, aber 
beim Überfliegen des Inhaltsverzeichnis' fand ich "12.6 Zeiger als 
Funktionsparameter (call–by–reference)" etwas eigenwillig, da C gar kein 
call by reference unterstützt; stattdessen werden Parameter immer per 
call by value übergeben. Leider findet sich so eine missbräuchliche 
Verwendung  von standardisierter Terminologie in vielen C- und auch 
Java-Büchern.

Übung macht den Meister :-] schrieb:
> Und welche Formulierungen verwenden andere Druckwerke? Beispiele
> gefällig?
Na, wer hat hier von wem abgeschrieben und Dinge für selbstverständlich 
erklärt die gar nicht stimmen...

Ich versteh auch das Problem nicht. Wenn man einen Integer-Typ mit 
Bereich -32767 bis 32767 haben will, nimmt man int_least16_t. Wenn man 
-100000 bis 100000 haben will, nimmt man int_least32_t. Warum sich erst 
kompliziert Gedanken machen ob ein int jetzt groß genug ist oder 
vielleicht auf der Plattform ein short auch reicht? Einfach das 
ausnutzen was der Standard garantiert und nichts kann einem was 
kaputtmachen.

Der Sommer ist weit weg der Realität. Ist ja noch Winter. :-)

Dr. Sommer schrieb:
> Ich versteh auch das Problem nicht.

Das verwundert stark, bist doch du derjenige, der das Problem entdeckt 
hat.

Übung macht den Meister :-] schrieb:
> Das verwundert stark, bist doch du derjenige, der das Problem entdeckt
> hat.
Ich bin nicht derjenige der sagt "aber auf Platform XY geht es ja doch" 
oder "ich muss unpassende Integer-Typen nutzen und das irgendwie 
verargumentieren"... Wenn man für alles und jedes "int" nehmen will, 
nimmt man Java. Eine der Stärken von C und C++ ist es, dass man viele 
verschiedene Typen zur Auswahl hat und man sich den Geeigneten nehmen 
kann.

Dirk B. schrieb:
> Aber in welchem Lehrbuch wird das denn so vermittelt? Gerade mit dem
> "least".

Keine Ahnung. Hier ist zu sehen dass der Austausch mit Experten sehr 
wichtig ist. Ich hab z.B. viele Anregungen im ##C++ Channel im FreeNode 
IRC bekommen... natürlich sollte man die Aussagen dann im Standard 
nachprüfen, konkrete Punkte kann man damit durchaus beantworten, auch 
wenn er zum reinen Durcharbeiten ungeeignet ist.

Die Wolfbücher sind Teil einer spammenden Unkultur. Das gibt es in 
vielen Büchern von Journalisten, und die haben nur den Anfang gemacht. 
Gewissermaßen genau das andere Ende von Buch mit nur Befehlsliste a la: 
friss und.. mach was draus.

Ubuntu zeigt ganz deutlich, dass es etwas besser schmeckt mit ein wenig 
Geld (oder bei ähnliche Reizen,  wie Lehrer in Schule übertrumpfen 
o.ä.).

Bei C ist das so, dass die Abstraktionen zuerstmal sacken müssen. Dieses 
optimierte "Denken" braucht man dann auch z.B. wenn man gute Programme 
mit endlichen Automaten (grep oder zip z.B.), Audiofilter, 
Betriebssysteme.. usw. usw. schreiben möchte.
Das braucht alles Motivation und Zeit .. (s.o.).

Peter M. schrieb:
> Ich würde gerne genauer wissen, wieso das Buch grottenschlecht

Also ich als Anfänger fand das Buch sehr gut. Das auf dein Posting 
folgende gemäkel versteh ich nicht.

Wieso z.B. ist ein Lehrbuch schlecht wenn es nicht alle Typen in einem 
Kapitel aufführt und

Dr. Sommer schrieb:
> Das Minimum ist -32767, nicht -32768,

Ja und? Das ist ein Lehrbuch und kein Referenzwerk.

Dr. Sommer schrieb:
> Ganz schlechter Stil, dafür nimmt man typedef

Ein Beispiel mit etwas zu erklären was erst später behandelt wird. Das 
ist ganz schlechter Stil. Selbst wenn es schon behandelt wurde ist es 
imho besser die einfachst mögliche Form zu nehmen.

Dr. Sommer schrieb:
> "Das Verhalten ist in diesem Fall undefiniert."
> Es ist implementation-defined,

Und wo ist der Unterschied in der Praxis? Warum muss jemand der C Syntax 
lernt das wissen? Ist es nicht information overload?

X4U schrieb:
> Ja und? Das ist ein Lehrbuch und kein Referenzwerk.
Ok, wenn du der Ansicht bist dass Lehrbücher fehlerhaft sein dürfen.

X4U schrieb:
> Selbst wenn es schon behandelt wurde ist es
> imho besser die einfachst mögliche Form zu nehmen.
Was an typedef ist komplizierter? Es ist sogar einfacher, weil es später 
weniger Probleme verursacht.

X4U schrieb:
> Ein Beispiel mit etwas zu erklären was erst später behandelt wird.
Dann kann man immer noch darauf verweisen. In einem Beispiel etwas 
falsch zu machen dass sehr oft falsch gemacht wird ist offensichtlich 
ziemlich mies.

X4U schrieb:
> Und wo ist der Unterschied in der Praxis?
Auf Implementation-Defined Behaviour kann man sich in gewissen Grenzen 
verlassen, Undefined Behaviour nicht. IMO sollte man keines von beiden 
annehmen.

X4U schrieb:
> Warum muss jemand der C Syntax
> lernt das wissen? Ist es nicht information overload?
Wer unbedingt C lernen will, muss sich auf eine Flut an komplizierten 
Informationen einstellen. Wenn man einfach nur programmieren lernen 
will, sollte man lieber Python o.ä. nehmen.

Es ist erwiesenermaßen didaktisch äußerst ungeschickt, zu zeigen wie es 
nicht geht, selbst wenn dran steht dass es so falsch ist - erst recht 
wenn es kommentarlos falsch ist und man sich das "später" richtig 
angucken soll. Denn die Leute merken sich genau das und wiederholen es 
so. Du sagst ja auch deinem Kind nicht "Du sollst nicht fluchen, 
Idiot!".

Karl schrieb im Beitrag #5310102:
> Meistens ist nichts brauchbares dabei, wie in
> deinen Beispielen.
Nur kein Neid!

Hier noch ein kleines Beispiel warum #define für Typen schlecht ist:

Angenommen wir erfinden gerade das Windows-API neu, und definieren uns 
einen Typ "HANDLE". Dieser wird von diversen API-Funktionen genutzt und 
zurückgegeben. Der Nutzer kann mit diesem Typ nichts anfangen, sondern 
ihn nur übergeben. Das ist ein ganz typisches Vorgehen in C. Wir fangen 
an und definieren ihn einfach als Alias für "uint8_t":

1

#define HANDLE uint8_t

Der Nutzer kann dann so etwas schreiben:

1

HANDLE a, b;

2

a = CreateFile (...);

3

b = CreateFile (...);

4

...

5

CloseHandle (a);

6

CloseHandle (b);

Jetzt fällt uns auf dass ein Integer doch nicht so schlau war, und wir 
ändern das auf "void*":

1

#define HANDLE void*

Jetzt ist diese Code plötzlich fehlerhaft, obwohl der Nutzer keinerlei 
Annahmen über die Interna von HANDLE gemacht hat:

1

HANDLE a, b;

Weil "b" als "void" statt "void*" definiert wird! Dies gibt einen 
Compiler-Fehler. Der Code müsste also angepasst werden:

1

HANDLE a, *b;

Das ist jetzt völlig verwirrend für den Leser. Wenn man das HANDLE dann 
nochmals umdefiniert gibts wieder ein Problem.

Hätten wir einfach ein Typdef genommen wäre alles in Butter:

1

typedef void *HANDLE;

Dann ist

1

HANDLE a, b;

immer noch korrekt. Es gibt noch weitere Beispiele, z.B. bei Arrays. Der 
Grund für die Probleme liegt in der verdrehten C-Syntax sowie darin, 
dass Makros nur dumme Textersetzung machen.

Jetzt könnte man natürlich sagen, dass für einfache Fälle - wie Integer 
- das #define ausreicht. Das ist zwar korrekt, aber warum jedes Mal 
überlegen "Brauche ich ein typedef oder bin ich mir absolut sicher 
niemals den Typ auf einen Pointer zu ändern und kann somit #define 
nutzen" wenn ich mir auch einfach merken kann "immer typedef nutzen". 
Bei #define spart man nichtmal ein einziges Zeichen Code.

Wenn man jetzt im Buch sowas wie "#define BYTE unsigned char" liest, 
merkt man sich das, insbesondere wenn man das folgende Kapitel über 
"typedef" nicht liest. Da dieser Fehler weit verbreitet ist sollten die 
Autoren Wert darauf legen, es gleich richtig zu zeigen...

Dr. Sommer schrieb:
> X4U schrieb:
>> Ja und? Das ist ein Lehrbuch und kein Referenzwerk.
> Ok, wenn du der Ansicht bist dass Lehrbücher fehlerhaft sein dürfen.

Meinst du wirklich DEINE Ansicht darüber würde etwas an der Tatsache 
ändern, dass Lehrbücher nun mal Fehler enthalten?

Fehler werden üblicherweise in der nachfolgenden Auflage (falls es eine 
gibt) korrigiert, so sie bekannt sind und als solche auch erachtet 
werden. Meistens werden dann auch gleich Kapitel ergänzt und dabei 
wieder neue Fehler eingebracht. Fehlerfrei gibt es also nicht!

Aber mal was Grundsätzliches,

immerhin ist die Online-Ausgabe dieses Druckwerks umsonst, d.h. sie 
kostet 0 Euro. Du formulierst nun einen Anspruch daran ohne dafür 
bezahlt zu haben und das Buch wird deiner Meinung nach deinem Anspruch 
nicht gerecht. Interessant dabei ist, wann immer man einen ähnlichen 
Anspruch z.B. an Open Source SW stellt (z.B. gute Doku, intuitive 
Bedienbarkeit, Fehlerfreiheit o.ä.), reagieren gerade Leute wie du 
(damit meine ich Leute die selber Software schreiben) angesäuert und 
kontern, man hätte doch schließlich nix bezahlt dafür, also hätte man 
die Füße stillzuhalten. Hier jedoch ereifern sich die "Genossen 
Programmierer" wie im erwähnten Thread 1) anscheinend über 31 WebSeiten 
!! lang (hab's nicht gelesen, wozu auch) mit dem Niedervoten dieses 
Lehrbuchs. Schon interessant, wie hier von manchen mal wieder mit 
zweierlei Maß gemessen wird.

1) https://www.c-plusplus.net/forum/272350

Darf man demnächst auch "Warnthreads" vor bestimmten halbgaren Open 
Source Programmen erstellen? (ohne dass einen der Shitstorm ereilt)

Nein, ich bin kein "OS Hasser". Wollte nur mal einen Vergleich ziehen.

Übung macht den Meister :-] schrieb:
> Meinst du wirklich DEINE Ansicht darüber würde etwas an der Tatsache
> ändern, dass Lehrbücher nun mal Fehler enthalten?
Darum ging es nicht.

Übung macht den Meister :-] schrieb:
> Fehler werden üblicherweise in der nachfolgenden Auflage (falls es eine
> gibt) korrigiert, so sie bekannt sind und als solche auch erachtet
> werden.
Anscheinend wissen hier Autor und Verlag sehr wohl um die Fehler, tun 
aber nix.

Übung macht den Meister :-] schrieb:
> Du formulierst nun einen Anspruch daran ohne dafür
> bezahlt zu haben und das Buch wird deiner Meinung nach deinem Anspruch
> nicht gerecht.
Falsch. Ich sage, dass man das Buch nicht zum Lernen nehmen sollte, und 
lieber Geld in ein richtiges investieren soll:

Dr. Sommer schrieb:
> Daher sollte
> man halt mal die paar Euro in ein gutes Buch investieren. Höhrere
> Mathematik lernt man auch nicht mit eine paar Online-Tutorials.

Übung macht den Meister :-] schrieb:
> Schon interessant, wie hier von manchen mal wieder mit
> zweierlei Maß gemessen wird.
Bei Open Source Software besteht immerhin nicht das Risiko, eine 
Generation von Programmierern mit gefährlichem Halbwissen 
heranzuzüchten.

Übung macht den Meister :-] schrieb:
> Darf man demnächst auch "Warnthreads" vor bestimmten halbgaren Open
> Source Programmen erstellen?
Gibts doch schon jede Menge.

Gerade bei C-Büchern gibts eine riesige Auswahl, und da soll man sich 
mit einem begnügen wo man nach ein paar Minuten schon Fehler findet? So 
eine Auswahl hat man bei Software oft nicht.

Dr. Sommer schrieb:
> Gerade bei C-Büchern gibts eine riesige Auswahl, und da soll man sich
> mit einem begnügen wo man nach ein paar Minuten schon Fehler findet?

Wer schreibt denn sowas? Ich jedenfalls nicht.

Kennst du den Satz: "Aus Fehlern wird man klug." Der Lerneifer beim 
Programmieren wird selber viel mehr Programmierfehler hervorbringen. Da 
gehen die paar Ungenauigkeiten aus dem Buch im Rauschen unter. Außerdem 
gehst du von der falschen Denke aus, dass EIN Buch mit ein paar Fehlern 
darin zwangsläufig zu lebenslangen nicht reflektierten, unkorrigierten 
eigenem Fehlverhalten führt. Das ist Nonsens.

Lesen allein genügt sowieso nicht, das zeigen die Irrungen und Wirrungen 
des Buchhändlers aus Würselen. Der soll übrigens jede freie Minute 
gelesen haben, dass die Schwarte kracht.

Übung macht den Meister :-] schrieb:
> Da
> gehen die paar Ungenauigkeiten aus dem Buch im Rauschen unter.
Na, und da beschweren sich noch Leute C sei schwer zu lernen.

Übung macht den Meister :-] schrieb:
> Außerdem
> gehst du von der falschen Denke aus, dass EIN Buch mit ein paar Fehlern
> darin zwangsläufig zu lebenslangen nicht reflektierten, unkorrigierten
> eigenem Fehlverhalten führt. Das ist Nonsens.
Guck dir mal den Code von W.S. an. Der hat's bis heut nicht gelernt. 
Oder der Linux Kernel, dessen Code funktioniert nur mit dem GCC, mit 
einer bestimmten alten Sprachversion, und nur mit -fno-strict-aliasing 
aktiviert, d.h. wenn eine bestimmte Art fehlerhaften Codes erlaubt ist. 
Das verhindert eine Klasse von Optimierungen. Mit anderen Worten: Linux 
ist unnötig langsam, weil die Linux-Kernel-Entwickler keine Lust haben, 
korrekten Code zu schreiben.

Dr. Sommer schrieb:
> Mit anderen Worten: Linux
> ist unnötig langsam, weil die Linux-Kernel-Entwickler keine Lust haben,
> korrekten Code zu schreiben.

in welcher Sprache mag dann Windows erst geschrieben sein?

Walter K. schrieb:
> in welcher Sprache mag dann Windows erst geschrieben sein?

Der Kernel natürlich auch in C. Wenn die den Code derart geheim halten 
muss er furchtbar sein :)

Na ja, wenn jemand die Programmiersprache lernen soll, müsste derjenige 
doch erstmal als allererstes lernen, die Warnungslevel vom Compiler 
hochzudrehen. Dann isses doch Hupe, welches Buch derjenige nimmt. Das 
ist aber auch der härteste Weg, den man gehen kann, um ne 
Programmiersprache zu lernen.

Der Compiler halt das erste und das letzte Werkzeug vom Programmierer, 
dass Ding muss man handwerklich beherrschen können. Vielleicht ist da 
portabelst möglicher Code für ein Grundlagenbuch die beste Empfehlung, 
damit man das so breitbandig wie möglich durch die Compiler jagen kann. 
Aber halt mit der Empfehlung "Warnungslevel rauf", damit man die 
Fehler/Warnungen zu beheben lernt.

Ich hatte damals mit "C für Linux in 21 Tagen" angefangen (ja, lacht 
nur...) und das ging auch damit, da man erstmal überhaupt was sieht. K&R 
ist aber so schlecht nicht für Einsteiger.

Dass man nach so 'nem Grundlagenbuch eigentlich noch gar nix kann, was 
die ganzen anderen Aspekte der Softwareentwicklung betrifft (Testen, 
Requirements, Doku, Refactoring, Zeitrahmen einhalten, ...), ist doch 
ohnehin klar.

Yalu X. schrieb:
> sondern wurden es erst mit der Einführung von C99, das in
> diesem Punkt nicht abwärtskompatibel zur früheren C-Versionen ist.

Ach tatsächlich, ok dann ist Linux entschuldigt...

Yalu X. schrieb:
> Der Linux-kernel ist schon ein paar Jahre älter als die Strict-Aliasing-
> Rule. Die fraglichen Teile des Linux-Kernels waren nicht von Anfang an
> fehlerhaft, sondern wurden es erst mit der Einführung von C99, das in
> diesem Punkt nicht abwärtskompatibel zur früheren C-Versionen ist.

Wie sicher bist du dir da? Ich habe hier ein pdf, das sich ansi/iso 
9899-1990 nennt. Darin steht in im Kapitel 6.3 "Expressions" folgender 
Absatz:

1

An object shall have its stored value accessed only by an lvalue that has one of the following types:*

2

- the declared type of the object,

3

- a qualified version of the declared type of the object.

4

- a type that is the signed or unsigned type corresponding to the declared type of the object,

5

- a type that is the signed or unsigned type corresponding to a qualified version of the declared type of the object.

6

- an aggregate or union type that includes one of the aforementioned types among its members (including, recursively, a member of a aggregate or contained union), or

7

- a character type.

8

9

* The Intent of the list is to specify those circumstances in which an object may or may not be aliased.

Im c11 Draft (n1579) steht folgendes in Kapitel 6.5 "Expressions":

1

7 An object shall have its stored value accessed only by an lvalue expression that has one of

2

the following types:*

3

— a type compatible with the effective type of the object,

4

— a qualified version of a type compatible with the effective type of the object,

5

— a type that is the signed or unsigned type corresponding to the effective type of the

6

object,

7

— a type that is the signed or unsigned type corresponding to a qualified version of the

8

effective type of the object,

9

— an aggregate or union type that includes one of the aforementioned types among its

10

members (including, recursively, a member of a subaggregate or contained union), or

11

— a character type.

12

13

* The intent of this list is to specify those circumstances in which an object may or may not be aliased.

Die Fußnote ist sogar identisch.

Ich frage mich übrigens gerade, ob es heutzutage für einen Anfänger noch 
Sinn macht, mit einem reinen C Buch anzufangen. Sollte man nicht gleich 
ein C++ Buch lesen? Wenn man sich dann später auf C beschränken will, 
ignoriert man eben den OOP Kram mit Klassen und die C++ Bibliotheken 
usw. Die OOP Grundidee ist heute ja eh Allgemeinwissen, so dass man sich 
dadurch nicht so viel mehr unnötigen Lernaufwand aufbürded, und die 
Kapitel des Buches die C++ Bibliotheken beschreiben kann man ja 
(zunächst) ignorieren.

Ich habe C vor langer Zeit mit irgendeinem billigen und eher schlechten 
C-Buch gelernt. Jedenfalls habe ich den Eindruck, dass Bücher wie der 
C++ Primer von Lippman schon ganz gut erklären. Ein paar reine C-Sachen 
wie Datentyp struct oder C specifischen Input/Output mag fehlen, aber 
gut das kann man in Online-Quellen nachlesen.

Philipp K. schrieb:
> Naja das Geheimnis des Beispiels ist das es funktioniert..
Hm. Also ich sehe im C-Standard keinerlei Garantie, dass der von strtok 
zurückgegebene Zeiger auf einen statischen Speicher zeigt. Und selbst 
wenn, wäre es doch ein extrem schlechter Stil. Valgrind meckert bei dem 
Programm auch.

Stefan schrieb:
> Sollte man nicht gleich
> ein C++ Buch lesen?
Meiner Meinung nach ja; wenn man C++ kann ist es relativ leicht auf C 
umzusteigen. Natürlich wird man sich dann ärgern dass C so limitiert ist 
und lieber so viel wie möglich in C++ machen.

Mikro 7. schrieb:
> Oder mit Linus' Worten

Was der so von sich gibt muss man nicht so ernst nehmen... Ist bei dem 
Anteil an Beschimpfungen auch besser für die geistige Gesundheit.

Rolf M. schrieb:
> Der zurückgegebene Zeiger zeigt auf den Speicher, den man ihm übergeben
> hat. Und der ist in diesem Fall nicht statisch.
In der Linux man-Page heißt es:
"* The strtok() function uses a static buffer while parsing, so it's not 
thread safe."
Daraus zu folgern dass man das als statischen Puffer missbrauchen kann 
ist aber schon kriminell. Die Größe ist ja auch fix. Und im C-Standard 
steht's ja auch nicht.
Eine der Fallen von C ist ja, dass viele Dinge den Anschein haben zu 
funktionieren, aber falsch sind und bei veränderten Bedingungen 
(Compiler/Version/Plattform) schief gehen. Das Argument "Funktioniert 
doch" zählt hier überhaupt nicht...

Rolf M. schrieb:
> Naja, als Berufsfremder wird man es vielleicht auch anschaulich finden,
> wenn jemand mit einem Hammer eine Schraube in die Wand klopft, und es
> mag auch funktionieren. Aber es ist eben trotzdem blödsinnig.
Ganz genau!

Philipp K. schrieb:
> Ich habe das Problem dabei aber schon sofort verstanden, auch wenn ich
> noch nie was über Pointer gelesen habe.

Das hat mit Pointern auch nix zu tun, sondern mit dem Scope lokaler 
Variablen.

Philipp K. schrieb:
> Denn eine Funktion direkt zurückzugeben macht man sowieso nicht..

Du meinst man soll kein "return irgendeineFunktion (...);" machen? Das 
ist überhaupt kein Problem und sogar sinnvoll, weil es u.U. gewisse 
Optimierungen wie tail-recursion ermöglicht bzw. einen Sprung statt 
Aufruf. Man kann den Rückgabewert in eine Variable speichern und den 
zurückgeben, aber was hätte das für einen Vorteil?

Philipp K. schrieb:
> dann würde das Beispiel nicht mehr
> funktionieren?
Das Beispiel funktioniert vermutlich schon nicht mehr wenn man in der 
main, nach Zeile 18, irgendwas anderes einfügt, wie z.B. einen Aufruf an 
eine andere Funktion. Dass es auf einer bestimmten Plattform den 
Anschein hat zu funktionieren ist purer Zufall, es könnte auch irgendwas 
anderes machen.

Ich habs jetzt mal ausprobiert. Rolf Magnus hatte recht, strtok gibt 
auch unter Linux einen Zeiger auf den Eingabepuffer zurück. Ändert man 
das Beispiel so (die "eingabe"-Funktion bleibt gleich!):

1

/* ptr13.c */

2

#include <stdio.h>

3

#include <stdlib.h>

4

#include <string.h>

5

#define MAX 255

6

7

char *eingabe(char *str) {

8

   char input[MAX];

9

10

   printf("Bitte \"%s\" eingeben: ",str);

11

   fgets(input, MAX, stdin);

12

   return strtok(input, "\n");

13

}

14

15

int main(void) {

16

   char *ptr1, *ptr2;

17

18

   ptr1 = eingabe("Vorname");

19

   ptr2 = eingabe("Nachname");

20

   printf("Hallo %s %s\n", ptr1, ptr2);

21

   printf("%s, interssanter Nachname\n", ptr2);

22

   return EXIT_SUCCESS;

23

}

Sieht es so aus:

1

$ ./a.out 

2

Bitte "Vorname" eingeben: Hans

3

Bitte "Nachname" eingeben: Meier

4

Hallo Meier Meier

5

Meier, interssanter Nachname

Das ist auf jeden Fall verkehrt, und der Fehler liegt in der 
"eingabe"-Funktion, er tritt nur nicht unter jedem Umstand zu tage. Eine 
Schraube mit dem Hammer einzuhämmern mag vielleicht manchmal 
funktionieren, aber wenn man ein Bild dranhängt klappt das nicht mehr so 
gut.

Ein weiteres Problem ist übrigens, dass das "str"-Argument an "eingabe" 
nicht "const" ist.

Rolf M. schrieb im Beitrag #5311079:
> Kann es nicht, da strtok() den übergebenen String modifiziert.
Achja. In C++ darf man String-Literale nicht einfach überschreiben, hab 
grad nich im Kopf wie das bei C ist...

Oh, tatsächlich. Hab ich auch verdreht...

Nur aus Interesse, wie schneidet dieses Büchlein im Expertenstreit ab?
(ISBN: 3934358039 / 3-934358-03-9)

https://www.ebay.de/itm/C-C-Von-den-Grundlagen-zur-professionellen-Programmierung-m-CD-Rom-Ulr/232407127909?hash=item361c8b5765:g:4EoAAOSwK~RaCwhU

Monokollonialer Antikörper mit Senf schrieb:

> Nur aus Interesse, wie schneidet dieses Büchlein im Expertenstreit ab?
> (ISBN: 3934358039 / 3-934358-03-9)

LOL.


Wenn ich negativen (sachlich begründeten) Kritiken auf Amazon lese: 
MegaLOL.

C lernt man doch mit Kernigham und Ritchie. Das ist Fakt.

Monokollonialer Antikörper mit Senf schrieb:
> Nur aus Interesse, wie schneidet dieses Büchlein im Expertenstreit ab?
> (ISBN: 3934358039 / 3-934358-03-9)
>
> Ebay-Artikel Nr. 232407127909

Merke: Vorsichtig sein, wenn dir ein C/C++ über den weg läuft.

Man weiß nie, ob die andere Person zu Faul ist zwischen C und C++ zu 
unterscheiden oder, ob sie nicht weiß, dass es sich um zwei 
unterschiedliche Sprachen handelt.

Karl schrieb:
> Monokollonialer Antikörper mit Senf schrieb:
>
>> Nur aus Interesse, wie schneidet dieses Büchlein im Expertenstreit ab?
>> (ISBN: 3934358039 / 3-934358-03-9)
>
> LOL.
>
>
> Wenn ich negativen (sachlich begründeten) Kritiken auf Amazon lese:
> MegaLOL.

Moment mal bitte. Wenn ich die Kritiken richtig interpretiere, hat KEIN 
EINZELNER Rezensent inhaltliche Probleme oder sachlich begründete Kritik 
am Inhalt a la Dr. Sommer am Originalbuch. Dir Kritik lautet einhellig 
"das ist kein Buch für Nafänger und setzt mathematische Kenntnisse 
voraus, anstatt Glitzibunti Olala Beispiele zu zeigen."

Wenn dem so ist, scheint es mir wenn überhaupt ein nicht gut 
positioniertes Buch zu sein, aber bei weitem nicht ein schlechtes Buch.

Wäre also wenn es denn so ist durchaus ein Kaufkandidat für Jemanden, 
der sich für Tiefe anstatt Jumpstart interessiert.

mh schrieb:
> Merke: Vorsichtig sein, wenn dir ein C/C++ über den weg läuft.
Genau, das ist wie zu sagen "Ich kenn mich mit Java/Javascript aus" oder 
"Ölbohren/Ölgemälde" :)

Adapter schrieb:
> Moment mal bitte. Wenn ich die Kritiken richtig interpretiere, hat KEIN
> EINZELNER Rezensent inhaltliche Probleme oder sachlich begründete Kritik
> am Inhalt a la Dr. Sommer am Originalbuch.
Aber an dem anderen Galileo Buch. Ist jetzt die Frage ob da eine 
Kausalität bestehen könnte.

Dr. Sommer schrieb:
> mh schrieb:
>> Merke: Vorsichtig sein, wenn dir ein C/C++ über den weg läuft.
> Genau, das ist wie zu sagen "Ich kenn mich mit Java/Javascript aus" oder
> "Ölbohren/Ölgemälde" :)
>
> Adapter schrieb:
>> Moment mal bitte. Wenn ich die Kritiken richtig interpretiere, hat KEIN
>> EINZELNER Rezensent inhaltliche Probleme oder sachlich begründete Kritik
>> am Inhalt a la Dr. Sommer am Originalbuch.
> Aber an dem anderen Galileo Buch. Ist jetzt die Frage ob da eine
> Kausalität bestehen könnte.

Hä? Da wird also ein Buch in Sippenhaft genommen für ein schlechtes Buch 
aus demselben Verlag? Was soll denn das? Ist das Buch nun schlecht, weil 
es ein schlecht geschriebenes oder inhaltlich schlechtes Buch ist, oder 
weil es zufällig im selben Verlag erschienen ist wie ein Anderes, 
inhaltlich schlechtes Buch? Was ist das denn für eine Logik? Oder habe 
ich da etwas falsch verstanden?

Yalu X. schrieb:
> Damit hat auch Dr. Sommer recht mit seiner Aussage, dass der
> Linux-Kernel
> fehlerhaften Code enthält.

Jetzt müsst ihr nur noch annehmen, dass die Herren Kernel-Programmierer 
ihre Kenntnisse aus der vom TE benannten Lektüre bezogen ..

:-]

Übung macht den Meister :-] schrieb:
> Jetzt müsst ihr nur noch annehmen, dass die Herren Kernel-Programmierer
> ihre Kenntnisse aus der vom TE benannten Lektüre bezogen ..

Unwahrscheinlich, der Kernel funktioniert doch nahezu konsistent!
- Duck und wech -

Yalu X. schrieb:

> Damit hat auch Dr. Sommer recht mit seiner Aussage, dass der
> Linux-Kernel
> fehlerhaften Code enthält.

Kompletter Unfug.

Der Kernel enthält Code, der die Strict-Aliasing-Regeln bricht.
Gleichzeitig schaltet der Kernel-Build aber die Strict-Aliasing-Regeln 
ab.
Das bedeutet, dass der Code nicht fehlerhaft ist, sondern bewusst so 
geschrieben ist.

Wenn etwas nicht standardkonform ist, heißt das nicht gleich, dass es 
fehlerhaft ist.

Ma W. schrieb:
> Wenn etwas nicht standardkonform ist, heißt das nicht gleich, dass es
> fehlerhaft ist.

Es ist fehlerhaft im Sinne des Standards. Dass der GCC eine Option 
bietet über solche Fehler hinwegzusehen ist pure Nettigkeit.
Das ist aber auch kein Beinbruch - wenn man sich des Fehlers und seiner 
Folgen bewusst ist und man die entsprechenden Compiler Optionen kennt 
ist das akzeptabel. Bleibt nur zu hoffen dass der GCC diese Option nie 
entfernt. Das vom Standard garantierte Verhalten wird er aber wohl immer 
bieten, d.h. korrekte Programme gehen immer.

Dr. Sommer schrieb:
> Es ist fehlerhaft im Sinne des Standards.

Nein. Das Programm ist nicht fehlerhaft.

Das Programm ist nicht standardkonform. Es erhebt auch nicht den 
Anspruch standardkonform zu sein. Deshalb kann es auch nicht "fehlerhaft 
im Sinne des Standards" sein.

Es ist unmöglich einen OS-Kernel in standardkonformem C zu schreiben.

Ma W. schrieb:
> Nein. Das Programm ist nicht fehlerhaft.
>
> Das Programm ist nicht standardkonform.

Und was für eine Art von Programm ist Standard konform, aber fehlerhaft?

Ma W. schrieb:
> Es ist unmöglich einen OS-Kernel in standardkonformem C zu schreiben.
Stimmt auch wieder.

Dr. Sommer schrieb:
> Es ist fehlerhaft im Sinne des Standards. Dass der GCC eine Option
> bietet über solche Fehler hinwegzusehen ist pure Nettigkeit.

Ich denke das ist falsch.

Strict-Aliasing erlaubt dem Compiler weitere Optimierungen.

Wenn man mit Option no-strict-aliasing compiliert, kann der Compiler 
diese betreffenden Optimierungen eben nicht machen.

Wobei ich gelesen hatte, dass es etwas schwierig ist Strict-Aliasing 
einzuhalten, und dass die diesbezüglichen Optimirungen auch nicht so 
viel bringen, allenfalls einige % mehr performance.


>Es ist unmöglich einen OS-Kernel in standardkonformem C zu schreiben.

Das kann ich mir eigentlich nicht vorstellen.

Stefan schrieb:
>>Es ist unmöglich einen OS-Kernel in standardkonformem C zu schreiben.
>
> Das kann ich mir eigentlich nicht vorstellen.

Wie schreibt man denn Interrupt-Service-Routinen oder Early-Boot-Code in 
Standard-C ohne Nicht-Standard-Extensions?

Man wird immer Bestandteile im Kernel haben, die gar nicht 
standardkonform sein können.

Dr. Sommer schrieb:
> Und was für eine Art von Programm ist Standard konform, aber fehlerhaft?

1

int sum(int a, int b)

2

{

3

  return a * b;

4

}

5

6

int main()

7

{

8

  return sum(1, 2);

9

}

Bei manchen Threads bekommt man wirklich das Gefühl, dass Blinde über 
Farben zu diskutieren versuchen.

Und wo soll da der Fehler sein, oh Sehender?

Dr. Sommer schrieb:
> Und wo soll da der Fehler sein, oh Sehender?

Na dann schau mal genauer.

Rolf M. schrieb:
> Ob das Programm fehlerhaft ist, kann nicht beurteilt werden, da nicht
> dabei steht, was es tun soll. Wenn die Aufgabe des Programms ist, die
> Summe aus 1 und 2 zurückzugeben, ist es fehlerhaft. Soll es das Produkt
> aus 1 und zwei zurückgeben, dann ist es korrekt, und der Name der
> Funktion zur Berechnung ist nur sehr unglücklich gewählt.

Unfug. Es ist kein "Fehler," einer Funktion einen Namen zu geben, der 
nicht mit dem übereinstimmt, was die Funktion tut. Es ist vermutlich 
sinnfrei und irritierend, aber kein Fehler.

Ich sehe in dem Codefragment zwei Fehler:

1. Überlauf nicht berücksichtigt
2. Rückgabe von der main() Funktion ist nicht dazu gedacht, Ergebnisse 
einer Berechnung zurückzugeben, sondern dessen exit status.

Rolf M. schrieb:
> weil so viele GCC-Spezifika
> kreuz und quer über den ganzen Kernel benutzt wurden.

Und du glaubst echt, das wird gemacht, weil man keine Lust hat es 
standardkonform zum implementieren?
Hast du mal daran gedacht, dass es gute Gründe hat kein Standard-C zu 
verwenden?

>Wenn es mit einem neueren, strikteren Compiler nicht
>mehr läuft, ist für ihn der Compiler fehlerhaft und nicht das Programm.

So allgemein ist das natürlich falsch.
Bitte zitiere Linus' Aussage.

So so, eine Funktion, die nicht das tut, was ihr Name sagt, ist also 
kein Fehler, sondern nur "unglücklich". Naja, Hobbyprogrammierer halt.

Yalu X. schrieb:
> Aber der Name ist tatsächlich ziemlich unglücklich gewählt,

Wieso, das ist doch in C so kryptisch und damit völlig normal.

Rolf M. schrieb:
> Ich würde in so einem
> Fall meinen  Code reparieren (oder ggf. auch einen Work-Around suchen),
> aber nicht dem Tool die Schuld geben.

Natürlich.
Und jetzt kommen wir wieder in der Realität an.

Wenn ein Compiler funktionierenden Code kaputtoptimiert, dann muss es 
dafür schon einen guten Grund geben.
Wenn er das nur aus Prinzip tut und keinen Performancevorteil bietet, 
dann gehören die Compiler-Entwickler gesteinigt.

Ma W. schrieb:
> Wenn er das nur aus Prinzip tut und keinen Performancevorteil bietet,
> dann gehören die Compiler-Entwickler gesteinigt.

Damit man den Fehler nicht so schnell findet, und der erst dann auffällt 
wenn aufgrund geänderter Umstände die Optimierung dann doch einen 
Performance-Vorteil bringt?