Vorwort

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: translation-feedback@oreilly.com

Ist es wirklich Punkrock

Gefällt dir die Parteilinie?

Wilco, "Too Far Apart"

C ist Punkrock

C hat nur eine Handvoll Schlüsselwörter und ist an den Kanten ein bisschen grob, aber es rockt. Du kannst damit alles machen. Wie die Akkorde C, G und D auf der Gitarre kannst du die Grundtechniken schnell lernen und dann den Rest deines Lebens damit verbringen, besser zu werden. Die Leute, die es nicht verstehen, fürchten seine Kraft und halten es für zu kantig, um sicher zu sein. Dabei ist sie die beliebteste Sprache, für die keine Firma oder Stiftung Geld ausgibt, um sie zu fördern.1

Außerdem ist die Sprache etwa 40 Jahre alt und damit mittelalt. Sie wurde von ein paar Jungs geschrieben, die im Grunde genommen gegen das Management arbeiteten - die perfekten Punkrock-Ursprünge - aberdas war in den 1970er Jahren, und es war viel Zeit, bis die Sprache zum Mainstream wurde.

Was haben die Leute gemacht, als der Punkrock zum Mainstream wurde? In den Jahrzehnten seit seinem Aufkommen in den 1970er Jahren ist der Punk sicherlich von den Rändern her gekommen: The Clash, The Offspring, Green Day und The Strokes haben weltweit Millionen von Alben verkauft (um nur einige zu nennen), und ich habe in meinem Supermarkt leichte Instrumentalversionen von Songs aus dem Punk-Ableger Grunge gehört. Der ehemalige Leadsänger von Sleater-Kinney hat jetzt eine beliebte Sketch-Comedy-Show, in der er sich häufig über Punkrocker lustig macht.2 Eine Reaktion auf die fortschreitende Entwicklung wäre, die harte Linie zu fahren und zu sagen, dass die ursprüngliche Welle Punk war und alles andere nur einfacher Punk-Pop für die Massen ist. Die Traditionalisten können immer noch ihre Alben aus den 70er Jahren spielen und wenn die Rillen abgenutzt sind, können sie eine digital gemasterte Ausgabe herunterladen. Sie können Ramones-Kapuzenpullis für ihre Kleinkinder kaufen.

Außenstehende verstehen das nicht. Einige von ihnen hören das Wort Punk und stellen sich etwas aus den 1970er Jahren vor - ein historisches Artefakt über ein paar Kids, die damals wirklich etwas anderes gemacht haben. Die traditionalistischen Punks, die immer noch ihre Iggy-Pop-LPs von 1973 lieben und spielen, haben ihren Spaß, aber sie verstärken den Eindruck, dass Punk verknöchert und nicht mehr relevant ist.

Um auf die Welt von C zurückzukommen: Es gibt sowohl die Traditionalisten, die das Banner von ANSI '89 schwenken, als auch diejenigen, die zu allem, was funktioniert, abrocken und vielleicht nicht einmal merken, dass der Code, den sie schreiben, in den 1990er Jahren nicht kompiliert worden wäre oder nicht funktioniert hätte. Außenstehende verstehen den Unterschied nicht. Sie sehen immer noch gedruckte Bücher aus den 1980er Jahren und Online-Tutorials aus den 1990er Jahren, sie hören von den Hardcore-Traditionalisten, die darauf bestehen, auch heute noch so zu schreiben, und sie wissen nicht einmal, dass sich die Sprache und der Rest ihrer Benutzer weiterentwickeln. Das ist eine Schande, denn sie verpassen einige großartige Dinge.

In diesem Buch geht es darum, mit der Tradition zu brechen und C punkrockig zu halten. Ich habe keine Lust, den Code in diesem Buch mit der ursprünglichen C-Spezifikation in Kernighan & Ritchies Buch von 1978 zu vergleichen. Mein Telefon hat 512 MB Speicher, warum also behandeln unsere C-Lehrbücher immer noch seitenweise Techniken, mit denen wir Kilobytes aus unseren ausführbaren Dateien herausholen können? Ich schreibe dies auf einem roten Netbook der untersten Kategorie, das 3.200.000.000 Befehle pro Sekunde verarbeiten kann; was kümmert es mich, ob eine Operation 8 oder 16 Bits vergleichen muss? Wir sollten Code schreiben, den wir schnell schreiben können und der für unsere Mitmenschen lesbar ist. Da wir immer noch in C schreiben, wird unser lesbarer, aber unvollkommen optimierter Code immer noch um eine Größenordnung schneller laufen, als wenn wir vergleichbaren Code in einer beliebigen anderen, aufgeblähten Sprache geschrieben hätten.

Q & A (oder, die Parameter des Buches)

F: Wie unterscheidet sich dieses C-Buch von allen anderen?

A: Manche sind besser geschrieben, manche sind sogar unterhaltsam, aber C-Lehrbücher sind ein ziemlich einheitlicher Haufen (ich habe viele von ihnen gelesen, darunter C for Programmers with an Introduction to C11; Head First C; The C Programming Language, 1st Edition; The C Programming Language 2nd Edition; Programming in C; Practical C Programming; Absolute Beginner's Guide to C; The Waite Group's C Primer Plus; and C Programming). Die meisten wurden geschrieben, bevor der C99-Standard viele Aspekte der Verwendung vereinfachte, und man merkt, dass einige der Bücher, die jetzt in der x-tenAuflage vorliegen, nur ein paar Notizen über Aktualisierungen eingefügt haben, anstatt ernsthaft zu überdenken, wie die Sprache zu verwenden ist. Sie alle erwähnen, dass es Bibliotheken gibt, die du vielleicht beim Schreiben deines eigenen Codes verwenden könntest, aber die meisten sind älter als die Installationswerkzeuge und das Ökosystem, das wir heute haben und das die Verwendung dieser Bibliotheken zuverlässig und einigermaßen portabel macht. Diese Lehrbücher sind immer noch gültig und wertvoll, aber moderner C-Code sieht einfach nicht mehr so aus wie der Code in vielen dieser Lehrbücher.

Dieses Buch macht dort weiter, wo sie aufgehört haben, und überdenkt die Sprache und das Ökosystem, in dem sie lebt. Hier geht es um die Verwendung von Bibliotheken, die verknüpfte Listen und XML-Parser bereitstellen, und nicht darum, neue Parser von Grund auf zu schreiben. Es geht darum, Code zu schreiben, der lesbar ist und eine benutzerfreundliche Oberfläche hat.

F: Für wen ist dieses Buch gedacht? Muss ich ein Programmierer-Guru sein?

A: Du hast Erfahrung im Programmieren in einer beliebigen Sprache, vielleicht Java oder einer Skriptsprache wie Perl. Ich muss dir nicht erklären, warum dein Code nicht aus einer einzigen langen Routine ohne Unterfunktionen bestehen sollte.

Der Hauptteil des Buches setzt Grundkenntnisse in C voraus, die du beim Schreiben von C-Code erworben hast. Wenn du in den Details eingerostet bist oder bei Null anfängst, findest du im Anhang A ein kurzes Tutorial zu den Grundlagen von C für Leser, die von einer Skriptsprache wie Python oder Ruby kommen.

Ich möchte dich darauf hinweisen, dass ich auch ein Lehrbuch über statistisches und wissenschaftliches Rechnen geschrieben habe: Modeling with Data (Klemens, 2008). Neben vielen Details zum Umgang mit numerischen Daten und zur Verwendung statistischer Modelle zur Beschreibung von Daten enthält es auch ein längeres, eigenständiges Tutorial zu C, das meiner Meinung nach viele der Fehlschläge älterer C-Tutorials ausgleicht.

F: Ich bin ein Anwendungsprogrammierer und kein Kernel-Hacker. Warum sollte ich C statt einer schnell zu schreibenden Skriptsprache wie Python verwenden?

A: Wenn du ein Anwendungsprogrammierer bist, ist dieses Buch genau das Richtige für dich. Wenn ich lese, dass C eine Systemsprache ist, finde ich das sehr unpunkig - wer sind sie, dass sie uns vorschreiben, was wir schreiben dürfen?

Aussagen wie "Unsere Sprache ist fast so schnell wie C, aber einfacher zu schreiben" sind so häufig, dass sie schon fast ein Klischee sind. Nun, C ist definitiv so schnell wie C, und das Ziel dieses Buches ist es, dir zu zeigen, dass C einfacher zu schreiben ist, als es die Lehrbücher der letzten Jahrzehnte vermuten lassen. Du musst nicht mehr so oft malloc aufrufen und dich mit der Speicherverwaltung herumschlagen wie die Systemprogrammierer der 1990er Jahre, wir haben Möglichkeiten zur einfacheren Handhabung von Zeichenketten und sogar die Kernsyntax hat sich weiterentwickelt, um den Code lesbarer zu machen.

Ich habe ernsthaft angefangen, C zu schreiben, weil ich eine Simulation in einer Skriptsprache, R, beschleunigen musste. Wie viele andere Skriptsprachen hat auch R eine C-Schnittstelle und ermutigt den Benutzer, diese immer dann zu nutzen, wenn die Hostsprache zu langsam ist. Irgendwann hatte ich so viele Funktionen, die aus dem Host-Skript in den C-Code übergingen, dass ich die Host-Sprache einfach ganz weggelassen habe.

F: Es ist schön, dass Anwendungsprogrammierer, die von Skriptsprachen kommen, dieses Buch mögen werden, aber ich bin ein Kernel-Hacker. Ich habe mir C in der fünften Klasse selbst beigebracht und habe manchmal Träume, die sich richtig kompilieren lassen. Welches neue Material kann es für mich geben?

A: C hat sich in den letzten 20 Jahren weiterentwickelt. Wie ich später noch erläutern werde, haben sich die Dinge, die garantiert von allen C-Compilern unterstützt werden, im Laufe der Zeit verändert, da es seit dem ursprünglichen ANSI-Standard, der die Sprache so lange definiert hat, zwei neue C-Standards gibt. Vielleicht wirfst du mal einen Blick in Kapitel 10 und schaust, ob dich dort etwas überrascht. Einige Abschnitte dieses Buches, wie das Kapitel, das häufige Missverständnisse über Zeiger aufklärt(Kapitel 6), behandeln Themen, die sich seit den 1980er Jahren kaum verändert haben.

Auch die Umgebung hat sich weiterentwickelt. Viele der Werkzeuge, die ich behandle, wie make und der Debugger, sind dir vielleicht schon bekannt, aber ich habe festgestellt, dass andere nicht so gut bekannt sind. Die Autotools haben die Art und Weise, wie der Code verteilt wird, völlig verändert, und Git hat die Art und Weise, wie gemeinschaftlich programmiert wird, verändert.

F: Mir ist aufgefallen, dass etwa ein Drittel des Buches fast keinen C-Code enthält.

A: Dieses Buch will das abdecken, was die anderen C-Lehrbücher nicht tun, und ganz oben auf der Liste stehen die Werkzeuge und die Umgebung. Wenn du keinen Debugger verwendest (eigenständig oder als Teil deiner IDE), machst du dir das Leben viel schwerer. In Lehrbüchern wird der Debugger oft nur am Rande erwähnt, wenn er überhaupt vorkommt. Wenn du deinen Code mit anderen teilst, brauchst du weitere Tools, wie Autotools und Git. Code lebt nicht im luftleeren Raum, und ich hatte das Gefühl, dass ich einen schlechten Dienst erweise, wenn ich ein weiteres Lehrbuch schreibe, das vorgibt, dass der Leser nur die Syntax der Sprache braucht, um produktiv zu sein.

F: Wie hast du aus den vielen Tools, die es für die C-Entwicklung gibt, die in diesem Buch ausgewählt?

A: Die C-Gemeinschaft hält sich mehr als die meisten anderen an einen hohen Standard der Interoperabilität. Es gibt viele C-Erweiterungen, die von der GNU-Umgebung bereitgestellt werden, IDEs, die nur unter Windows funktionieren, und Compiler-Erweiterungen, die nur in LLVM existieren. Das ist wahrscheinlich der Grund, warum frühere Lehrbücher sich davor scheuten, Tools zu behandeln. Heutzutage gibt es jedoch einige Systeme, die auf allen Computern funktionieren, die wir gemeinhin als Computer bezeichnen. Viele von ihnen stammen aus der GNU; LLVM und die dazugehörigen Tools sind zwar schnell auf dem Vormarsch, aber noch nicht so weit verbreitet. Ganz gleich, ob du einen Windows-Rechner, einen Linux-Rechner oder eine Instanz deines Cloud-Providers verwendest, die hier vorgestellten Tools sollten einfach und schnell zu installieren sein. Ich erwähne ein paar plattformspezifische Tools, werde aber in diesen Fällen explizit darauf eingehen.

Ich gehe nicht auf integrierte Entwicklungsumgebungen (IDEs) ein, weil nur wenige, wenn überhaupt, zuverlässig auf allen Plattformen funktionieren (versuch mal, eine Amazon Elastic Compute Cloud-Instanz hochzufahren und Eclipse und seine C-Plug-ins zu installieren) und die Wahl der IDE stark von persönlichen Vorlieben beeinflusst wird. IDEs haben in der Regel ein Projekt-Build-System, das in der Regel nicht mit den Projekt-Build-Systemen der anderen IDEs kompatibel ist. IDE-Projektdateien sind daher unbrauchbar für die Verteilung von Projekten außerhalb von Situationen (Klassenzimmer, bestimmte Büros, einige Computerplattformen), in denen jeder die gleiche IDE verwenden muss.

F: Ich habe das Internet und kann Befehle und Syntaxdetails in ein oder zwei Sekunden nachschlagen. Warum sollte ich also dieses Buch lesen?

A: Es stimmt: Du kannst eine Operator-Präzedenztabelle von einer Linux- oder Mac-Eingabeaufforderung mit man operator abrufen, warum sollte ich sie also hier einfügen?

Ich habe das gleiche Internet wie du und ich habe viel Zeit damit verbracht, es zu lesen. Ich habe also eine gute Vorstellung davon, worüber nicht gesprochen wird, und daran halte ich mich hier. Wenn ich ein neues Tool wie gprof oder gdb vorstelle, gebe ich dir, was du wissen musst, um dich zurechtzufinden und deiner Suchmaschine schlüssige Fragen zu stellen, und was andere Lehrbücher ausgelassen haben (was eine Menge ist).

Standards: So viele zur Auswahl

Wenn nicht ausdrücklich anders angegeben, entspricht alles in diesem Buch den ISO-Normen C99 und C11. Damit du verstehst, was das bedeutet, und um dir einen Überblick über die Geschichte zu verschaffen, gehen wir die Liste der wichtigsten C-Normen durch (und übergehen dabei die kleineren Überarbeitungen und Korrekturen).

K & R (ca. 1978)

Dennis Ritchie, Ken Thompson und eine Handvoll anderer Mitwirkender entwickelten C bei der Entwicklung des Unix-Betriebssystems. Brian Kernighan und Dennis Ritchie schrieben schließlich eine Beschreibung der Sprache in der ersten Ausgabe ihres Buches nieder, das den ersten De-facto-Standard setzte (Kernighan, 1978).

ANSI C89

Bell Labs übergab die Verantwortung für die Sprache an das American National Standards Institute (ANSI). Im Jahr 1989 veröffentlichte das Institut seinen Standard, der einige Verbesserungen gegenüber K & R enthielt. Die zweite Auflage des K & R-Buches enthielt eine vollständige Spezifikation der Sprache, was bedeutete, dass Zehntausende von Programmierern eine Kopie des ANSI-Standards auf ihrem Schreibtisch hatten (Kernighan, 1988). Der ANSI-Standard wurde 1990 von der Internationalen Organisation für Normung (ISO) ohne gravierende Änderungen übernommen, aber ANSI '89 scheint der gebräuchlichere Begriff zu sein (und würde sich gut als T-Shirt-Slogan eignen).

Ein Jahrzehnt verging. C wurde zum Mainstream, und zwar in dem Sinne, dass der Basiscode für mehr oder weniger jeden PC und jeden Internetserver in C geschrieben wurde, was mehr Mainstream ist, als ein menschliches Unterfangen überhaupt werden kann.

In dieser Zeit spaltete sich C++ ab und kam groß raus (wenn auch nicht ganz so groß). C++ war das Beste, was C je passiert ist. Während jede andere Sprache zusätzliche Syntax einbaute, um dem objektorientierten Trend zu folgen, und was den Autoren sonst noch an neuen Tricks einfiel, hielt C am Standard fest. Die Leute, die Stabilität und Portabilität wollten, benutzten C, die Leute, die immer mehr Funktionen wollten, um darin zu schwelgen wie in feuchten Hundert-Dollar-Scheinen, bekamen C++, und alle waren glücklich.

ISO C99

Ein Jahrzehnt später wurde der C-Standard einer umfassenden Überarbeitung unterzogen. Es wurden Ergänzungen für numerische und wissenschaftliche Berechnungen vorgenommen, mit einem Standardtyp für komplexe Zahlen und einigen typgenerischen Funktionen. Einige Annehmlichkeiten von C++ wurden übernommen, darunter einzeilige Kommentare (die ursprünglich aus einer der Vorgängersprachen von C, BCPL, stammten) und die Möglichkeit, Variablen am Anfang von for Schleifen zu deklarieren. Die Verwendung von Strukturen wurde durch einige Ergänzungen der Regeln für ihre Deklaration und Initialisierung sowie durch einige Erleichterungen bei der Notation vereinfacht. Die Dinge wurden modernisiert, um der Tatsache Rechnung zu tragen, dass Sicherheit wichtig ist und dass nicht jeder Englisch spricht.

Wenn man bedenkt, wie viel Einfluss C89 hatte und dass die ganze Welt auf C-Code basierte, ist es schwer vorstellbar, dass die ISO etwas herausgeben konnte, das nicht auf breite Kritik stoßen würde - selbst die Weigerung, Änderungen vorzunehmen, wäre verpönt gewesen. Und tatsächlich war dieser Standard umstritten. Es gibt zwei gängige Möglichkeiten, eine komplexe Variable auszudrücken (rechtwinklige und polare Koordinaten) - wie kommt die ISO dazu, sich für eine zu entscheiden? Warum brauchen wir einen Mechanismus für Makroeingaben mit variabler Länge, wenn der ganze gute Code ohne ihn geschrieben wurde? Mit anderen Worten: Die Puristen warfen der ISO vor, sich dem Druck nach mehr Funktionen zu beugen.

Zum Zeitpunkt der Erstellung dieses Artikels unterstützen die meisten Compiler C99 mit einigen Abstrichen. Es gibt jedoch eine bemerkenswerte Ausnahme von diesem breiten Konsens: Microsoft weigert sich derzeit, seinem Visual Studio C++ Compiler C99-Unterstützung hinzuzufügen. Der Abschnitt "C mit Windows kompilieren" behandelt einige der vielen Möglichkeiten, C-Code für Windows zu kompilieren. Visual Studio nicht zu verwenden, ist also höchstens eine Unannehmlichkeit, und wenn uns ein großes Unternehmen sagt, dass wir ANSI- und ISO-Standard-C nicht verwenden können, verstärkt das nur noch den Punkrock.

C11

Aus Angst vor dem Vorwurf des Ausverkaufs nahm die ISO in der dritten Ausgabe des Standards nur wenige ernsthafte Änderungen vor. Wir haben eine Möglichkeit bekommen, typgenerische Funktionen zu schreiben, und die Dinge wurden modernisiert, um der Tatsache Rechnung zu tragen, dass Sicherheit wichtig ist und dass nicht jeder Englisch spricht.

Der C11-Standard wurde im Dezember 2011 veröffentlicht, aber die Unterstützung für den Standard wurde von den Compiler-Autoren überraschend schnell implementiert, so dass eine Reihe großer Compiler bereits eine fast vollständige Konformität beanspruchen. Der Standard definiert jedoch das Verhalten sowohl des Compilers als auch der Standardbibliothek. Die Unterstützung der Bibliothek, z. B. für Threading und Atomics, ist auf einigen Systemen vollständig, auf anderen jedoch noch nicht.

Der POSIX-Standard

Das ist der Stand der Dinge, was C selbst angeht, aber die Sprache hat sich zusammen mit dem Unix-Betriebssystem entwickelt, und du wirst im Laufe des Buches sehen, dass diese Wechselbeziehung für die tägliche Arbeit wichtig ist. Wenn etwas auf der Unix-Befehlszeile einfach ist, liegt das wahrscheinlich daran, dass es in C einfach ist; Unix-Tools werden oft geschrieben, um das Schreiben von C-Code zu erleichtern.

Unix

C und Unix wurden in den frühen 1970er Jahren in den Bell Labs entwickelt. Während des größten Teils des 20. Jahrhunderts wurde gegen Bell wegen monopolistischer Praktiken ermittelt, und eine der Vereinbarungen mit der US-Regierung beinhaltete das Versprechen, dass Bell seinen Einflussbereich nicht auf Software ausweiten würde. Also wurde Unix kostenlos an Forscher/innen zum Sezieren und Nachbauen weitergegeben. Der Name Unix ist ein Markenzeichen, das ursprünglich Bell Labs gehörte und später wie eine Baseballkarte zwischen verschiedenen Unternehmen gehandelt wurde.

Varianten von Unix blühten auf, als der Code von verschiedenen Hackern überarbeitet, neu implementiert und auf unterschiedliche Weise verbessert wurde. Es braucht nur eine kleine Inkompatibilität, um ein Programm oder ein Skript unportabel zu machen, also wurde die Notwendigkeit einer Standardisierung schnell deutlich.

POSIX (Portable Operating System Interface)

Dieser Standard, der 1988 vom Institute of Electrical and Electronics Engineers (IEEE) eingeführt wurde, bildet eine gemeinsame Grundlage für Unix-ähnliche Betriebssysteme. Er legt fest, wie die Shell funktionieren soll, was von Befehlen wie ls und grep zu erwarten ist und eine Reihe von C-Bibliotheken, die C-Autoren zur Verfügung gestellt werden sollten. So werden zum Beispiel die Pipes, die Befehlszeilenbenutzer verwenden, um Befehle aneinanderzureihen, hier im Detail beschrieben, was bedeutet, dass die Funktion popen (pipe open) von C dem POSIX-Standard entspricht und nicht dem ISO C-Standard. Der POSIX-Standard wurde mehrmals überarbeitet; die aktuelle Version ist POSIX:2008, und darauf beziehe ich mich, wenn ich sage, dass etwas POSIX-Standard ist. Ein System, das dem POSIX-Standard entspricht, muss über einen C-Compiler verfügen, der über den Befehl c99 aufgerufen werden kann.

In diesem Buch wird der POSIX-Standard verwendet, aber ich werde dir sagen, wann.

Mit Ausnahme vieler Mitglieder der Betriebssystemfamilie von Microsoft basieren fast alle aktuellen Betriebssysteme auf einer POSIX-kompatiblen Basis: Linux, Mac OS X, iOS, webOS, Solaris, BSD - sogar Windows-Server bieten ein POSIX-Subsystem. Und für die "Hold-Out"-Betriebssysteme wird dir in "C mit Windows kompilieren" gezeigt, wie du ein POSIX-Subsystem installieren kannst.

Schließlich gibt es noch zwei weitere Implementierungen von POSIX, die aufgrund ihrer Verbreitung und ihres Einflusses erwähnenswert sind:

BSD

Nachdem Unix von den Bell Labs der Öffentlichkeit zur Verfügung gestellt wurde, nahmen die Forscher der University of California, Berkeley, wichtige Verbesserungen vor und schrieben schließlich die gesamte Unix-Codebasis um, um die Berkeley Software Distribution zu entwickeln. Wenn du einen Computer von Apple, Inc. benutzt, verwendest du BSD mit einem attraktiven grafischen Frontend. BSD geht in vielerlei Hinsicht über POSIX hinaus, und wir werden einige Funktionen kennenlernen, die nicht zum POSIX-Standard gehören, aber zu nützlich sind, um auf sie zu verzichten (vor allem der Lebensretter asprintf).

GNU

Es steht für GNU's Not Unix und ist die andere große Erfolgsgeschichte der unabhängigen Neuimplementierung und Verbesserung der Unix-Umgebung. Die große Mehrheit der Linux-Distributionen verwendet durchgängig GNU-Werkzeuge. Die Chancen stehen gut, dass du die GNU Compiler Collection (gcc) auf deinem POSIX-System hast - sogar BSD verwendet sie. Auch hier definiert die gcc einen De-facto-Standard, der C und POSIX in einigen Punkten erweitert, und ich werde explizit darauf eingehen, wenn ich diese Erweiterungen verwende.

Rechtlich gesehen ist die BSD-Lizenz etwas freizügiger als die GNU-Lizenz. Da einige Parteien sehr besorgt über die politischen und geschäftlichen Auswirkungen der Lizenzen sind, kann man in der Regel sowohl GNU- als auch BSD-Versionen der meisten Tools finden. Zum Beispiel sind sowohl gcc als auch die BSD-Version clang erstklassige C-Compiler. Die Autorinnen und Autoren beider Lager beobachten die Arbeit der jeweils anderen Seite genau und lernen von ihr, so dass wir davon ausgehen können, dass sich die derzeit bestehenden technischen Unterschiede mit der Zeit ausgleichen werden.

Einige Logistik

Die zweite Auflage

Früher war ich ein Zyniker und dachte, dass die Leute die zweite Auflage nur geschrieben haben, um all die Leute zu stören, die gebrauchte Exemplare der ersten Auflage verkaufen. Aber diese zweite Auflage hätte es ohne die erste nicht geben können, und sie hätte auch nicht früher erscheinen können (und die meisten Leserinnen und Leser des Buches lesen ohnehin elektronische Exemplare).

Die größte Neuerung gegenüber der ersten Ausgabe ist das Kapitel über gleichzeitige Threads, auch bekannt als Parallelisierung. Es konzentriert sich auf OpenMP und atomare Variablen und Strukturen. OpenMP ist nicht Teil des C-Standards, aber es ist ein zuverlässiger Teil des C-Ökosystems und passt daher gut in dieses Buch. Atomare Variablen wurden in der Revision des C-Standards vom Dezember 2011 hinzugefügt. Als dieses Buch weniger als ein Jahr später herauskam, gab es also noch keine Compiler, die sie unterstützten. Jetzt sind wir so weit, dass ich dieses Kapitel sowohl auf der Grundlage der Theorie des Standards als auch der Praxis einer realen Implementierung und getesteten Codes schreiben konnte. Siehe Kapitel 12.

Die erste Ausgabe war mit einigen wunderbar pedantischen Lesern gesegnet. Sie haben alles aufgespürt, was irgendwie als Fehler ausgelegt werden konnte, von der dummen Sache, die ich über Bindestriche in der Kommandozeile gesagt habe, bis hin zu Sätzen, deren Wortlaut in bestimmten Fällen falsch verstanden werden konnte. Nichts auf dieser Welt ist fehlerfrei, aber das Buch ist dank der vielen tollen Leserrückmeldungen viel genauer und nützlicher geworden.

Weitere Ergänzungen in dieser Ausgabe:

  • Anhang A bietet ein grundlegendes C-Tutorial für Leser, die aus einer anderen Sprache kommen. Ich habe gezögert, ihn in die erste Ausgabe aufzunehmen, weil es schon so viele C-Tutorials gibt, aber das Buch ist mit ihm nützlicher als ohne.

  • Auf vielfachen Wunsch habe ich die Diskussion über die Verwendung eines Debuggers erheblich erweitert. Siehe "Einen Debugger verwenden".

  • In der ersten Ausgabe gab es einen Abschnitt darüber, wie man Funktionen schreibt, die eine Liste beliebiger Länge aufnehmen, sodass sowohl sum(1, 2.2) als auch sum(1, 2.2, 3, 8, 16) gültig wären. Aber was ist, wenn du mehrere Listen senden willst, z. B. wenn du eine Punktproduktfunktion schreibst, die zwei Vektoren beliebiger Länge multipliziert, wie dot((2, 4), (-1, 1)) und dot((2, 4, 8, 16), (-1, 1, -1, 1))? "Mehrere Listen" deckt dies ab.

  • Ich habe Kapitel 11 über die Erweiterung von Objekten mit neuen Funktionen neu geschrieben. Die wichtigste Ergänzung ist eine Implementierung von virtuellen Tabellen.

  • Ich habe ein wenig mehr über den Präprozessor geschrieben, mit einer Einführung in den Wust von Testmakros und ihre Verwendung in "Testmakros", einschließlich einer beiläufigen Erwähnung des Schlüsselworts _Static_assert.

  • Ich habe mich an ein Versprechen gehalten, das ich mir selbst gegeben habe, nämlich kein Tutorial über das Parsen regulärer Ausdrücke in dieses Buch aufzunehmen (weil es Hunderte davon online und in anderen Büchern gibt). Allerdings habe ich in "Parsen regulärer Ausdrücke" eine Demo zur Verwendung der Parsing-Funktionen für reguläre Ausdrücke von POSIX hinzugefügt, die im Vergleich zu Regex-Parsern in vielen anderen Sprachen in einer relativ rohen Form vorliegen.

  • Die Diskussion über die Handhabung von Zeichenketten in der ersten Ausgabe stützte sich stark auf asprintf, eine sprintf-ähnliche Funktion, die den erforderlichen Speicherplatz automatisch zuweist, bevor eine Zeichenkette in den Speicher geschrieben wird. Es gibt eine von der GNU verbreitete Version, aber viele Leserinnen und Leser konnten sie nicht verwenden. Deshalb habe ich in dieser Ausgabe Beispiel 9-3 hinzugefügt, das zeigt, wie man eine solche Funktion aus C-Standardteilen schreibt.

  • Eines der Hauptthemen in Kapitel 7 ist, dass der Umgang mit numerischen Typen zu Problemen führen kann. Deshalb wurden in der ersten Ausgabe die Dutzende neuer numerischer Typen, die mit dem C99-Standard eingeführt wurden, wie int_least32_t, uint_fast64_t usw., nicht erwähnt (C99 §7.18; C11 §7.20). Mehrere Leser haben mich ermutigt, zumindest einige der nützlicheren Typen wie intptr_t und intmax_t zu erwähnen, was ich jetzt auch tue, wo es angebracht ist.

In diesem Buch verwendete Konventionen

In diesem Buch werden die folgenden typografischen Konventionen verwendet:

Kursiv

Weist auf neue Begriffe, Dateinamen und Dateipfade, URLs und E-Mail-Adressen hin. Viele neue Begriffe werden in einem Glossar am Ende des Buches definiert.

Constant width

Wird für Programmlistings sowie innerhalb von Absätzen verwendet, um auf Programmelemente wie Variablen- oder Funktionsnamen, Datenbanken, Datentypen, Umgebungsvariablen, Anweisungen und Schlüsselwörter hinzuweisen.

Constant width italic

Zeigt Text an, der durch vom Benutzer eingegebene Werte oder durch kontextabhängige Werte ersetzt werden soll.

Hinweis

Dieses Symbol steht für einen Tipp, eine Anregung oder einen allgemeinen Hinweis.

Vorsicht

Dieses Symbol weist auf eine Warnung oder Vorsicht hin.

Code-Beispiele verwenden

Dieses Buch soll dir helfen, deine Arbeit zu erledigen. Im Allgemeinen darfst du den Code in diesem Buch in deinen Programmen und deiner Dokumentation verwenden. Du musst uns nicht um Erlaubnis fragen, es sei denn, du reproduzierst einen großen Teil des Codes. Wenn du zum Beispiel ein Programm schreibst, das mehrere Teile des Codes aus diesem Buch verwendet, brauchst du keine Erlaubnis. Wenn du eine CD-ROM mit Beispielen aus den O'Reilly-Büchern verkaufst oder verteilst, ist eine Genehmigung erforderlich. Die Beantwortung einer Frage mit einem Zitat aus diesem Buch und einem Beispielcode erfordert keine Genehmigung. Wenn du einen großen Teil des Beispielcodes aus diesem Buch in die Dokumentation deines Produkts aufnimmst, ist eine Erlaubnis erforderlich.

Die Codebeispiele für diesen Titel findest du hier: https://github.com/b-k/21st-Century-Examples.

Wir schätzen die Namensnennung, verlangen sie aber nicht. Eine Quellenangabe umfasst normalerweise den Titel, den Autor, den Verlag und die ISBN. Zum Beispiel: "21st Century C, 2nd Edition von Ben Klemens (O'Reilly). Copyright 2014 Ben Klemens, 978-1-491-90389-6."

Wenn du der Meinung bist, dass die Verwendung von Code-Beispielen nicht unter die Fair-Use-Regelung oder die oben genannte Erlaubnis fällt, kannst du uns gerne unter kontaktieren

Safari® Bücher Online

Safari Books Online(www.safaribooksonline.com) ist eine digitale On-Demand-Bibliothek, die Experteninhalte in Buch- und Videoform von weltweit führenden Autoren aus den Bereichen Technologie und Wirtschaft bereitstellt.

Technologieexperten, Softwareentwickler, Webdesigner sowie Geschäftsleute und Kreative nutzen Safari Books Online als Hauptressource für Recherchen, Problemlösungen, Lernen und Zertifizierungstraining.

Safari Books Online bietet eine Reihe von Produktkombinationen und Preisprogrammen für Unternehmen, Behörden und Einzelpersonen. Abonnenten haben Zugang zu Tausenden von Büchern, Schulungsvideos und Manuskripten von Verlagen wie O'Reilly Media, Prentice Hall Professional, Addison-Wesley Professional, Microsoft Press, Sams, Que, Peachpit Press, Focal Press, Cisco Press, John Wiley & Sons, Syngress Sons, Syngress, Morgan Kaufmann, IBM Redbooks, Packt, Adobe Press, FT Press, Apress, Manning, New Riders, McGraw-Hill, Jones & Bartlett, Course Technology und Dutzende mehr. Wenn du mehr über Safari Books Online erfahren möchtest, besuche uns bitte online.

Wie du uns kontaktierst

Bitte richte Kommentare und Fragen zu diesem Buch an den Verlag:

  • O'Reilly Media, Inc.
  • 1005 Gravenstein Highway Nord
  • Sebastopol, CA 95472
  • 800-998-9938 (in den Vereinigten Staaten oder Kanada)
  • 707-829-0515 (international oder lokal)
  • 707-829-0104 (Fax)

Wir haben eine Webseite für dieses Buch, auf der wir Errata, Beispiele und zusätzliche Informationen auflisten. Du kannst diese Seite unter http://bit.ly/21st_century_c_2e aufrufen .

Wenn du Kommentare oder technische Fragen zu diesem Buch stellen möchtest, sende eine E-Mail an

Weitere Informationen zu unseren Büchern, Kursen, Konferenzen und Neuigkeiten findest du auf unserer Website unter http://www.oreilly.com.

Finde uns auf Facebook: http://facebook.com/oreilly

Folge uns auf Twitter: http://twitter.com/oreillymedia

Schau uns auf YouTube: http://www.youtube.com/oreillymedia

Danksagungen

  • Nora Albert: allgemeine Unterstützung, Versuchskaninchen.
  • Jerome Benoit: Autoconf-Tipps.
  • Bruce Fields, Dave Kitabjian, Sarah Weissman: umfangreiche und gründliche Überprüfung.
  • Patrick Hall: Unicode Gelehrsamkeit.
  • Nathan Jepson, Allyson MacDonald, Rachel Roumeliotis, und Shawn Wallace: Redaktion.
  • Andreas Klein: weist auf den Wert von intptr_t hin.
  • Rolando Rodríguez: Testen, neugierig sein und erforschen.
  • Rachel Steely, Nicole Shelby und Becca Freed: Produktion.
  • Ulrik Sverdrup: Er weist darauf hin, dass wir wiederholte designierte Initialisierungen verwenden können, um Standardwerte zu setzen.

1 Dieses Vorwort verdankt sich ganz offensichtlich dem Buch Punk Rock Languages: A Polemic von Chris Adamson.

2 Mit Texten wie "Can't get to heaven with a three-chord song" war Sleater-Kinney vielleicht Post-Punk? Leider gibt es keine ISO-Norm für Punk, an der wir uns orientieren können, um genau zu definieren, was Punk ist und was nicht.

Get 21st Century C, 2. Auflage now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.

Start your free trial