Announcement: there is an English version of this forum on 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. Danke euch!
Christian P. schrieb: > (..) > > Denn, ich habe ein C-Buch geschrieben, das demnächst beim Rheinwerk > erscheinen soll.. > Das Inhaltsverzeichnis habe ich hier als PDF beigefügt. Lektor für lau?🤔 Spass beiseite..du solltest schon einige Kapitel aus dem Buch posten um ggf. Interesse zu wecken.
Christian P. schrieb: > Das hat keiner gesagt, dass das für lau sein muss. Als Schriftsteller solltest du (korrekt) zitieren. Du hast aber auch nicht erwähnt dass es für lau sein soll.
Jörg R. schrieb: > 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... Man kann sich aber auch haben!
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?
:
Bearbeitet durch User
Christian P. schrieb: > 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.
Nikolaus S. schrieb: > Hat (in meiner Auflage von 1983) nur 260 Seiten. 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.
Rene K. schrieb: > Jörg R. schrieb: >> Als Schriftsteller solltest du (korrekt) zitieren. > > Was soll er denn zitieren wenn ausschließlich ein weiterer Beitrag > dazwischen ist? Zum Beispiel aus Gründen der Höflichkeit und Respekt. Das schlechte Zitieren bzw. nicht Zitieren greift hier immer mehr um sich, daher darf man schon darauf hinweisen, auch in diesem Fall. Kannst du aber gerne anders sehen.
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? https://www.rheinwerk-verlag.de/c-programmieren-das-umfassende-handbuch/
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.
Gerald B. schrieb: > https://www.rheinwerk-verlag.de/c-programmieren-das-umfassende-handbuch/ Vergleich mal den Titel meines Buches mit dem von dir zitierten Buch :)
Harald K. schrieb: > 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!
Norbert schrieb: > Viel Erfolg dir auf alle Fälle und unabhängig vom Erfolg meinen Respekt > für dieses Werk! Danke, sehr nett von dir.
Christian P. schrieb: > 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?
1000 Seiten sind mir zu viel. Ich würde es nicht kaufen.
Johannes F. schrieb: > Christian P. schrieb: >> 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.
:
Bearbeitet durch User
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.
Hallo Christian, Christian P. schrieb: > 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: Du schreibst > Anhang C: Operatorpräzendenz. . . . . . . . . . . . . . . . . 1032 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...
:
Bearbeitet durch User
Christian P. schrieb: > ich habe ein C-Buch geschrieben 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).
Peter M. schrieb: > Hätte es "Operatorenhierarchie" nicht auch getan? Rangfolge ist der etabliertere Begriff.
Hallo Harald K., ja "Operatorenrangfolge" ist noch besser, danke!
Thomas W. schrieb: > 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>).
Nikolaus S. schrieb: > 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.
:
Bearbeitet durch User
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 ;)
Nick schrieb: > 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.
Beitrag #8040416 wurde vom Autor gelöscht.
> Anhang C: Operatorpräzendenz. . . . . . . . . . . . . . . . . 1032
Ups, genau dafür ist es gut, wenn jmd. drüberschaut, muss natürlich
Operatorpräzedenz heißen.
Christian P. schrieb: >> Anhang C: Operatorpräzendenz. . . . . . . . . . . . . . . . > Ups, genau dafür ist es gut, wenn jmd. drüberschaut, muss natürlich > Operatorpräzedenz heißen. Du glaubst tatsächlich dass „Drüberschauen“ bzw. mal eben Querlesen reicht?
Harald K. schrieb: > Nick schrieb: >> Ich dachte zunächst auch an eine Englische Ausgabe. Ich lese solche >> Bücher nur in Englisch. > > Auf, nicht in. In ist ein Anglizismus. Das war also ein hinreichender Beweis, dass ich Englische Bücher lese.
Christian P. schrieb: >> Anhang C: Operatorpräzendenz. . . . . . . . . . . . . . . . . 1032 > > Ups, genau dafür ist es gut, wenn jmd. drüberschaut, muss natürlich > Operatorpräzedenz heißen. Nun ja... meiner Meinung nach sollte es "Operatorvorrang" heissen...
Christian P. schrieb: > 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.
Frank D. schrieb: >> Danke euch! > Sind Sie der Ullenboom? Wenn "der" Ullenboom der ist, der Java-Bücher schreibt, ja. Nicht "der" Ullenboom mit der Baby-Wäsche.
Ein Buch über C im Zeitalter von KI? Wozu? 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.
Erster kurzer Eindruck: 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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
Angehängte Dateien:
-
Tiobe_April2026.png
27 KB
> Ich will jetzt kein Fass aufmachen, aber: Warum nicht Rust? Vielleicht, weil als praktizierte Programmiersprache nicht sonderlich verbreitet ?!: * https://www.tiobe.com/tiobe-index/ (siehe Anhang)
F. schrieb: > 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: https://de.wikipedia.org/wiki/Indiana_Pi_Bill
F. schrieb: > Ich will jetzt kein Fass aufmachen, aber: Warum nicht Rust? Weil Rust schon eine sehr gute Dokumentation hat.
Nick schrieb: > 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. mfg
Harald K. schrieb: > Nick schrieb: >> 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 andere*r*n? 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.
Bradward B. schrieb: >>> 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: > > https://de.wikipedia.org/wiki/Indiana_Pi_Bill 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.
Nick schrieb: > Mein Lieblings-C-Buch ist von Koenig (ich habs grad nicht zur Hand, Eventuell das hier? https://en.wikipedia.org/wiki/C_Traps_and_Pitfalls (Ich suche noch nach einem guten Buch mit deutlich unter 1000 Seiten)
Peter M. schrieb: > 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 | inline void myfunc(void){} |
3 | // something.c
|
4 | #include "something.h" |
5 | extern void myfunc(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.
:
Bearbeitet durch User
Daniel A. schrieb: > Viele Compiler haben auch ein Attribut, um inlining zu erzwingen. C bringt ja auch einen Riesenballast mit in den Code hinein. Den unnützen Überbau kann man teilweise gut mit dem Hexeditor rauseditieren.
Sowas hier kann auch nützlich sein, gerade für C: https://fedoramagazine.org/gdb-source-tracking-breakpoints/ Und so einen Stackoverflow sollte man auch programmieren können.
F. schrieb: > Ich will jetzt kein Fass aufmachen, aber: Warum nicht Rust? und warum nicht iCon? https://de.wikipedia.org/wiki/ICon-L Es hat keinen Sinn immer wieder neue Sprachen zu erfinden, davon werden Programme auch nicht besser.
Nikolaus S. schrieb: > 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.
Oder Du pruefst Dein Buch selbst. 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.
Hans schrieb: > Es gibt viele gute Gründe ein Buch in die Hand zu > nehmen. einem Buch geht nie der Strom aus, es scheitert nur am Gepäcklimit bei Flugreisen und am Tragekomfort auf Reisen.
Hans schrieb: > 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.
Lotta . schrieb: > neuen Futures wie Threads, Concepts, Ranges u.s.w., > Futures, die C++ in der Programmgeschwindigkeit immer > mehr an Assembler heranbringt. Wo hast du denn den Unsinn aufgeschnappt?
Hans schrieb: > Joachim B. schrieb: >> einem Buch geht nie der Strom aus > > Das auch. Ein Buch ist immer vor dem Chef im Geschäft?
Frank D. schrieb: > Wo hast du denn den Unsinn aufgeschnappt? 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.
Z.B. fast 2 Seiten für die int_fastN_t Integertypen, nachdem die Grundtypen schon eingeführt wurden. Mir fehlt jede Fantasie, wie man mit einer wirklich vollständigen Erklärung dazu mehr als zwei kurze Absätze füllen kann. Schwierig. Oliver
Harald K. schrieb: > Nein. Wieso eigentlich "E"nglische Bücher mit großem "E"? Englische Bücher, Deutsche Bücher. Das Eine ist Englische Rechtschreibung (und kein Anglizismus), das Andere Deutsche Rechtschreibung. Harald K. schrieb: > Aber für derartige Diskussionen ist das hier nicht der richtige Ort. Und deine Regeln gelten natürlich nur für Andere. Ich schreib "deine" absichtlich klein, für dich!
F. schrieb: > Hans schrieb: >> Joachim B. schrieb: >>> einem Buch geht nie der Strom aus >> >> Das auch. > > Ein Buch ist immer vor dem Chef im Geschäft? 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. Gruss WK
Thomas F. schrieb: > Eventuell das hier? > https://en.wikipedia.org/wiki/C_Traps_and_Pitfalls > > (Ich suche noch nach einem guten Buch mit deutlich unter 1000 Seiten) Nein, das kenne ich nicht. Taugt das was? Ich such mal ... Oh sorry! Ich meinte "C in a nutshell" (und weiß echt nicht mehr, wie ich auf Koenig gekommen bin). 600 Seiten. https://www.oreilly.com/library/view/c-in-a/9781491924174/ 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.
Nick schrieb: > Taugt das was? 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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
Ich hab sehr viel durch das "C/C++ Users Journal" gelernt. Gibts aber nicht mehr. https://en.wikipedia.org/wiki/C/C++_Users_Journal
Diese Seite hier ist teilweise auch sehr hilfreich. Schön, dass die immer noch Online-verfügbar ist: http://www-cs-students.stanford.edu/~blynn/c/
Dieter D. schrieb: > 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 was hat das mit Futures zu tun?
Walter T. schrieb: > .... > 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.
Hallo Frank D., Frank D. schrieb: > Und was hat das mit Futures zu tun? Er meint wahrscheinlich Features - um börsengehandelte Terminkontrakte geht es wahrscheinlich weniger. Meinte ein Kollege vor Jahren in der Projektgruppe: "Das ist ja eine Syphillis-Arbeit!" :)
:
Bearbeitet durch User
Oliver S. schrieb: > Natürlich gar nix. Es dietert halt… Blöderweise macht das c23 bzw. die Standardcrew irgendwie auch gerade..;)
Johann L. schrieb: > Teil 2 für: Welche Compiler und IDEs gibt es 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: >> >> https://de.wikipedia.org/wiki/Indiana_Pi_Bill > > 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 Manche sagen "Ballast" andere sagen "Erfahrung".
Wenn man genügsam ist, kann man auch erstmal hiermit anfangen: https://bellard.org/tcc/ (https://manpages.ubuntu.com/manpages/jammy/man1/tcc.1.html)
> TCC is heading toward full ISOC99 compliance und > 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.
Bradward B. schrieb: > "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: > > https://de.wikipedia.org/wiki/Indiana_Pi_Bill Wie die Festlegung der Lichtgeschwindigkeit auf exakt 299792458 m/s 😉
>> https://de.wikipedia.org/wiki/Indiana_Pi_Bill > > Wie die Festlegung der Lichtgeschwindigkeit auf exakt 299792458 m/s 😉 Hehe, frag mal nach den Wert für die Hubble-"Konstante", da kriegen die Hochkopferten schnell Schnappatmung.
Peter M. schrieb: > 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. :-)
Nikolaus S. schrieb: > Warum ein Buch, wo es alle Infos im Internet incl. Tutorials und Videos > gibt? Ein Buch kann man in seiner Zelle lesen.
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?
Bradward B. schrieb: > 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 > > Manche sagen "Ballast" andere sagen "Erfahrung". 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
F. schrieb: > Dinge wie bounds checking verhindern buffer overflows. Substantive werden im Deutschen immer noch groß geschrieben. Das hat was mit Grammatik zu tun, oder willst du die auch noch anglisieren?
> 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. BTW: https://en.wikipedia.org/wiki/The_Art_of_Computer_Programming ( 3000+ pages)
:
Bearbeitet durch User
Christian P. schrieb: > 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.
Udo K. schrieb: > 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.
Rainer W. schrieb: > 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?
Bradward B. schrieb: > 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.
Jack V. schrieb: > Ist die Lichtgeschwindigkeit im Vakuum nicht eine gegebene, universelle > Konstante, und der Meter ist so definiert worden, dass dieser Wert > rauskommt? So ist es. „The metre is the length of the path travelled by light in vacuum during a time interval of 1 / 299 792 458 of a second.“ Mir völlig unverständlich, warum in dem C-Buch um das es hier geht, diese Eigenschaft von c nicht erklärt wird.
>> 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: * https://de.wikipedia.org/wiki/Michelson-Morley-Experiment * https://de.wikipedia.org/wiki/Urmeter
:
Bearbeitet durch User
Bradward B. schrieb: > 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. Oliver
> Warum auch. Das Ding in Paris hat seit ewigen Zeiten nur noch > historischen Wert. Eher "halb so ewig" weil bis 1960 war es noch ziemlich gültig. BTW, Bayern ist das Land der Maße 🍺 hat seine eigene Kopie vom Urmeter ;-) > Mir völlig unverständlich, warum in dem C-Buch um das es hier geht, > diese Eigenschaft von c nicht erklärt wird. Weil die Programmiersprache 'C' von der Programmiersprache 'B' abgeleitet ist, und c von "celeritas" (lat. Schnelligkeit) .
:
Bearbeitet durch User
Bradward B. schrieb: > 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.
:
Bearbeitet durch User
Angehängte Dateien:
-
Herkunft.png
150 KB
>> 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.
:
Bearbeitet durch User
> 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.
:
Bearbeitet durch User
Bradward B. schrieb: > 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.
Wie soll man über dein neues C-Buch ehrliche Kritik ausüben ohne es gelesen zu haben sag mal Bruder?
Jük P. schrieb: > Wie soll man über dein neues C-Buch ehrliche Kritik ausüben ohne es > gelesen zu haben sag mal Bruder? Wenn das dein Bruder ist, dann ruf ihn an und frag ihn direkt. TelNr hast du ja wohl.
Bradward B. schrieb: > 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.
Bradward B. schrieb: > Und wieder ein Gewerbe ... 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.
Jük P. schrieb: > 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.
Bradward B. schrieb: > Vielleicht wollten K&R die Vorarbeiten von Thompson nicht gesondert > hervorheben. Das könnte sein. Ist wie bei den Malern, da malt auch der eine vom anderen ab.
Kostenlose Konkurrenz aus eigenem Hause zum Online lesen ? https://openbook.rheinwerk-verlag.de/c_von_a_bis_z/index.htm#_top
Christian P. schrieb: > Hallo zusammen, ich bin über einen anderen Thread hier gelandet Jetzt könnte man wenigstens noch fragen, welcher Thread? Christian P. schrieb: > Dabei bin > ich auch auf die Amazon-Bewertungen von "Max" gestoßen. Schöne Sache - aber: gibt es dazu nicht auch einen Link. Jörg R. schrieb: > 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.
:
Bearbeitet durch User
Wer sich für den Originalbeitrag interessiert, auf den ich mich bezogen habe: Beitrag "Sind alle C-Bücher wirklich so schlecht?"
12 Jahre später kann man wohl sagen: Ja, sind sie. Oliver
Christian P. schrieb: > 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: > 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.
Harald K. schrieb: > 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.
Harald K. schrieb: > 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. Oliver
Angehängte Dateien:
-
KR_2ndissue_1988.png
39 KB -
Hanser2nd_c.png
83 KB
> Die zweite Ausgabe von 1989 behandelte das damals "ANSI-C" genannte C89, > und war deutlich besser übersetzt und auch gesetzt. Vielleicht weil die US-Vorlage (nicht Hanser) deutlich anders in der Didaktik war ?! Siehe Anhang aus https://www.amazon.de/Programming-Language-Prentice-Hall-Software/dp/0131103628
Hans-Georg L. schrieb: > Kostenlose Konkurrenz aus eigenem Hause zum Online lesen ? > https://openbook.rheinwerk-verlag.de/c_von_a_bis_z/index.htm#_top Ist aber kein C23.
Moin, Oliver S. schrieb: > Harald K. schrieb: >> 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. Gruss WK
Angehängte Dateien:
-
Hanser3rd_c.png
66 KB
> Vorher hatte ich von "C. Schirmer - Die Programmiersprache C" - Hab' ich > in noch schlechterer Erinnerung. Vorher? Nachher? Auf dem Einband, scheint es so, als wäre CLaus Schirmer die Nachbearbeitung (3. Auflage) von K&R (2.Auflage) .
:
Bearbeitet durch User
Moin, Bradward B. schrieb: > 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. Gruss WK
Frank D. schrieb: > Hans-Georg L. schrieb: >> Kostenlose Konkurrenz aus eigenem Hause zum Online lesen ? >> https://openbook.rheinwerk-verlag.de/c_von_a_bis_z/index.htm#_top > > Ist aber kein C23. Was mit C23 dazu gekommen bzw. weggefallen ist ist überschaubar. https://en.cppreference.com/c/23 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.
Bradward B. schrieb: > 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).
Harald K. schrieb: > Bradward B. schrieb: >> 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.
Alexander S. schrieb: > 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:-)
:
Bearbeitet durch User
Max schrieb: > 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. > Ist es denn das hier? > https://www.rheinwerk-verlag.de/c-programmieren-das-umfassende-handbuch/ Genau richtig. Die Seite habe ich auch noch nicht gesehen. Das ist neu. > Dann habe ich soagr schon ein Buch von dir:-) Danke, von deinem Geld habe ich mir Lakritz gekauft. :)
Christian P. schrieb: >> Ist es denn das hier? >> https://www.rheinwerk-verlag.de/c-programmieren-das-umfassende-handbuch/ > > 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
> Dann bist du also der Autor vom legendären Java-Insel-Buch? Boah ey, > Respekt alter, Wow!!. Danke. > 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). 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.
:
Bearbeitet durch User
Christian P. schrieb: > 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?
Bradward B. schrieb: > BTW: https://en.wikipedia.org/wiki/The_Art_of_Computer_Programming ( > 3000+ pages) Das sind aber mehrere Bände. Und, meiner Meinung nach, das mit Abstand lehrreichste was ein (angehender) Informatiker lesen kann. Auch noch 2026. /regards
Joachim B. schrieb: > 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!
Kerningham/Ritchie war das erste und letzte C-Buch was sich lohnt zu kaufen.
Benedikt L. schrieb: > Wie soll man denn ohne Strom programmieren? Nur Buch lesen? So um 2000 Herum konnte man Informatik studieren, ohne einen PC anzufassen.
:
Bearbeitet durch User
Nemopuk schrieb: > So um 2000 Herum konnte man Informatik studieren, ohne einen PC > anzufassen. Da standen noch ein paar Suns und ein paar Maschinen von SGI herum ...
Rbx schrieb: > 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. Gerhard DK4XP < https://www.amazon.de/VHDL-2008-stuff-Systems-Silicon/dp/0123742498/ref=sr_1_1?__mk_de_DE=%C3%85M%C3%85%C5%BD%C3%95%C3%91&crid=8QBPSQ7W846S&dib=eyJ2IjoiMSJ9.d8yK4ESI6z0Nks3tn981q6jSyGSb7kyvRPUyBcxGJoTFQqdB2Q3jlnOD0uO7m-i5p53fJQPBskiw3gE9bOCTWw.MKzRQN6plTrtHwCF6G3fg8Q9OF-3NO34suelD1BsBDE&dib_tag=se&keywords=vhdl+just+the+new+stuff&qid=1777746690&sprefix=vhdl+just+the+new+stuff%2Caps%2C137&sr=8-1 >
:
Bearbeitet durch User
Angehängte Dateien:
-
Auswahl_028.png
1,8 MB
Bradward B. schrieb: >> 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. Gruß, Gerhard
Christian P. schrieb: > Rbx schrieb: >> 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 https://www.amazon.de/C-programmieren-Das-umfassende-Handbuch/dp/3367116416/ref=sr_1_4
:
Bearbeitet durch User
Hans-Georg L. schrieb: > Du hättest ja wenigstens zu einigen (wichtigen) Überschriften für uns > hier einen kurzen Satz dazu schreiben können um was es geht. Es ging ihm hier aber um Werbung.
Nick schrieb: > Es ging ihm hier aber um Werbung. Glaube ich nicht. Er kennt das Forum, und weiß, dass sich die meisten Autoren hier mit solchen Versuchen ins eigene Knie schießen.
Hallo Benedikt L.B Benedikt L. schrieb: >> 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. Mit freundlichem Gruß Bernd Wiebus alias dl1eic http://www.dl0dg.de
:
Bearbeitet durch User
Hallo Nikolaus S. Nikolaus S. schrieb: > 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. Mit freundlichem Gruß Bernd Wiebus alias dl1eic http://www.dl0dg.de
Alexander S. schrieb: > Der Unterschied zwischen „ließt“ und „liest“ > https://liest-liesst.de/liesst-liest/ du bist soo cool! dürfen wir mit dir abhängen?
Frank D. schrieb: Hey, ist ja wieder einmal ein geiler Thread! > Lotta . schrieb: >> neuen Futures wie Threads, Concepts, Ranges u.s.w., >> Futures, die C++ in der Programmgeschwindigkeit immer >> mehr an Assembler heranbringt. > Wo hast du denn den Unsinn aufgeschnappt? Aus eigener Erfahrung, an die Eleganz und Geschwindigkeit von Boost kommt man als Amateur nicht so schnell ran, wenn man alles selbst proggen muß. Außerdem siehe Hier! https://www.youtube.com/watch?v=P5wlrPa-T9Q mfg
Also mal Aussage! WO kann man diesen C-Schinken denn nun runterladen? Kaufen wird den wohl keiner. Höchstens was spenden.
Benedikt L. schrieb: > WO kann man diesen C-Schinken denn nun runterladen? Der Link wurde doch weiter oben angegeben Max schrieb: > Ist es denn das hier? > https://www.rheinwerk-verlag.de/c-programmieren-das-umfassende-handbuch/ E-Book ca. € 49,90 Vorbestellbar, Verfügbar ab 08.09.2026 und Christian P. schrieb: > Kurz gesagt: Nein, das geht nicht. Die > Rechte liegen beim Verlag, und öffentliche Verbreitung wäre keine gute > Idee.
Max schrieb: > 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 > Auch dieses Buch kannst du komplett (beim Verlag) online lesen und selbst beurteilen .... https://openbook.rheinwerk-verlag.de/javainsel/index.html > 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
:
Bearbeitet durch User
> 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.
:
Bearbeitet durch User
Hallo Hans-Georg. Hans-Georg L. schrieb: > 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) Mit freundlichem Gruß: Bernd Wiebus alias dl1eic http://www.dl0dg.de
Max schrieb: > 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.
Christian P. schrieb: > Rbx schrieb: >> 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.)
Rbx schrieb: > 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.
Christian P. schrieb: > an einzelnen Kapiteln Da wäre ich vorsichtig, weil jeder holt sich sonst ein anderes Kapitel und im Hintergrund wird wie wild getauscht. ;)
Bernd W. schrieb: > 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.
Für mich ist das hier maßgebend: https://en.cppreference.com/c englisch https://de.cppreference.com/c deutsch 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 ...
Beispiel einer Buchkritik die mal für viel Diskussionen im Internet und im Usenet gesorgt hat. Einfach nach den beiden Begriffen suchen ... Das Buch: C++ The Complete Reference von Herbert Schild Die Replik: C++ The Complete Nonsens von Peter Seebach
Dieter D. schrieb: > 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.
:
Bearbeitet durch User
Dieter D. schrieb: > 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 ;)
Max schrieb: > Welcher C Standard wird abgehandelt? Bis C23? 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.
:
Bearbeitet durch User
>> Welcher C Standard wird abgehandelt? Bis C23? > > 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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.