Hallo zusammen, ich bin über einen anderen Thread hier gelandet, in dem diskutiert wurde, ob C-Bücher wirklich alle so schlecht sind. Dabei bin ich auch auf die Amazon-Bewertungen von "Max" gestoßen. Der hat ja wirklich kein Blatt vor den Mund genommen und die Bücher ziemlich zerlegt. Genau diese Art von präziser, kritischer Rückmeldung finde ich interessant, aber im Vorfeld und nicht, wenn das Kind schon in den Brunnen gefallen ist.
Denn, ich habe ein C-Buch geschrieben, das demnächst beim Rheinwerk erscheinen soll, und suche gezielt Leute, die mit einem scharfen Blick über den Text gehen und auch Details hinterfragen, idealerweise von Leuten, die sich in C sehr gut auskennen. Wer sich angesprochen fühlt und Lust hat, das Buch entsprechend kritisch zu prüfen, kann sich gern per PM bei mir melden.
(Und falls jemand von euch Amazon-Max kennt oder einen Kontakt herstellen kann, würde ich mich ebenfalls freuen.)
Das Inhaltsverzeichnis habe ich hier als PDF beigefügt.
Als Schriftsteller solltest du (korrekt) zitieren.
Was soll er denn zitieren wenn ausschließlich ein weiterer Beitrag dazwischen ist? Ist ja nicht so das es da jetzt kein Zusammenhang mehr geben würde zwischen deinem Post und seinen...
Erster Gedanke nach einem kurzen Blick ins Inhaltsverzeichnis: warum soll man 1000 Seiten lesen (das dickste Buch mit ca. 1000 Seiten bei meinen Eltern im Bücherregal waren Shakespeares gesammelte Werke...)
C habe ich aus Kernighan&Richie gelernt. Hat (in meiner Auflage von 1983) nur 260 Seiten. Und selbst C++ von Barne Stroustrup hatte nur 950 Seiten.
Da vergeht mir die Lust mich als Lektor anzubieten, obwohl ich C seit über 40 Jahren kenne und nutze :)
Kernfrage für irgendeine Bewertung ist: wer ist die Zielgruppe? Schüler/Studenten? Hausmänner und Frauen die noch nie programmiert haben? IT-Anfänger oder Profis? Warum ein Buch, wo es alle Infos im Internet incl. Tutorials und Videos gibt?
Das Inhaltsverzeichnis habe ich hier als PDF beigefügt.
Über 1000 Seiten? Echt?
Das Inhaltsverzeichnis klingt aber nicht schlecht.
Was ist denn dein Zielpublikum? Einsteiger wohl nicht, die scheitern schon am Gewicht. :-)
Ein Nachschlagewerk, aber ohne Bibliotheken?
Mein Lieblings-C-Buch ist von Koenig (ich habs grad nicht zur Hand, darum kein besserer Titel; ist von O'Reilly). Eigentlich ist das erschöpfend für mich.
Vielleicht hast du mal eine Leseprobe (10 Seiten?).
Aber 1000 Seiten pingelig durchzugehen dürfet wohl für viele einfach zu viel sein.
Das war ja auch noch das grottige K&R-C ohne Typprüfung, Funktionsprototypen etc. Und die deutsche Ausgabe war in gleich mehrerer Hinsicht grauenerregend - einerseits sehr merkwürdig von einem Freund der Deppen Leer Zeichen übersetzt, und andererseits waren Codebeispiele in einer /Proportionalschrift/ gesetzt.
Die zweite Ausgabe von 1989 behandelte das damals "ANSI-C" genannte C89, und war deutlich besser übersetzt und auch gesetzt.
Beide erschienen im Hanser-Verlag.
C hat sich aber seit C89 deutlich weiterentwickelt.
Oh - toll, noch ein C-Buch. Es gibt ja gefühlt erst 1000.
In dem Verlag ist ja bereits für das zweite Habljahr das C-Buch "C programmieren - Das umfassende Handbuch (Modernes C23 von Anfang an)" angekündigt. Das ist aber sichlerlich von einem anderen Christian. Was mach dein Buch besser als dieses?
Das Buch ist als Lehrbuch angelegt und basiert auf C23. Es richtet sich an Einsteiger, deckt aber auch fortgeschrittene Themen wie Metaprogrammierung, Ownership-Modelle und Allokatoren ab.
Wenn man Grundlagen und weiterführende Konzepte inklusive Best-Practices/Pattern und Anti-Patterns zusammenhängend darstellt, geht der Seitenzähler schnell hoch.
Ein Buch mit 1000 Seiten ist viel, klar, und jedes Buch hat andere Zielgruppen und Leserschaften. Manche wollen ein vollständiges Nachschlagewerk, andere arbeiten sich punktuell durch verschiedene Quellen im Internet.
Das war ja auch noch das grottige K&R-C ohne Typprüfung,
Das ist bei mir schon ewig im Altpapier. Ich versteh echt nicht, wie man sich darauf berufen kann/möchte.
Ich lese zur Zeit (ganz langsam) "21st Century C" von Ben Klemens.
Ich befürchte aber, dass ich das nicht empfehlen kann. Da stehen recht eigenartige Tips drinnen und es hat einen dogmatischen Schreibstil.
Vom Schreibstil her hat mir der Stroustrup (irgend was altes) ganz gut gefallen. Das konnte man wirklich von Anfang bis zum Ende durcharbeiten aber auch zum Nachschlagen gebrauchen.
Hui also schonmal Respekt für das Inhaltsverzeichnis.
Ich habe noch nie ein C/C++ Buch gelesen, nutze aber C++ schon seit ungefähr 20 Jahren und würde mir zutrauen zu fast jedem Thema im Inhaltsverzeichnis meinen Senf dazugeben zu können. Man ist manchmal selbst überrascht, was man so an mehr oder weniger unnützen Wissen im Laufe seines Lebens ansammelt (schönes Beispiel: wchar_t).
Viel Erfolg dir auf alle Fälle und unabhängig vom Erfolg meinen Respekt für dieses Werk!
Das Inhaltsverzeichnis habe ich hier als PDF beigefügt.
Sieht nach schnellem Überfliegen m.E.n. ganz vielversprechend aus.
Ich frage mich allerdings, ob sich bei so einem ambitionierten Buchprojekt zu einem Informatik-/IT-Thema eine Veröffentlichung auf Deutsch noch wirklich lohnt. Evtl. könntest du in Kooperation mit dem Verlag parallel eine Ausgabe auf Englisch herausbringen. Das würde den Leserkreis jedenfalls stark erweitern, global gesehen, und das Werk bekannter machen.
Ich habe nur eine einfache Frage:
Was macht dein Buch so besonders, dass ich genau dieses anstelle der dutzenden anderen auf dem Markt kaufen möchte/sollte?
Das Inhaltsverzeichnis habe ich hier als PDF beigefügt.
Sieht nach schnellem Überfliegen m.E.n. ganz vielversprechend aus.
Ich frage mich allerdings, ob sich bei so einem ambitionierten
Buchprojekt zu einem Informatik-/IT-Thema eine Veröffentlichung auf
Deutsch noch wirklich lohnt. Evtl. könntest du in Kooperation mit dem
Verlag parallel eine Ausgabe auf Englisch herausbringen. Das würde den
Leserkreis jedenfalls stark erweitern, global gesehen, und das Werk
bekannter machen.
Der Aufwand waere schon sehr heftig (technischer Uebersetzer und englisches Lektorat). Und da stellt sich die Frage: Was hat das Buch, was alle anderen nicht haben?
Du hast natuerlich recht, dass der TO mehr Leser bekommt, aber leider auch die Zahl der Mitbewerber (die anderen englisch-schreibenden Autoren) ist auch deutlich groesser.
Ich habe (auch wg. der deutschen Uebersetzung vom Kernighan & Richie) angefangen, die Werke in der Originalsprache zu lesen. Der K&R, 1. Auflage aus dem Hanser-Verlag war zu schlecht.
Ich würde mich als Probeleser zur Verfügung stellen: Ich hab C-Grundkenntnisse und mich immer mal wieder dran versucht, aber irgendwie fehlte mir bislang der rote Faden. Wenn das Buch den liefert, ist es gut. Ich sehe mich auch in der Lage, brauchbares Feedback und konstruktive Kritik liefern zu können.
1000 Seiten sind kein Hindernis, wenn gut geschrieben.
Das Buch ist als Lehrbuch angelegt und basiert auf C23. Es richtet sich
an Einsteiger, deckt aber auch fortgeschrittene Themen wie
Du suchst C-Profis als Korrekturleser, die offensichtlich nur eine fachliche Prüfung vornehmen sollen.
Was ist denn mit der Didaktik*? Dafür brauchst Du Anfänger.
Weiter zu kontrollieren ist doch Rechtschreibung, Kommasetzung und Satzbau. Die ersten beiden Prüfpunkte macht wohl der Computer. Mögliche Sprachsaltos, zum Beispiel Endlossätze, extrem geschachtelte Sätze sollten vermieden werden - ist das kein Anliegen für Dich?
Schon bei Durchsicht des Inhaltsverzeichnis fallen mir Dinge auf:
Ich kann's erahnen, weiß es aber nicht, was der Begriff bedeutet.
Erster Gedanke: Gibt es im Lateinischen das Verb präcendere? Mein Hirn zeigt gähnende Leere an. Für wen verwendest Du den Begriff?
Hätte es "Operatorenhierarchie" nicht auch getan?
Dein Inhaltsverzeichnis ist gigantisch groß, strukturiert, aber leider unlesbar. Ich kann da nicht schnell mit dem Auge durchscrollen.
Grenze die Ebenen voneinander stärker ab, z.B. durch Fettschrift, Kursivschrift, dezente Färbung der Schrift oder des Hintergrunds.
Dein Rieseninhaltsverzeichnis ist ein Spezialfall, das etwas Zusatzaufwand erfordert, meine ich.
Ich würde von Dir eine ZIP-Datei erwarten, die eine Dateistruktur enthält, die Dein Inhaltsverzeichnis nachbildet. Entpacke ich die ZIP-Datei, sehe ich nur die oberste Hierarchie. Ich öffne dann den Ordner, indem ich mein Thema vermute und hangele mich so weiter bis zur dritten Ebene.
Bei Dir muss ich immer wieder linear alles durchlesen, Zugriffszeit O(n).
Mit einer hierarchischen Struktur, die ein Buch schlecht abbilden kann, gehe ich in Richtung O(log(n)).
Eine Möglichkeit bestünde auch darin, in einem Kurzinhaltsverzeichnis nur die erste und zweite Ebene anzuzeigen.
Mal abgesehen von meiner ätzenden Kritik wünsche ich Dir natürlich gutes Gelingen!
*Didaktik Beispiel:
Die Vorlesung Analysis I kann man "schulmäßig" abhalten.
Man kann sie aber auch anhand von Banach-Räumen aufziehen. Da jubeln die Mathematiker weil wohl der Inhalt von Analysis I nur ein Spezialfall von Banach-Räumen ist, für Mathematik-Studenten eine Supersache.
Die Informatiker, Wirtschaftsinformatiker, Chemiker und Physiker, die diese Vorlesung auch hören und nie mir in ihrem Leben Banach-Räume anfassen müssen, schauen sich das an und holen geschlossen ihre Tränenvase aus der Tasche...
Krass, du hast echt 1000 Seiten vollgeschrieben mit Dingen diean nicht auf 100 Seiten lesen will ?
Die Zeit solcher Bücher ist vorbei.
Es gibt heute nicht nur K&R C, sondern zig Varianten, zig IDE, zig Plattformen, zig Librarys und ein Buch kann nicht alle andevken und wenn man es tut, wird es unübersichtlich.
Was man heute haben will ist ein 'sich selbst generierendes' Buch, dem man zunächst sagt welchen C-Dialekt auf welcher Plattform man mit welcher IDE unter Verwendung welcher Libraries man zu benutzen gedenkt, und dass dann von selbst seinen Inhalt an genau dieses anpasst, also
"Windows MSVC für National Instruments LabViee"
oder "Arduino unter Linux mit EMACS unter Verwendung von ArduinoGFX"
und dann liest man nur genau das was auf der eigenen Umgebung auch funktioniert .
Vergleiche Windows API Hilfe für Borland Turbo C, die halt zwar nur für 1 Umgebung, passte aber.
Heute wird man meist verwirrt weil Versatzstücke unterschiedlichster Umgebungen (Kommandozeile/Windows/embedded, KeilC/C99/Gnu, Linux) eben nicht auf das passen was man vor sich hat.
Schönstes Beispiel ist Windows UWP (ok, C++) dessen Doku schon längst nicht mehr zum aktuellen Stand der Software passt, jedes Beispiel, jedes Kapitel, ging nur damals als die Version existierte zu der die Doku geschrieben wurde.
Ein generisches C Buch das nur Kommandozeile abdeckt darf keine 50 Seiten haben, der Rest ist Seitenschindetei (ich weiss, als Autor wurde man oft nach Seiten bezahlt).
Du hast natuerlich recht, dass der TO mehr Leser bekommt, aber leider
auch die Zahl der Mitbewerber (die anderen englisch-schreibenden
Autoren) ist auch deutlich groesser.
Ich dachte zunächst auch an eine Englische Ausgabe. Ich lese solche Bücher nur in Englisch. Und wenn es eine Übersetzung ins Deutsche gäbe, würde ich immer noch das Englische Original lesen. "C für Dummies" ist nicht mein Niveau.
Die Gefahr, dass beim übersetzen das Buch leidet ist höher, als dass es besser wird. Dazu braucht es nämlich einen Fachübersetzer. Also wirklich einen vom FACH.
Also ist mein anfänglicher leichter Widerstand so ein Buch in Deutsch zu lesen unbegründet und weg.
Ein Gegenargument wäre aber, dass ein Softwareentwiggler englischsprachige Literatur lesen können muss. Da könnte er dann gleich üben (und bestensfalls da schon aufgeben <harharhar>).
ernfrage für irgendeine Bewertung ist: wer ist die Zielgruppe?
Schüler/Studenten? Hausmänner und Frauen die noch nie programmiert
haben? IT-Anfänger oder Profis?
Sehe ich genauso.
Die (teils kurzen und) tief gegliederten Kapitel könnten suggerieren, dass dort zwar die "richtige" Info steht aber eher sachlich und nicht "faszinierend".
Wenn "Endlosschleife" bei while steht oder "JSON-Dokumente" bei break und continue, macht mich das zwar neugierig aber wenig zuversichtlich.
Ein typisches Kapitel von einer halben Seite mit 2-3 Worten zum Kontext wäre wirklich hilfreich.
Das Inhaltsverzeichnis wirkt schon recht ordentlich, muss halt nur noch aufgeräumt werden, weil sich einige Themen und Begrifflichkeiten überlagern. Wiederholung stört zwar nicht, aber mit ein wenig mehr Ordnung drin schon OK.
Nach didaktischem Buch sieht es auch nicht aus, da sind K+R und Erlenkötter sehr viel besser. Accelerated C++ wäre in diesem Zusammenhang auch eine Empfehlung. Das Inhaltsverzeichnis sieht viel eher nach einem großen Nachschlagebuch aus. Praktische Programme, Algos und MC-Stuff wäre auch schön - wie gesagt, etwas mehr Aufräumen, etwas Ausdünnen und eben auch gewisse Schwerpunkte setzen (wie im letzten Satz vor dem Gedankenstrich z.B.).
Außerdem haben wir ja auch KI/AI-Zeiten - so gesehen könnten ein paar Tipps dazu auch nicht verkehrt sein ;)
Ich dachte zunächst auch an eine Englische Ausgabe. Ich lese solche
Bücher nur in Englisch.
/Auf/, nicht /in/. /In/ ist ein Anglizismus.
Ich lese sowas bevorzugt auch nur auf Englisch; mir ist bislang nur einmal ein Fachbuch bzw. eine Dokumentation untergekommen, bei der die deutschsprachige Fassung erheblich besser war als das englische Original.
Und das war das Handbuch zu Borland Turbo C 2.0, dessen deutsche Fassung jemand namens Arne Schäpers verfasst hatte. Das dürfte 1989 gewesen sein. Dahinter steckte damals der deutsche Softwarevertrieb namens Heimsoeth.
Genau diese Art von präziser, kritischer Rückmeldung
finde ich interessant, aber im Vorfeld und nicht, wenn
das Kind schon in den Brunnen gefallen ist.
Ich finde, das ist im Prinzip schonmal ein sehr lobens-
werter Ansatz, der Unterstützung verdient.
Allerdings fürchte ich, dass das Kind dennoch bereits
in den Brunnen gefallen ist: Das Manuskript wird ja im
großen und ganzen schon fertig sein, und ich vermute,
Du wirst sehr wenig Lust haben, die eine Hälfte des
Textes wegzuwerfen und die andere Hälfte massiv
umzuordnen.
Also beschränkt sich der Einfluss der hier gesuchten
Testleser (schätzungsweise) darauf, Tippfehler und
sonstige kleine Irrtümer aufzuspüren und Dir zu melden.
Eine etwas unbefriedigende Aussicht, wie ich finde...
Ich habe mehrere (bisher gescheiterte) Anläufe hinter
mir, C zu lernen: Der Leidensdruck auf der einen und
die masochistische Neigung, mich durch die verfügbaren
C-Bücher zu quälen, auf der anderen Seite waren bis
jetzt nicht groß genug...
Der Knackpunkt liegt m.E. nicht in den technischen
Details (die kann man bei Bedarf auch im Standard
nachschlagen), sondern in der didaktisch sinnvollen
Gliederung des Buches.
Alle Informationen über C und C23 findet man im Internet. Da kann man auch bequem suchen lassen. In einem 1000 seitigen Buch etwas zu suchen ist doch extrem mühsam. Vor über 30 Jahren hatte ich selbst mal Programmierbücher. Weil es damals nichts besseres gab.
Heute gibt es kostenlos dutzende gute Tutorials als PDF und bei Youtube. Und falls man noch spezielle Fragen hat, die in den Tutorials nicht behandelt werden, dann kann kann man sich das z.B. von Claude Opus erklären lassen.
Die KI nimmt dabei nicht das denken ab. Man hat mit der KI seinen eigenen Privatlehrer.
Seid einfach offen für neues. Es bringt nichts sich dem Fortschritt zu verweigern.
Und jetzt noch etwas konstruktives:
Einerseits macht das Buch für mich den Eindruck, dass es für Programmieranfänger geschrieben ist, weil teilweise sehr viel Raum für Dinge verwendet wird, die absolute Grundladen sind. Andererseits werden auch viel fortschrittlichere Konzepte behandelt, die schon einiges an Programmiererfahrung voraussetzen.
Ich würde deshalb das Buch in zwei oder vielleicht sogar drei Teile aufteilen und klar zwischen den Themenbereichen trennen.
Dem Inhaltsverzeichniss nach geht das in Richtung "Hochschullehrbuch für Informatikstudenten aus der Ecke Softengineering/Betriebssysteme", definitiv kein Buch für Hobby- und Gelegenheitscoder.
Gut das man einige Theorie und Basics zum Software-Engineering nachlesen kann, vermisst habe ich persönlich Ausführungen dediziert zur bare metal Programmierung im Embedded Bereich, wie man sie in der Technischen Informatik erwartet.
Ich will jetzt kein Fass aufmachen, aber: Warum nicht Rust?
Ich bin mir einfach nicht sicher, warum man heute noch C in so einer Weise lernen sollte. Das Buch ist sehr lang und beschäftigt sich auf sehr vielen Seiten mit relativ "einfachen" Konzepten, wird bei den komplexeren Konzepten aber immer knapper. Zum Vergleich: Das Kapitel zu Schleifen ist nur etwas kürzer als das Kapitel zum Präprozessor. Das ist meines Erachtens nach sehr viel verschenktes Potenzial, da man davon ausgehen muss, dass sich heute niemand ein C-Buch kauft, der überhaupt keine Ahnung vom Programmieren hat. Programmieren ist heute so zugänglich, dass die Leute sicher zumindest schonmal ein bisschen mit Python herumgespielt haben.
Und hier sehe ich das größte konzeptionelle Problem: Im Kapitel zu Schleifen (oder ganz vielen anderen Kapiteln) wird wenig Neues stehen, wenn ich von Python oder von Java oder von Javascript komme, aber überlesen kann ich es auch nicht, da C eben doch manchmal ein wenig anders ist. Das macht dann alles sehr anstrengend, weil man sich erst einmal durch gefühlt das halbe Buch kämpfen muss, bis irgendwas kommt, das ordentliches Programmieren ermöglicht. Insofern finde ich es auch etwas problematisch, dass pointer erst ab Seite 509 eingeführt werden.
Am Umfang ist ja nichts auszusetzen, aber ich würde mir bei so einem Buch einfach erhoffen, dass es an die moderne Zeit angepasst ist; C ist dann eben auch eine Sprache, die so ziemlich alles Moderne, das irgendwie verbreitet ist, beeinflusst hat. Wenn man irgendwas davon kennt, sind einem die C-Konzepte schon einmal nicht mehr ganz fremd und das sollte man ausnutzen. Ich gehe nicht davon aus, dass es einen Sinn hat, heute ein C-Buch so aufzuziehen, als hätten die Leser noch nie programmiert. Also: Die Grundlagen ein wenig straffen und auf die Besonderheiten von C eingehen. Dafür dann das Buch ein wenig in Richtung der aktuellen Verwendungen von C erweitern, nämlich embedded und systems programming. Da würde man den Lesern einen großen Gefallen tun. Ein bisschen systems programming ist ja schon drin, aber der embedded-Aspekt mit seinen ganzen Fallstricken scheint noch überhaupt nicht beleuchtet worden zu sein. Ich würde mir außerdem wünschen, dass ein großes Augenmerk darauf gelegt wird, fremden C-Code zu verstehen. Ich denke, dass C oft genutzt werden muss, weil irgendwelcher Legacy-Code zu erweitern oder anzupassen ist. Für moderne Neuentwicklungen auf Systemen mit genügend Rechenleistung sind andere Sprachen meist zu bevorzugen, weil sie einfach deutlich weniger fehleranfällig und bequemer zu programmieren sind.
Für moderne Neuentwicklungen auf Systemen
mit genügend Rechenleistung sind andere Sprachen meist zu bevorzugen,
weil sie einfach deutlich weniger fehleranfällig und bequemer zu
programmieren sind.
Ich glaube nicht, dass das auf die Embedded-Systeme der Industrie zutrifft.
Für moderne Neuentwicklungen auf Systemen
mit genügend Rechenleistung sind andere Sprachen meist zu bevorzugen,
weil sie einfach deutlich weniger fehleranfällig und bequemer zu
programmieren sind.
Ich glaube nicht, dass das auf die Embedded-Systeme der Industrie
zutrifft.
Und die 'Fehler' "passieren" mit anderen Programmiersprachen genauso.
"Fehler bauen" ist keine Eigenschaft/Fähigkeit der benutzten Sprache sondern des Sprachnutzers aka Programmierer. Aber wer es halt bequem mag, erklärt das π gleich 3.2 sei und lässt das zum Landesgesetz erheben:
Das war also ein hinreichender Beweis, dass ich Englische Bücher lese.
Nein. Wieso eigentlich "E"nglische Bücher mit großem "E"?
Anglizismen sind nur ein Zeichen allgemeinen Sprachverfalls, und ganz und gar keine "Beweise" für das Beherrschen anderer Sprachen. Das ist nur Nachgeäffe der Fehler von anderern. Wie auch "Snack's", "Public Viewing" etc. ...
Aber für derartige Diskussionen ist das hier nicht der richtige Ort.
Ich würd das Buch kaufen.
So viele Bücher für modernes C in Deutsch gibt es nicht.
Ein bissel mehr Internas würden dem Buch noch gut tun,
etwa:
Benutzt C auch das neue Stack-System wie C++ 23,
das Funktionsaufrufe im kompilierten Programm
sehr verschnellert?
Das C inzwischen auch Metaprogrammierung macht, find
ich gut.
Lernt es von C++ auch in Punkto Optimierung?
Mich perönlich würde auch weitere Litheratur über C++23
interessieren, gerade mit volkstümlicher Erklärung der
neuen Futures wie Threads, Concepts, Ranges u.s.w.,
Futures, die C++ in der Programmgeschwindigkeit immer
mehr an Assembler heranbringt.
Das war also ein hinreichender Beweis, dass ich Englische Bücher lese.
Nein. Wieso eigentlich "E"nglische Bücher mit großem "E"?
Anglizismen sind nur ein Zeichen allgemeinen Sprachverfalls, und ganz
Komma vor und???
nur Nachgeäffe der Fehler von anderern. Wie auch "Snack's", "Public
anderern? Klein?
Allgemeiner Sprachverfall schön und gut, aber das Problem sind keine Anglizismen, sondern eher die Unlust, sich präzise ausdrücken zu wollen. Sprachen sind immer im Wandel, auch im Englischen gibt es einige Wörter, die aus dem Deutschen übernommen und--mal mehr, mal weniger--angepasst wurden. Zeitgeist, wanderlust, uber- sind einige bekannte Beispiele.
Für moderne Neuentwicklungen auf Systemen
mit genügend Rechenleistung sind andere Sprachen meist zu bevorzugen,
weil sie einfach deutlich weniger fehleranfällig und bequemer zu
programmieren sind.
Und die 'Fehler' "passieren" mit anderen Programmiersprachen genauso.
"Fehler bauen" ist keine Eigenschaft/Fähigkeit der benutzten Sprache
sondern des Sprachnutzers aka Programmierer. Aber wer es halt bequem
mag, erklärt das π gleich 3.2 sei und lässt das zum Landesgesetz
erheben:
Das ist ziemlicher Unsinn und ich hoffe, das weißt du auch.
Programmiersprachen machen keine Fehler, Menschen machen sie. Aber das ist genauso bescheuert, wie zu sagen, dass es keine unsicheren Dinge gibt, sondern nur Menschen, die sie nicht bedienen können.
Um mal ein paar Hinweise zu geben: Dinge wie bounds checking verhindern buffer overflows. Garbage collection hilft sehr dabei, Speicherlecks zu vermeiden. Das sind nur mal exemplarisch zwei features moderner Sprachen. Nun mögen immer mal wieder Leute kommen, die sich über den Performanceverlust beschweren, doch erstens ist der in der Praxis gar nicht so hoch, wie beispielsweise Rust zeigt (das hat nämlich bounds checking :), allerdings keine garbage collection, aber dafür automatische Speicherfreigabe--auch nicht verkehrt) und außerdem ist moderne Hardware schnell. Wir haben genügend Leistung, um uns Programmiersprachen leisten zu können, die minimale Mengen dieser Leistung dazu benutzen, um weniger fehleranfällige Programme sicherzustellen, weil bestimmte Fehler so nicht gemacht werden können. Mittlerweile können wir ja auch sehr gute Compiler bauen und den Leistungsverlust erträglich halten.
Nun hat C seine Berechtigung, immer noch, auch in Zukunft. Aber ich frage mich eben durchaus, ob es heute noch sinnvoll ist, ein umfangreiches Buch zu entwerfen, das sich an Programmier-Anfänger richtet und C verwendet, da C, zumindest gemessen an vielen anderen Sprachen, relativ unkomfortabel und fehleranfällig ist.
Dein Inhaltsverzeichnis ist gigantisch groß, strukturiert, aber leider
unlesbar. Ich kann da nicht schnell mit dem Auge durchscrollen.
Grenze die Ebenen voneinander stärker ab, z.B. durch Fettschrift,
Kursivschrift, dezente Färbung der Schrift oder des Hintergrunds.
Blos nicht. Vielleicht etwas mehr Einrückung, aber kein gefärbter Hinergrund (weniger Kontrast) oder verschiedene Schriftschnitte. Sowas sieht doch grausam aus. Ich verstehe nicht, wie das die Lesbarkeit verbessern soll?!
Das wäre mir zu viel Arbeit, das alles durch zu lesen.
Etwas, was eigentlich alle immer falsch machen, ist die Verwendung von inline. Das ist nämlich in C und C++ anders gelöst. Ich sehe natürlich nicht, was du dazu geschrieben hast, aber der richtige Weg ist:
Funktionen, die nur in einer Compilation Unit sind, als "static inline" im C file. Die meisten meiner Funktionen mach ich dort zwar einfach nur static, inline bringt selten was.
Funktionen, die in mehreren Compilation Units gebraucht werden, im Header mit inline definieren und ohne static. Zusätzlich in genau einer Compilation Unit im C File ein eine extern Deklaration, und der Header mit der inline Definition muss vorher eingebunden worden sein.
1
// something.h
2
inlinevoidmyfunc(void){}
3
// something.c
4
#include"something.h"
5
externvoidmyfunc(void);
Die Compilation Unit mit dem "extern void myfunc(void);" enthält nachher effektiv die Funktion. Die wird gebraucht, wenn der Compiler mal entscheidet, die Funktion nicht zu inlinen. Ist extrem einfach, zu vergessen, und muss in exakt einer Compilation Unit sein. Nicht mehr und nicht weniger.
Man kann "static inline" Funktionen auch in Header packen, aber dann hat jede Compilation Unit seine eigene, lokale Kopie, auch wenn nichts geinlined wird.
In C++ funktioniert das anders, da reicht die inline Funktion im Header. Implementationen generieren da in der regel weak symbols, jede Compilation Unit hat eine eigene Kopie, aber beim Linken wird dann halt nachher nur eine verwendet. In C kann man das mit Compiler spezifischen Attributen nachbilden.
Viele Compiler haben auch ein Attribut, um inlining zu erzwingen.
PS: Etwas tricky wird es, wenn man in 2 Headern inline Funktionen hat, die eine inline Funktion aus dem jeweils anderen braucht, aber man dem Nutzer die Möglichkeit geben will, nur eine einzubinden. Dann braucht man eine forward Deklaration mit inline. Aber manche Compiler explodieren, wenn dann die inline Definition in der selben Compilation unit nicht kommt, statt einfach das externe Symbol zu verwenden. Auch GCC, aber nur bei bestimmten Targets. Scheint wohl keiner jemals zu machen. Naja, in der Regel kann man dann einfach einen weiteren Header für diese inline Funktionen machen.
Warum ein Buch, wo es alle Infos im
Internet incl. Tutorials und Videos gibt?
Weil sich ein Buch angenehmer liest als irgendwelche Tutorials im Internet. Weil man in einem Buch auch mal an der einen oder anderen Stelle persönliche Anmerkungen machen kann, man sich Textstellen hervorheben kann. Es gibt viele gute Gründe ein Buch in die Hand zu nehmen.
Dazu bittest Du die KI einen Punkt, wie in Deinem Buch zu erklaeren. Dann vergleiche diese.
Insbesondere an den Stellen, wo die KI sich verhaut, den Punkt musst Du ausfuehrlicher darstellen.
Es gibt viele gute Gründe ein Buch in die Hand zu
nehmen.
Auf jeden Fall kann der Ordnungsaufbau hilfreicher sein - jedenfalls bei mir. So ein Buch hat ja schon (meistens jedenfalls) eine qualitative Überarbeitung. So ähnlich läuft das auch bei Lexikon-Bänden. Hier können die Überblicksartikel wesentlich lesbarer und qualitativer sein als ein Wikipedia-Artikel, wo man schon die Analogie hat, dass man wie aus einem vollen Feuerwehr-C-Schlauch Wasser trinken muss.
Das ist kein Unsinn, weil dahinter ein Konzept steht, das ernsthaft verfolgt wird. Es wird verfolgt den C-Compiler und die CISC-Prozessoren aufeinander abzustimmen.
Ein CISC-Prozessor (Complex Instruction Set Computer) ist ein Prozessordesign, das darauf ausgelegt ist, komplexe Befehle in möglichst wenigen Taktzyklen auszuführen. Im Gegensatz zu RISC-Prozessoren (Reduced Instruction Set Computer), die einfache Befehle bevorzugen.
Also 1000 Seiten liest sich wie Overkill, womöglich ist der Text mit unnötig langen Listings aufgeblasen. Will man wirklich 800 Seiten durchackern bevor man zu Bitoperationen kommt?
Auf jeden Fall würde ist das Ding in 2 Bände aufteilen:
Teil 1 für die Sprache C: Präprozessor, Schlüsselworte, Kontrollstrukturen, Ausdrücke, Funktionen, Operatoren und deren Reihenfolge, und schließlich die Libs. Und natürlich ein volständiger Index, wo man auch Zeug wie & und && findet.
Teil 2 für: Welche Compiler und IDEs gibt es, Debugger, Design-Pattern und Anti-Pattern, Profiling, Optimierung und statische Analyse, Diagnostics, Geschichte von C und Signifikanz, Lsiting erstellen und lesen, Binutils, eigene Bibliotheken erstellen, Static vs. Dynamic Linking, etc.
Erweiterungen wie OpenMP, GNU-C, Inline-Asm, Pragmas, Attribute, können auch erwähnt werden.
Zu inline: Ist zwar ein wichtiges Thema, aber für eine Einführung eher weniger geeignet. inline hat ja keinen Einfluss auf die Semantic, und die drei verschiedenen inline-Varianten zu differenzieren ist m.E. was für den fortgeschrittenen Teil zu Optimierung, wie auch Cloning, Flattening, etc.
Der Buch schneidet den Fleisch schweissfrei.
Der Buch wird niemals muede.
Ich bin froh, dass ich C mittels K&R gelernt habe, noch froher waere ich gewesen, wenn die Uebersetzung nicht so fuerchterlich grottig gewesen waere. Aber lieber grottig uebersetzte 279 Seiten als >1000.
Da wuerde ich echt mehrere Buecher/Baende draus machen.
Das ist kein Anfängerbuch. Man kann es aber dennoch durchlesen (bis auf den std-lib Anteil, ca. 220 Seiten). Für mich taugt es für Detailfragen, Nachschlagewerk, zur Auffrischung. Alles auch mit kurzen Beispielen erklärt.
Ja, aber es ist im wesentlichen eine etwas ausführlichere Ausführung des gleichnamigen Artikels des gleichen Autors, der völlig kostenlos im Interweb zu finden ist.
So, zu der Diskussion:
Hier wird über einen unbekannten Inhalt diskutiert. Man kann, wenn man will, dem TO Werbung vorwerfen. Aus Eigeninteresse ist mir das aber egal.
Aber um so mehr will ich jetzt eine Leseprobe die mehr als eine Seite lang ist.
Wie in ca. 3 Monaten (Erscheinungstermin August) ein Buch kritisiert werden kann ist mir bissl schleierhaft. Aber ich hab nur Anleitungen und paar Artikel geschrieben, keine Bücher. Und hab daher keinen Schimmer vom Verlagswesen.
Rheinwerk Verlag ist schon ein bischen berüchtigt, dass man viel Papier fürs Geld kriegt.
Ich meine... hier geht das Buch erst auf Seite 43 los, auf Seite 226 kommt dann die erste Funktion.
Insgesamt scheint die wichtigste Zielvorgabe gewesen zu sein, dass man im Regal auf Buchstützen verzichten kann.
Hier wird zuviel auf einmal versucht. Vom Hallo Welt bis in die Details von Gleitkommazahlen bis Modul- und Regeressionstests. Das schafft niemand auf einmal.
Und vorher muss ich mich durch 40 Seiten Philosophie quälen. Als ob ich einen 1000-Seiten-Wälzer überhaupt anrühren würde, wenn ich nicht schon im Vornhinein einen Grund hätte. Zumindest bei einem Sachbuch.
Das ist kein Unsinn, weil dahinter ein Konzept steht, das ernsthaft
verfolgt wird. Es wird verfolgt den C-Compiler und die CISC-Prozessoren
aufeinander abzustimmen.
Ein CISC-Prozessor (Complex Instruction Set Computer) ist ein
Prozessordesign, das darauf ausgelegt ist, komplexe Befehle in möglichst
wenigen Taktzyklen auszuführen. Im Gegensatz zu RISC-Prozessoren
(Reduced Instruction Set Computer), die einfache Befehle bevorzugen.
....
Und vorher muss ich mich durch 40 Seiten Philosophie quälen. Als ob ich
einen 1000-Seiten-Wälzer überhaupt anrühren würde, wenn ich nicht schon
im Vornhinein einen Grund hätte. Zumindest bei einem Sachbuch.
Des Autors Javabücher sind genauso aufgebaut, das ist sein Stil, mehr sage ich jetzt mal dazu nicht, sonst kommt gleich wieder der Mod und schlägt zu.
Für ein Buch, welches C-Grundlagen vermitteln soll völlig fehl am Platze. Natürlich wird sich auch so ein Grundlagenbuch bei den Codebeispielen an einem oder auch zwei Compilern orientieren. Sinnvollerweise wählt man da möglichst weit verbreitete Compiler aus. Genau deshalb verweist der TO auf den GCC und den Mikrosoftcompiler, wird aber da nicht ins Detail gehen. Sieht eigentlich am Umfang des Kapitels Werkzeuge (ca. 20 Seiten).
Eine genaue Beschreibung der Werkzeuge würde auch den Rahmen eines C-Grundlagenbuches komplett sprengen. Für die gängigsten Compiler/IDE gibt spezielle Fachbücher die es locker auf 500 Seiten und mehr bringen.
"Fehler bauen" ist keine Eigenschaft/Fähigkeit der benutzten Sprache
sondern des Sprachnutzers aka Programmierer. Aber wer es halt bequem
mag, erklärt das π gleich 3.2 sei und lässt das zum Landesgesetz
erheben:
Das ist ziemlicher Unsinn und ich hoffe, das weißt du auch.
??? Wenn's Unsinn wäre , hätt ich es als solchen markiert, wenn es offensichlich wäre.
Wir haben genügend Leistung, um uns
Programmiersprachen leisten zu können, die minimale Mengen dieser
Leistung dazu benutzen, um weniger fehleranfällige Programme
sicherzustellen, weil bestimmte Fehler so nicht gemacht werden können.
Mittlerweile können wir ja auch sehr gute Compiler bauen und den
Leistungsverlust erträglich halten.
Ja, die Hoffnung stirbt zuletzt.
Nun hat C seine Berechtigung, immer noch, auch in Zukunft. Aber ich
frage mich eben durchaus, ob es heute noch sinnvoll ist, ein
umfangreiches Buch zu entwerfen, das sich an Programmier-Anfänger
richtet und C verwendet, da C, zumindest gemessen an vielen anderen
Sprachen, relativ unkomfortabel und fehleranfällig ist.
C ist eben mit großen Abstand die verbreiteste Programmiersprache. Und C ist relativ einfach zu bändigen, siehe MISRA-C etc.. Jetzt einfach als blutiger Rookie auf eine Sprache setzen weil sie als sicherer und als performanter gilt, ist mindestens trügerisch. Jede Sprache /Technik ist fehleranfällig, wie tschernobyl eindrucksvoll bewies, insbesonders wenn man vom Gegenteil ausgeht und mit dem Hammer draufkloppt in dem blinden Vertrauen das schon nichts schiefgeht. Besser statt einfach drauflos hacken und hoffen das
die Sprache schon jeden Mist abfängt ist sich von Anfang bewusst zu sein, das man Fehler hackt und das man sich Tests einfallen lassen muss un diese zu entdecken. Aus Fehlern lernt man.
Hinzu kommt der Reifegrad der Entwicklungsumgebung, bei der Qualifikation von Compilern für sicherheitskritischen Anwendungen schaut man sich eben auch die Release Notes der vergangenen Jahre an. Und siehe da, bei allen Compilern findet sich in den ersten 10 Jahren noch massiv Dreck und Freie Software scheint diese Probs noch verstärkt anzuziehen: https://www.heise.de/news/Linus-Torvalds-wettert-gegen-Compiler-Collection-GCC-4-9-2268920.html
TCC not only supports ANSI C, but also most of the /new/ ISO C99
standard and many GNUC extensions including inline assembly.
"new". Ja.
Ja, man kann auch heute mit einem Compiler zurechtkommen, der im wesentlichen nur C89 unterstützt, nur wird man, wenn man fremden Code verwenden will, der aus irgendwelchen Gründen für einen dieser neumodischeren Hipstercompiler geschrieben wurde, Probleme bekommen.
"Fehler bauen" ist keine Eigenschaft/Fähigkeit der benutzten Sprache
sondern des Sprachnutzers aka Programmierer. Aber wer es halt bequem
mag, erklärt das π gleich 3.2 sei und lässt das zum Landesgesetz
erheben:
Meinte ein Kollege vor Jahren in der Projektgruppe:
"Das ist ja eine Syphillis-Arbeit!"
Der Kollege litt wahrscheinlich als Kind unter Sigmatismus. Da hat man ihn bei einer Sprachtherapie mühsam eingepaukt, dass er nicht "Schischipusch" sagen soll. Hat er da dann ja auch immer schön vermieden. :-)
Wäre im Jahr 2026 ein Rust Buch nicht zeitgemäß? Was soll der 1000 Seiten Schicken kosten? 80 bis 120 €? Gibt es wenigstens ein pdf dazu, womit man den KI Agenten füttern kann?
Das Torvaldsinterview ist aus dem Jahr 2014 und in Compilerversion GCC 4.9. GCC gibt es schon noch länger und es wäre interessant, ob Torvalds das immer noch als Mist bezeichnet
Und vorher muss ich mich durch 40 Seiten Philosophie quälen. Als ob ich
einen 1000-Seiten-Wälzer überhaupt anrühren würde, wenn ich nicht schon
im Vornhinein einen Grund hätte. Zumindest bei einem Sachbuch.
Ach herrje, etliche Standardwerke in einen gut sortierten Fachregal haben die 1000-Marke geknackt, Beispiele:
Rothammel, Antennebuch: 1502
ARRL Handbook 2018: 1280 pages
Zeitdiskrete Signalverarbeitung ca. 1050 seiten.
PC Hardwarebuch, 1320 Seiten
Algorithmen von Sedgewick hat zwar nur 992 ist aber auch ein Beispiel das man Qualität/Grundlagenwissen nicht an der Seitenzahl messen. Obwohl, einem der mault, das er keine hunderte Seiten Programmiersprachenlehrbücher nutzen mag, könnte man ein gepflegtes "Nur Idioten prahlen mit ihren klaffenden Wissenslücken" an den Kopf knallen.
Der hat ja
wirklich kein Blatt vor den Mund genommen und die Bücher ziemlich
zerlegt. Genau diese Art von präziser, kritischer Rückmeldung finde ich
interessant, aber im Vorfeld und nicht, wenn das Kind schon in den
Brunnen gefallen ist.
Ich habe nur gelesen was im ersten Kapitel stehen soll.
Was glaubst du wie viele das lesen wollen, wenn sie schon andere C-Bücher hinter sich haben?
Ich möchte das nicht einmal kostenlos lesen.
Karl Heinz Buchegger hätte ein Buch schreiben sollen und ich hatte ihn immer dazu aufgefordert, aber er wollte einfach nicht.
Er konnte alles und mit wenigen Worten klar erklären.
Nicht jeder der etwas gut kann, kann auch gut erklären und erst recht keine Bücher schreiben.
Diese Beweggründe warum jemand noch ein C-Buch schreibt, das interessiert wohl die wenigsten. Sie kaufen ein Buch, weil sie die Sprache lernen wollen und nicht weil sie die Beweggründe und Danksagungen der Autoren lesen wollen.
Wie die Festlegung der Lichtgeschwindigkeit auf exakt 299792458 m/s
Da hat man sich wirklich keinen Gefallen getan, einer fundamentale Größe wie der Lichtgeschwindigkeit einen Wert mit 9 gültigen Stellen zu geben, der von den mehr oder weniger zufälligen, aktuellen Abmessungen und aktuellen Rotationseigenschaften eines gravitativ zusammengehaltenen Aschehaufens, 4,543 Mrd. Jahre nach seiner Kollision mit einer ebenso zufälligen anderen Zusammenballung von Materie, bestimmt ist.
Da hat man sich wirklich keinen Gefallen getan, einer fundamentale Größe
wie der Lichtgeschwindigkeit einen Wert mit 9 gültigen Stellen zu geben,
der von den mehr oder weniger zufälligen, aktuellen Abmessungen und
aktuellen Rotationseigenschaften eines gravitativ zusammengehaltenen
Aschehaufens, 4,543 Mrd. Jahre nach seiner Kollision mit einer ebenso
zufälligen anderen Zusammenballung von Materie, bestimmt ist.
Ist die Lichtgeschwindigkeit im Vakuum nicht eine gegebene, universelle Konstante, und der Meter ist so definiert worden, dass dieser Wert rauskommt?
das man Qualität/Grundlagenwissen nicht an der Seitenzahl messen.
Code Complete hat auch > 900 Seiten und ich habe es über wenige Jahre fast komplett mit Gewinn und Genuss gelesen. Die einzelnen Kapitel von 10 oder 20 Seiten (oder auch mal 50) beleuchteten einen Aspekt tief und breit. Ich konnte es irgendwo aufschlagen, 3 Sätze lesen und war gefangen, das ganze Kapitel zu studieren. Ein Tietze Schenk ist da ähnlich, Rothammel glaube ich auch, verstehe ich nur zu wenig von.
Das Inhaltsverzeichnis des TO suggeriert allerdings, dass er das Stichwortverzeichnis eines C-Nachschlagewerks zugrunde gelegt hat und zu jedem ein paar Sätze geschrieben hat, verpackt in "seine" Philosophie. Das ist zwar nicht fair, aber zerstreut es auch nicht. Weder per Leseprobe oder Infos zu Anspruch, Zielgruppe oder didaktischem Aufbau des Buches.
Da hat man sich wirklich keinen Gefallen getan, einer fundamentale Größe
wie der Lichtgeschwindigkeit einen Wert mit 9 gültigen Stellen zu geben,
der von den mehr oder weniger zufälligen, aktuellen Abmessungen und
aktuellen Rotationseigenschaften eines gravitativ zusammengehaltenen
Aschehaufens, 4,543 Mrd. Jahre nach seiner Kollision mit einer ebenso
zufälligen anderen Zusammenballung von Materie, bestimmt ist.
Ist die Lichtgeschwindigkeit im Vakuum nicht eine gegebene, universelle
Konstante, und der Meter ist so definiert worden, dass dieser Wert
rauskommt?
Und Lichtgeschwindigkeit ist "überall" verfügbar, ganz im Unterschied zum Urmeter unter Glas im Panzerschrank in Paris, von dem nur eher selten Kopien gezogen und abgeglichen werden. Und das die Lichtgeschwindigkeit wirklich konstant und anbhängig vom Planeten ist, hat man in Potsdam schon vor hundert Jahren rausgefunden:
Und Lichtgeschwindigkeit ist "überall" verfügbar, ganz im Unterschied
zum Urmeter unter Glas im Panzerschrank in Paris, von dem nur eher
selten Kopien gezogen und abgeglichen werden.
Warum auch. Das Ding in Paris hat seit ewigen Zeiten nur noch historischen Wert.
Weil die Programmiersprache 'C' von der Programmiersprache 'B'
abgeleitet ist, und c von "celeritas" (lat. Schnelligkeit) .
Stand aber anders bei K&R.
Da stand ziemlich lapidar, wenn ich mich nach über 30 Jahren (oder eher 40 Jahren) richtig erinnere, weil C nach B kommt und keine weiteren Erläuterungen.
Leider habe ich das Buch nicht mehr.
Weil die Programmiersprache 'C' von der Programmiersprache 'B'
abgeleitet ist, und c von "celeritas" (lat. Schnelligkeit) .
Stand aber anders bei K&R.
Da stand ziemlich lapidar, wenn ich mich nach über 30 Jahren (oder eher
40 Jahren) richtig erinnere, weil C nach B kommt und keine weiteren
Erläuterungen.
Leider habe ich das Buch nicht mehr.
Hehe, ich hab noch die Sekundärliteratur von 1987 (ISBN: 3-341-00287-1), anbei der Scan der relevanten Seite (da wird noch als Zwischenschritt BCPL erwähnt).
Vielleicht wollten K&R die Vorarbeiten von Thompson nicht gesondert hervorheben.
Hi Bruder,
wo kann ich dein Buch runterladen bitte?
Und wieder ein Gewerbe die durch Raubkopierer in den Orkus getrieben wird.
Gute Fachliteratur findet man heutzutage nur noch im Antiquariät, es trägt sich finanziell nicht mehr als Autor tätig zu sein.
Gute Fachliteratur findet man heutzutage nur noch im Antiquariät,
Das war früher aber auch schon so, ganz unabhängig von "C in 21 Tagen" und ähnlichen Internetscherzen. Dank K&R wissen wir auch, dass man zum C-Lernen ruhig einen 5-Jahres-Plan einrichten sollte ;) - Zwischenstationen sind aber die bekannten 8 Wochen oder die 2 Jahre.
Gute Fachliteratur findet man heutzutage nur noch im Antiquariät, es
trägt sich finanziell nicht mehr als Autor tätig zu sein.
Gut ist was sich verkauft. Ullenboom haut ein Buch nach dem anderen raus, das macht der sicher nicht, wenn es sich nicht lohnen würde und vor allem nicht für den Verlag. Wenn ein Autor Unverkäufliches abliefert ist der schnell weg vom Fenster.
Heutzutage schreiben sich Bücher mit KI-Support wesentlich besser. Bald sind Autoren obsolet. Menschen bald auch. Die Erde braucht den Dreck nicht. Die Erde, die Tiere, die Insekten und die Pflanzen können auch gut oder sogar besser ohne. Zum kotzen bitte vorher aussteigen! :)
Mit rund 1000 Seiten wird das Buch ganz schön schwer. Soviele Seiten schafft heute keiner mehr.
Immer weniger Menschen lesen Bücher, da soziale Medien und Streamingdienste die Aufmerksamkeit dominieren. Besonders bei jüngeren Generationen (Gen Z) wird über Schwierigkeiten berichtet, sich auf längere Texte zu konzentrieren, was oft zu weniger Lesekompetenz und geringerer Ausdauer führt. Über 6 Millionen Menschen in Deutschland lesen kaum noch, während viele junge Menschen Schwierigkeiten haben, ganze Bücher zu lesen.
Wie soll man über dein neues C-Buch ehrliche Kritik ausüben ohne es
gelesen zu haben sag mal Bruder?
Der Threadstarter hat das Procedere erläutert, und denen, die sich ihm gegenüber in angemessener Weise vorgestellt haben, Material zum Lesen zur Verfügung gestellt.
Deine Frage hier zeigt, daß das mit dem Lesen nicht Deine Primärqualifikation ist, denn sonst hättest Du diese "Frage" nicht stellen müssen.
Als Schriftsteller solltest du (korrekt) zitieren.
Wäre auf jeden Fall schon mal ein Minimum des gefragten Handwerks. Nun ist ein C-Programmier-Buch kein wissenschaftliches Buch. Aber ein Familienroman (https://de.wikipedia.org/wiki/Homo_faber_(Roman)) eigentlich auch nicht. Üblicherweise hilft es ja beim Lernen, wenn man gewisse andere Hintergründe "jonglieren" kann - Beispielsweise kann man beim Speichermanagement oder mit dem Stackframe sehr durcheinander kommen - es hilft aber auch, wenn man z.B. mit Zahlenformaten zu tun hat, von mir auch mit Beweisen, und diesbezüglich ein Instrument zum Zahlen untersuchen nutzen kann und - wie z.B. die Mengenlehre - parat hat. Es stört in diesem Zusammenhang auch nicht, sich mit Signalschaltungen oder mit FSGs oder von mir aus auch mit Linux-Kernelprogrammierung zu beschäftigen. Nochmal - das mit den Lernen ist schon komplex - da kann man von der anderen Seite (also von einem Buchautor) schon gewisse Sorgfalt beim Übertragen von Informationen erwarten.
Wer sich für den Originalbeitrag interessiert, auf den ich mich bezogen
habe: Beitrag "Sind alle C-Bücher wirklich so schlecht?"
Hier wäre nochmal einer der merkwürdigeren Hinweise aus dem Thread:
Karl H. schrieb im Beitrag #3536197:
Alleine durch das selber tippen müssen erreicht man einen bewusstes und
gewolltes "du musst auf alle Details achten", die einem ein Copy&Paste
nie geben kann.
Das ist ja vor allem am Anfang auch wichtig - oder für mich waren anfangs auch Papier und Bleistift hilfreich - und sei es nur, beispielsweise ein kleines C++ Programm in eine andere Sprache zu übersetzen. Das geht zwar mit Papier und Bleistift überraschend gut - aber eigentlich meinte ich am Anfang auch die Schwierigkeiten mit dem Verständnis der Zahlenformate. So ist mir aufgefallen, das man einige Programme mit Fließkommazahlen auch mit Integerzahlen umsetzen kann - hängt aber auch von der Mathematik im Programm ab. Auf jeden Fall: Kann wirklich Spaß machen. Letztlich helfen darüberhinaus auch gute Rätselfragen. Das hilft u.a. auch, bei entsprechend schwierigen Angelegenheiten wie Parallel-Programmierung die Konzentration aufrecht zu halten. Um so besser, wenn die Rätselsachen mit etwas Humor daherkommen.
Was auch am Anfang sehr hilfreich ist, das wäre ein Fehler-Protokoll - wo man alle gemachten oder gelernten Fehler einträgt - das hilft enorm, die selben Fehler nicht noch 50 mal erneut zu machen.
Und die deutsche Ausgabe war in gleich mehrerer
Hinsicht grauenerregend
Gut dass du das schreibst!
Damals war es doch als "das C-Buch" (nur weil es von den Erfindern war?) beschrieben.
Ich hatte sofort Augenkrebs beim Lesen.
Die zweite Ausgabe von 1989 behandelte das damals "ANSI-C" genannte C89,
und war deutlich besser übersetzt und auch gesetzt.
So isses. Und daher wurde die auch immer empfohlen.
Ja, Hilfe! Die hab' ich hier seit "damals" im Regal. Und da ist immer die Rede von Vektoren, wenn eigentlich Arrays gemeint sind, von Binder und Bindung, wenns um Linker und dessen Taetigkeit geht und von uebersetzen und Uebersetzern, wenns eigentlich um compilieren/Compiler geht.
Das sind nur die 3 Beispiele, die sich mir im Kopp auf ewig festgesetzt haben. Davon gibt's sicher noch einige mehr.
Und die soll deutlich besser uebersetzt sein? Eieiei!
Gut, dass ich nicht die erste Ausgabe hier habe.
Vorher hatte ich von "C. Schirmer - Die Programmiersprache C" - Hab' ich in noch schlechterer Erinnerung. Das sah schon vom Druckbild her so aus, als waere es auf einem C64 mit Nadeldrucker in "Near-Letter-Quality" entstanden :-) und war iirc damals die Empfehlung vom Programmierlernvorlesungsprof.
Kann aber für Anfänger Probleme machen mit älterem Code der sich mit C23 nicht mehr ohne Fehler übersetzen lässt. Ob das alles in dem Buch sauber erklärt wird ist aus dem wenigen was bekannt ist nicht zu ersehen.
C wird üblicherweise in embedded Umgebungen eingesetzt und ob Keil, IAR, Segger und die GCC Derivate alle C23 unterstützen ist auch fraglich.
Wirklich neu sind in C23 compile time konstanten "constexpr" aber nur für Objekte.
Vorher? Nachher? Auf dem Einband scheint es so als wäre C. Schirmer die
Nachbearbeitung (3. Auflage) von K&R (2.Auflage) .
Ziemlich sicher vorher. Vom Schirmer hab' ich auch die 2. Auflage hier,
nicht die dritte.
OK, guter Hinweis, da ist die optische Ähnlichkeit rein verkaufsfördernd gedacht, nicht auf inhaltliche Kontinuität hinweisend. Könnte man glatt verwechseln.
Das sah schon vom Druckbild her so aus,
als waere es auf einem C64 mit Nadeldrucker in "Near-Letter-Quality"
entstanden :-)
Noch wie mit troff und nroff gesetzt ... ja so war es damals mit der Literatur aus dem "Akademischen Umfeld der Informatik".
Da hatte man nicht die Zeit als Doktorand o.ä. und als Lektor nicht den Bock das einer Gutenberg-Bibel ästhetisch gerecht zu machen. Auch wenn es schon als die "C-Bibel" bezeichnet wird.
Noch wie mit troff und nroff gesetzt ... ja so war es damals mit der
Literatur aus dem "Akademischen Umfeld der Informatik".
Dabei gab es damals schon TeX und LaTeX (ersteres seit 1978, letzteres
seit 1984).
Brian Kernighan hat auch die in 2023 erschienene 2. Aufl. von "The AWK Programming Language" ( https://awk.dev/ ) in groff gesetzt.
"Today, my use of groff is entirely for books. Most recently, I have done a second edition of the original Awk book with Al Aho and Peter Weinberger; that should appear in a couple of months. I also did a second edition of Understanding the Digital World, and the Unix: A History and a Memoir three or four years ago. All groff."
https://technicallywewrite.com/2023/06/01/groff
Wenn im Buch nur einfache Formeln und Tabellen vorkommen, spricht auch nichts dagegen. Da braucht es LaTeX nicht unbedingt.
Brian Kernighan hat auch die in 2023 erschienene 2. Aufl. von "The AWK
Programming Language" ( https://awk.dev/ ) in groff gesetzt.
Brian Kernighan ist mit jetzt 84 Jahren älter als unser Altersstarrsinnspräsident, da kann man ihm nachsehen, daß er einfach das nimmt, was er im Schlaf kennt.
Und letztlich -- heute verwendet man halt markdown.
Um noch mal zum Buch von Christian zurück zu kommen.
Ich bevorzuge ganz eindeutig diese 1000 Seiten Bücher, ideal, wenn jedes Thema von etlichen Seiten beleuchtet wird.
Leute die Bücher nicht verstehen, denken sie müssten alles davon lesen, aber tatsächlich ist es möglich, ein Thema vorzeitig zu überblättern, wenn man sich sicher ist, es verinnerlicht zu haben.
Das Inhaltsverzeichnis sieht schon mal super aus
Und der MArkt ist sicher für C und C++ gegeben, auf das was hier im Forum erzählt wird, darf man sowieso nichts geben.
Finde es schon sinnlos hier so eine Frage zu stellen.
Egal was du da ins Buch schreibst, NIEMALS wird es hier einen Konsens geben, never ever.
Ich würde Kritik von hier, komplett ignorieren.
Ist es denn das hier?
https://www.rheinwerk-verlag.de/c-programmieren-das-umfassende-handbuch/
Dann habe ich soagr schon ein Buch von dir:-)
Um noch mal zum Buch von Christian zurück zu kommen.
Ich bevorzuge ganz eindeutig diese 1000 Seiten Bücher, ideal, wenn jedes
Thema von etlichen Seiten beleuchtet wird.
Leute die Bücher nicht verstehen, denken sie müssten alles davon lesen,
aber tatsächlich ist es möglich, ein Thema vorzeitig zu überblättern,
wenn man sich sicher ist, es verinnerlicht zu haben.
Ich mag lieber ein umfangreiches Buch vor mir haben und Stellen überspringen, die einen nicht interessieren, oder darauf später zurückkommen. Aber jeder lernt anders. Man wird nicht gezwungen, in einem 1000-Seiten-Buch jede Seite auch wirklich zu lesen. Für mich ist ein Buch eine Sammlung von Themen, die der Autor didaktisch aufbereitet hat. Viele interessieren sich für die Geschichte einer Programmiersprache, andere wiederum finden das langweilig. Außerdem lerne ich ganz gerne auch an Beispielen, und deswegen gibt es in dem Buch viele Beispiele, die jeweils unterschiedliche Aspekte von C beleuchten.
Das Inhaltsverzeichnis sieht schon mal super aus
Und der MArkt ist sicher für C und C++ gegeben, auf das was hier im
Forum erzählt wird, darf man sowieso nichts geben.
Der Markt wird es letztendlich entscheiden. Wenn mein Buch Mist wird und es keiner kauft, verschwindet es wieder vom Markt. Wenn mein Buch weniger schlecht ist als die anderen, überlebt es.
Genau richtig. Die Seite habe ich auch noch nicht gesehen. Das ist neu.
Dann bist du also der Autor vom legendären Java-Insel-Buch? Boah ey, Respekt alter, Wow!!.
Wäre eigentlich nett (Wunschliste ;)) wenn ein wenig mehr gcc-asm-inline mit drin wäre, denn da gibt es auch eher wenig oder eher unstandarsierte oder didaktische Hilfe (https://sys.cs.fau.de/lehre/ss22/bst/uebung/doc/extern/gcc-inline-assembly.html). In einem Reiner Backer-Buch hinsichtlich DOS-Asm stand auch sehr schön beschrieben, wie die Asm-Übergaben bei C und Pascal organisiert waren. Darüberhinaus war das auch hinsichtlich anderer Zusammenhänge ein sehr gutes Nachschlagebuch für die Asm-Programmierung.
Das hier ist auch hilfreich: https://download-mirror.savannah.gnu.org/releases/pgubook/ProgrammingGroundUp-1-0-booksize.pdf
https://tutego.de/de/docs/c/Von_C_zu_Assembler.html ist das, was ich zum Thema C und ASM für das Buch vorbereitet habe, aber letztlich nicht aufnehmen konnte, weil das Buch jetzt schon zu dick ist. Also ist es jetzt ausgelagert und vielleicht noch für irgendjemanden interessant.
https://tutego.de/de/docs/c/Von_C_zu_Assembler.html ist das, was ich zum
Thema C und ASM für das Buch vorbereitet habe, aber letztlich nicht
aufnehmen konnte, weil das Buch jetzt schon zu dick ist. Also ist es
jetzt ausgelagert und vielleicht noch für irgendjemanden interessant.
Das ist aber auch ein Top-Down-Text. Assembler lernt man besser mit Bottom Up. Ich hatte mal überlegt, warum es viel Kritik bei den C-Programmier-Büchern gibt. Früher gab es ja viele Basic- und Pascal-Lehrgänge. Oder hier und da:
http://www.henning-thielemann.de/CHater.html (naja, modula3..schade eigentlich) (wollte ich mal mit Asm hinbekommen) - Früher waren die Zeitschriften auch voll mit Pascal- oder Basic-Code - C war schon bekannt - aber hier eher weniger im Gang. Erst in neuerer Zeit kam die C-Programmierung in Gang (so Anfang der 90er vielleicht) - C war auch schon früher bekannt - aber nicht wirklich im Vordergrund - aus dieser Sicht ein Nischenprodukt wie Linux. So denke ich mal, dass einfach weniger Drumherum darum ist. Und deswegen ist auch die Motivation schwierig, weil man erstmal über vieles nachdenken muss. Man sollte sich auch gewisse Ziele setzen - und mal versuchen, mit dem zurechtzukommen, was man vor sich liegen hat. Andererseits: hinsichtlich der Ausblicken in den Kapiteln im Buch: Ein kleines Tutorial zum Selber Denken (wegen der Motivation) dann noch ein kleines Tutorial zur Lambda-Nutzung und dann noch ein kleines Tutorial zum MC-Einstieg. Die MC-Bücher reichen eigentlich auch schon oft, um mit der Programmierung zurechtzukommen.
Andere Sachen im Inhaltsverzeichnis gehören eigentlich auch eher in ein Rust-Buch ;) oder in die Compiler-Dokumentation.
Andere Frage: Hast du die Kapitel auch einzeln parat?
Andere Frage: Hast du die Kapitel auch einzeln parat?
Es gab ja ein paar Nachfragen, ob ich die Kapitel hochladen oder allgemein verfügbar machen kann. Kurz gesagt: Nein, das geht nicht. Die Rechte liegen beim Verlag, und öffentliche Verbreitung wäre keine gute Idee.
Ich habe C gelernt mit K&R, und gemäß "learning by doing"
gleich beim Verstehen des Unix V6-Kerns auf unserer PDP-11
anwenden können, der Prüfungsfach war.
Das war der Anfang einer langen Freundschaft, schon gerade
nachdem man uns davor mit Elan (educational language) gequält
hat. Die Sprache für alle, denen Algol-68 zu wortkarg war.
Ich könnte mir vorstellen, das sowas wie
"VHDL-2008 - Just The New Stuff", nur halt für C ganz
interessant wäre. Die ollen Kamellen lenken nur ab.
Stand aber anders bei K&R.
Da stand ziemlich lapidar, wenn ich mich nach über 30 Jahren (oder eher
40 Jahren) richtig erinnere, weil C nach B kommt und keine weiteren
Erläuterungen.
Leider habe ich das Buch nicht mehr.
Hehe, ich hab noch die Sekundärliteratur von 1987 (ISBN: 3-341-00287-1),
anbei der Scan der relevanten Seite (da wird noch als Zwischenschritt
BCPL erwähnt).
Vielleicht wollten K&R die Vorarbeiten von Thompson nicht gesondert
hervorheben.
Nein. K&R kann man sowas nicht vorwerfen. Das hier ist Seite 1
nach den Vorworten aus der Original-V2 "Ansi C" 1988.
Gesetzt übrigens mit ( pic | tbl | eqn | troff -ms )
auf einer VAX unter Unix V9.
Der Hauptjob der kleinen Truppe bei Bell war wohl eher die
Chips-Bäckerei.
Der Weinberger aus awk (Aho, Weinberger, Kernighan) hat an seinen
Weinberger-Arrays geforscht, so etwas wie ein PAL.
Der yacc hatte seine erste Funktion zur Konstruktion von Schaltwerken
/ Zustandsautomaten.
Andere Frage: Hast du die Kapitel auch einzeln parat?
Es gab ja ein paar Nachfragen, ob ich die Kapitel hochladen oder
allgemein verfügbar machen kann. Kurz gesagt: Nein, das geht nicht. Die
Rechte liegen beim Verlag, und öffentliche Verbreitung wäre keine gute
Idee.
Du möchtest Kritik für dein Buch und bietest ein nacktes Inhaltsverzeichnis.
Du hättest ja wenigstens zu einigen (wichtigen) Überschriften für uns hier einen kurzen Satz dazu schreiben können um was es geht.
Fast jede Seite hat eine eigene Überschrift da fragt man sich wie tief es wohl darin geht. Es sei denn du nutzt Buchstaben die man nur mit der Lupe lesen kann ;-). Von Beispielen, aus der Praxis, auch kein Spur ...
Für mich wäre ein Buch lesenswert das Probleme aus der Praxis und Lösungen in "C" dazu anbietet und nicht schon wieder die Geschichte von C erzählt oder wieviel Compiler es gibt und wie man die installiert. Das wirkt doch wie Füllstoff um auf 1000 Seiten zu kommen.
Du kannst ja mal den Text von "Über den Autor" hier posten, da kann der Verlag ja nichts dagegen haben.
Mich würde schon interessieren wieviel Praxis Erfahrung du mit "C" hast.
Was stört dich am Inhaltsverzeichnis?!
Das ist doch super so gelöst, hatte er beim Java Buch genauso gemacht(Siehe LEseprobe), da kannst du doch nachlesen ab Seite 5, wie tief er die einzelnen Themen behandelt hat...da hat er nur nicht den Fehler gemacht, vorher hier zu fragen..
https://www.amazon.de/Java-auch-eine-Insel-Programmierer/dp/3367111341/ref=sr_1_1
Und du kannst an dem hier im Forum zur Verfügung gestelltem Inhaltsverzeichnis doch immerhin welche Themen alles behandelt werden und ob deiner Meinung nach was wichtiges fehlt...
Hier steht "Über den Autor, sein Schwerpunkt ist wohl Java
einem Buch geht nie der Strom aus, es scheitert nur am Gepäcklimit bei
Flugreisen und am Tragekomfort auf Reisen.
Wie soll man denn ohne Strom programmieren? Nur Buch lesen? Zapperment!
Nun, man muss ja nicht alles, was man ließt, sofort auch als Programm umsetzten.
Das wird zwar oft didaktisch proklamiert, um die Leute mit Erfolgserlebnissen bei der Stange zu halten, hat aber den Nachteil, dass das grundlegende Verständnis, die Philosophie eines Vorgehens oder eines Algorithmus vernachlässigt wird.
Die Syntax oder die spezielle Bibliothek bzw. API, die man kennen muss, sind in zwei bis fünf Jahren veraltet, die Idee dahinter aber noch lange nicht.
Unter diesen Umständen ist es halt auch wichtig, dass man sich den ganzen Kram durchließt und darüber nachdenkt, ohne es sofort als Programm umzusetzten.
Warum ein Buch, wo es alle Infos im
Internet incl. Tutorials und Videos gibt?
Ok, jetzt mal konkret weniger speziell auf "Buch" als auf "Tutorial" als Text (könnte man sich ja Ausdrucken lassen) vs. Video:
Videos erschweren das sich Konzentrieren und Reflektieren. Ich Spule bei Videos ständig hin und her, weil ich etwas mitkriegen möchte, was ich nicht so genau akustisch oder optisch mitbekommen habe. Und in vielen Fällen hatte ich auch den Verdacht, ich sollte etwas nicht mitbekommen. ;O)
Dieses hin und her Springen, Vergleichen und Reflektieren funktioniert mit Text wesentlich leichter als mit Audio oder Video. Zudem kann mich ein Sprecher weniger versuchen, mich durch seine Art und Weise zusätzlich zu manipulieren.
Die geringere Geschwindigkeit und das häufigere Wiederholen kommt übrigens auch dem Lernen, speziell dem Übergang vom Kurzzeit- ins Langzeit Gedächnis zu gute.
Was stört dich am Inhaltsverzeichnis?!
Das ist doch super so gelöst, hatte er beim Java Buch genauso
gemacht(Siehe LEseprobe), da kannst du doch nachlesen ab Seite 5, wie
tief er die einzelnen Themen behandelt hat...da hat er nur nicht den
Fehler gemacht, vorher hier zu fragen..
https://www.amazon.de/Java-auch-eine-Insel-Programmierer/dp/3367111341/ref=sr_1_1
Und du kannst an dem hier im Forum zur Verfügung gestelltem
Inhaltsverzeichnis doch immerhin welche Themen alles behandelt werden
und ob deiner Meinung nach was wichtiges fehlt...
Ich habe weiter oben schon mal das hier verlinkt:
https://en.cppreference.com/c/23
Da kannst du selber nachlesen was davon im Inhaltsverzeichnis vorkommt ...
Hier steht "Über den Autor, sein Schwerpunkt ist wohl Java
Eben ... und das ist eine andere Insel wie "C"amelot island Ontario ;-)
oje, und jetzt denkst du, dann kann er sich in C ja nicht gut auskennen?!
Dann solltest du mal etwas mehr über seinen Hintergrund lesen.
Ich denke nicht, das er in dem Punkt abstinken wird
Glaube ich nicht. Er kennt das Forum, und weiß, dass sich die meisten
Autoren hier mit solchen Versuchen ins eigene Knie schießen.
Nicht ganz, denen wird von Dritten ins Knie geschossen, resp. denen gibt man nur "Sch... zu Fressen".
Der Hauptjob der kleinen Truppe bei Bell war wohl eher die
Chips-Bäckerei.
Der Weinberger aus awk (Aho, Weinberger, Kernighan) hat an seinen
Weinberger-Arrays geforscht, so etwas wie ein PAL.
Der yacc hatte seine erste Funktion zur Konstruktion von Schaltwerken
/ Zustandsautomaten.
Interessantes Detail, war mir nicht so bekannt. Passt aber zu dem Anwendungsszenarion von Unix damals. Da ging es weniger um reine Programmierung in C oder irgendwas sondern um die Nutzung von (wissenschaftlich/technischen) Anwendungen aus dem Bereich Maschinelles Rechnen" darunter eben EDA ("Electronic design automatisation")
und CAD-Pakete (FEM und so), was eben auf "workstation/ main frames lief.
Das man dazu auch PC nutzen könnte, die eher aus der Linie "Terminal" entstand, daran konnten die genannten Herren damals noch nicht denken.
Embedded und C dürften die auch noch nicht gekannt haben.
Fast jede Seite hat eine eigene Überschrift da fragt man sich wie tief
es wohl darin geht. Es sei denn du nutzt Buchstaben die man nur mit der
Lupe lesen kann ;-). Von Beispielen, aus der Praxis, auch kein Spur ...
Das ist tatsächlich ein Problem, wenn man Bücher schreibt und viele Themen sich mit wenigen Sätzen abhandeln lassen.
Viele Autoren machen dann aus den einzelnen Themen Kapitel, damit sie über das Inhaltsverzeichnis gefunden werden können, aber ich persönlich fände es besser, diese "Kurzkapitel" zu in passenden Themenkapiteln zusammenzufassen.
Dann tauchen sie nicht mehr im Inhaltsverzeichnis auf. Günstig wäre aber dann ein guter Schlagwortindex.
Für mich wäre ein Buch lesenswert das Probleme aus der Praxis und
Lösungen in "C" dazu anbietet und nicht schon wieder die Geschichte von
C erzählt oder wieviel Compiler es gibt und wie man die installiert. Das
wirkt doch wie Füllstoff um auf 1000 Seiten zu kommen.
Für mich wäre ein C-Buch interessant, in dem auch die ganzen Konventionen und Abkürzungen, die es in C, und C++ gibt, explizit beschrieben werden.
Ebenso explizit die Arbeit mit Bibliotheken und die Toolchain, die benötigt wird.
Beispiele sind wichtig, aber die Philosophie im Hintergrund ist auch wichtig. Sonst mache ich nur Beispiele erweitert nach, ohne alles verstanden zu haben.
Bei kommerziellen Sachbüchern ist der Autor oft in einem Dilema:
Er muss, um Kunden zu finden, so schreiben, dass die Kunden meinen ihre Probleme würden damit gut abgedeckt.
Da er ja schlecht alles zur Einsicht veröffentlichen kann, weil dann ja keiner mehr kaufen würde, muss er um einen Überblick zu geben, dass Inhaltsverzeichnis veröffentlichen.
Bei meiner oben Beschriebenen Alternative müsste er aber stattdessen das Indexverzeichnis veröffentlichen.
Damit kann er aber wenig Eindruck machen, und darum wird so geschrieben wie es aktuelle Praxis ist.
Abgesehen kann kein Autor, der über einen Verlag veröffentlicht, wirklich frei Schreiben: Er ist schon irgendwie an die Wünsche und Vorstellungen eines Verlegers gebunden.
D.H. Sachbuchautoren schreiben in erster Linie für ihren Verleger und in zweiter Linie erst für dass, was ihre Zielgruppe meint zu wünschen.
Ob das den tatsächlichen Bedürfnissen ihrer Leser entgegenkommt...keiner weiss es, weil das auch die Leser erst NACH der Lektüre UND praktischen Erfahrungen wissen können.
Eigentlich würde ich gerne Sachbücher lesen, wo der Autor frei Schnauze über den "tatsächlichen Sachverhalt" Schreibt, und nicht über das, was er meint was ich gebrauchen könnte. Meine speziellen Bedürfnisse wird er vermutlich sowieso nicht treffen, und eine realistische Darstellung ist immer besser als eine geschönte. Wenn das ganze Detailiert mit Hintergrund ist, habe ich aber eine gute Chance, viel für mich wichtiges zu finden bzw. ableiten zu können.
Aber das ist nichts, was sich verkaufen lässt. ;O)
oje, und jetzt denkst du, dann kann er sich in C ja nicht gut
auskennen?!
Dann solltest du mal etwas mehr über seinen Hintergrund lesen.
Ich denke nicht, das er in dem Punkt abstinken wird
Du solltest vieleich mal lesen lernen und das ;-) dahinter verstehen und das es ich um ein Wortspiel handelt.
Es ist schon lustig ... normalerweise wird man ja hier angepflaumt wenn man nicht genug Informationen liefert. Hier ist es scheinbar genau umgekehrt.
Deshalb habe ich weiter oben nach dem Vorwort von dem "C" Buch gefragt.
Es geht um Informationen (Das "C" Buch ) einschätzen zu können und sonst um nichts.
Andere Frage: Hast du die Kapitel auch einzeln parat?
Es gab ja ein paar Nachfragen, ob ich die Kapitel hochladen oder
allgemein verfügbar machen kann. Kurz gesagt: Nein, das geht nicht. Die
Rechte liegen beim Verlag, und öffentliche Verbreitung wäre keine gute
Idee.
Eigentlich war das eher so gemeint, dass man sich so auf die Korrektur einzelner Kapitel besser konzentrieren kann(also nicht zum öffentlich hochladen). Für mich Beispielsweise k6 und k19 (glaube ich), das dürfte aber für andere hier auch gut liegen.
(außerdem habe ich mal den tcc geprüft, der übersetzt auch einige Grundprogramme gar nicht (Trigraphen z.B. oder sizeof Ints) - da fragt man sich warum eigentlich nicht.)
Eigentlich war das eher so gemeint, dass man sich so auf die Korrektur
einzelner Kapitel besser konzentrieren kann(also nicht zum öffentlich
hochladen).
Jeder, der Interesse an einzelnen Kapiteln hat, kann sich bei mir melden und bekommt die Kapitel. Über Rückmeldungen und Verbesserungsvorschläge freue ich mich und arbeite sie ein.
Jetzt bin ich doch richtig erschrocken "Hardcover – 8 Sept. 2026". Druckfehler oder nicht gemerkt, dass der Sommer schon rum ist. Dabei ist noch gar nicht Freitag.
Ebenso explizit die Arbeit mit Bibliotheken und die Toolchain, die
benötigt wird.
So ein C-Buch hab ich. Versehentlich! "21st Century C".
Da kann man gleich das 1. Drittel überblättern (wenn es langt, inzwischen langweilt mich das Buch) weil ich nicht mit der Umgebung arbeite die sich der Autor als allgemeingültig eingebildet hat.
Wenn ich Fragen zur toolchain hab, dann frag ich die toolchain (-Herausgeber) und nicht den K & R oder sonstwen.
Wenn ich fragen zu Bibliotheken hab, dann frag ich ein C-Buch wenn und nur dann, wenn es zum Standard gehört. Ansonsten die Herausgeber der auch so tollen und garantiert nicht allgemeingültigen Bibliotheken.
Zu 2.1.1 habe ich noch irgendwo den Artikel, dass C eigentlich aus einem Spaß für ein Geschenk entstanden wäre. Am nächsten Morgen, als alle wieder die Feier überstanden hatten, fanden der Beschenkte und die Schenkenden die Idee fortsetzungswert. Vor zwanzig Jahren war ich auf einer IEEE-Veranstaltung in der Strayer University (nebenan Rutgers University), wo dies auch erzählt wurde.
Was bei den Büchern fast immer zu kurz kommt ist das Auslesen der Tastatur abweichend von der Form, dass ein Prompt wartet, bis man return gedrück hat.
Als Anlage alle Programme als Zip zum herunterladen, wäre auch eine Anregung.
Wenn das alles sauber und verständlich übersetzt und erklärt wird,
und besser als die automatische Google-Translate Übersetzung ist, dann ist es ein sehr gutes Buch.
Und wenn der Verlag sich wirklich einmischt, was ich erst einmal nicht glaube, würde ich mir einen anderen suchen ...
Was bei den Büchern fast immer zu kurz kommt ist das Auslesen der
Tastatur abweichend von der Form, dass ein Prompt wartet, bis man return
gedrück hat.
Weil das nicht mehr durch die Standard Bibliothek abgedeckt ist. An der Stelle wird es schnell Betriebssystem-spezifisch.
Die conio.h (die mir dazu als erstes in den Sinn kommt) gehört nicht zum C Standard. Unter Linux würde man die ncurses.h benutzen.
Was bei den Büchern fast immer zu kurz kommt ist das Auslesen der
Tastatur abweichend von der Form, dass ein Prompt wartet, bis man return
gedrück hat.
hm..K&R noch nicht durchgearbeitet, was? Sheeva P. war vor einiger Zeit auch total sauer, weil ich dem nicht verraten hatte, warum K&R so gut zur Krypto-Programmierung einläd.
Das Problem bei einer Zeichenkette ist halt, dass man a) ein Ende setzen muss - oder b) eben vorher schon weiß, wieviel Zeichen eingelesen werden. Ach, und darüberhinaus bei C: -> stackoverflow.com ;)
Ja, bis einschließlich C23. Und so steht z. B. durchgängig main() statt main(void) in den Beispielen. <stdckdint.h> scheint an einigen Stellen durch und zu <stdbit.h> werden nur knapp die Funktionen aufgezählt.
Ja, bis einschließlich C23. Und so steht z. B. durchgängig main()
statt main(void) in den Beispielen. <stdckdint.h> scheint an einigen
Stellen durch und zu <stdbit.h> werden nur knapp die Funktionen
aufgezählt.
main() ist aber nicht standard-konform. Falls "durchgängig" dann nicht "... bis einschliesslich C23" sondern "ausschließlich C23" o.ä. .
Und vielleichgt muss man noch zwischen Embedded und OS -Applikation unterscheiden ob "main" Werte übergeben werden oder nicht.
