Diskussion:C (Programmiersprache)

Feldgröße

Im Abschnitt Schwächen taucht der Begriff Feldgröße als Link auf. Dieser Link führt nur auf die physikalische Feldgröße und sollte entfernt werden. (ich entferne es nicht, falls der Autor den Artikel Feldgröße noch erweitern wollte) Frank Braun

Angebliche Mehrdeutigkeit

Der Ausdruck

a = b++ * ++b * b

ist nach den Precedenceregeln eindeutig: der Post- resp. Preincrement-Operator ++ hat eine höhere Precedenz als die Multiplikation *. Allerdings ist der Postincrement-Operator dadurch definiert, daß er den ursprünglichen Wert liefert und erst nach kompletter Auswertung des Ausdruckes auf sein Argument angewandt wird.

Die Multiplikation ihrerseits assoziiert von links nach rechts (die Increment-Operatoren von rechts nach links).

Voll ausgeklammert ergibt sich daher folgender Ausdruck:

a = (b++ * ++b) * b

Das obige Beispiel wird also wie folgt ausgewertet werden:
Schritt 1a: Auswertung des 1.Increment-Operatoren:

b++ -> b'=(b+1)

unter Beibehaltung des Originalwertes von b für die Berechnung des Gesamtausdruckes!
Schritt 1b: Auswertung des 2.Increment-Operators:

++b -> b"=(b'+1)

unter Ersetzung von b durch (b+1) für die Berechnung des Gesamtausdruckes!
Schritt 2: Auswertung der Multiplikation:

((b+1) * (b+1)) * (b+1)

Schritt 3: Ersetzen von b durch den Zwischenwert b":

b = b+2

Als Gesamtergebnis bekommt man also:

a=(b+1)*(b+1)*(b+1); b=b+2;

MikeTheGuru 16:57, 24. Feb 2004 (CET)

Wenn du die Information aus der Sprachspezifikation hast, dann nimm doch meinen Absatz raus, bzw. korregiere ihn entsprechend.Ich hab im Moment keine Unterlagen da, um deine Aussage zu be- oder widerlegen, da meine Buecher bereits den Umzug gemacht haben. Kann sein, dass ich aus dem Kopf ein falsches Beispiel gewaehlt habe, ich hatte aber zumindest vor ein oder zwei Jahren selbst ein Bespiel gesehen, wo sich die Reihenfolge der Auswertung von gcc 2.95 auf gcc 3.0 geaendert hatte, nur hab ich im Moment keine Aufzeichnungen parat, wie das genau war. Michael 09:09, 25. Feb 2004 (CET)

Die Frage ist auch, ob man diese Unvollständigkeit der Sprachdefinition unter Schwäche einordnen muss. Die Unbestimmtheit der Reihenfolge ist doch Teil der Sprachdefinition und dort ausdrücklich erwähnt. Sie ist also absichtlich vorhanden und resultiert in einfacheren Compilern und größeren Optimierungsmöglichkeiten. Schon K&R behandelt das Thema, es wurde also nicht ignorierrt oder gar vergessen. Auch, dass die Allozierung von Speichern oder das Datentyplayout nicht vorgeschrieben ist, ist Teil der Sprachdefinition und absichtlich. Also das Wort unvollständig trifft hier m.E. überhaupt nicht!!! Hierfür gab es Gründe. Das sind keine Schwächen. Hubi 09:24, 25. Feb 2004 (CET)

Zumindest nicht gegebene Auswertereihenfolge ist ein Problem bei der Portierung - wie oben gesagt, ich hab irgendwo ein Beispiel rumliegen, wo sich das Verhalten von gcc-2.95 auf 3.0 geaendert hat - und das wohl auch ganz legal geaendert hat. Wenn du sowas hast, ist das Ergebnis eines Ausdrucks einfach "unbestimmt" und das ist eben etwas, dass du eigentlich nicht brauchen kannst - was hilft dir optimaler Code, der auf jeder Plattform andere Rechenergebnisse bringt? Es ist ein Nachteil, ja. Es ist eine bewusst in Kauf genommene Schwaeche - man kann eben nicht immer alles in allen Punkten optimieren. Und hier hat man sich eben fuer Flexibilitaet des Compilierbauers zulasten der Exaktheit der Sprache entschieden. Java geht den Weg genau anders rum, und mittlerweile scheint das bischen Overhead, das dadurch teilweise entsteht, nur noch wenigen weh zu tun. Michael 12:05, 25. Feb 2004 (CET)

Wenn ich mich dann auch mal einklinken dürfte... Probleme mit Ausdrücken wie "a = (b++ * ++b) * b" sind keine Schwäche der Sprache, sondern des Programmierers, der so einen Müll schreibt. Was hilft es, wenn das genau in der Sprachspezifikation definiert ist, es aber niemand mehr entziffern kann ohne erst mal ne Viertelstunde irgendeine Spezifikation zu wälzen? Wenn ich als Programmierer die Absicht eines Ausdrucks nicht eindeutig entziffern kann, hilft es nichts, wenn es der Compiler kann. IMHO sollte der ganze Abschnitt 4.1 wg. massiv POV restlos gestrichen werden, außer es kommt ein ernsthaftes, sinnvolles Beispiel. --Andreas B. 18:56, 26. Feb 2004 (CET)

Zum Aufdröseln des Ausdrucks durch MikeTheGuru wollte ich auch nur nochmal anmerken, dass es falsch gedacht ist. Die Seiteneffekte der Ausdrücke werden irgendwann vor dem nächsten Sequenzpunkt (in diesem Fall nach der kompletten Zuweisung) ausgeführt. Wann das zwischen Sequenzpunkten passiert, ist ausdrücklich undefiniert. Präzedenz ist völlig irrelevant, Additionen und Multiplikationen stellen keine Sequenzpunkte dar. Eigentlich wurscht, den Abschnitt habe ich eh entfernt. -- Andreas B. 17:41, 1. Mär 2004 (CET)

"Unvollständigkeit der Spezifikation" entfernt

Was weg muss, muss weg. Der Abschnitt ist faktisch falsch, und dann noch als "eine der größten Schwächen von C" bezeichnet. Die genannten Beispiele sind nicht uneindeutig, sie sind sogar sehr eindeutig. In der Spezifikation steht, dass solche Ausdrücke undefiniert sind. Punkt. Wer mehr wissen will, siehe auch http://www.eskimo.com/~scs/C-faq/s3.html

Bevor jemand den Abschnitt zurückstellt, sollte er erst mal eine tatsächliche Unvollständigkeit und ein korrektes Beispiel finden. -- Andreas B. 15:16, 1. Mär 2004 (CET)

---

Falls es noch interessiert: Undefiniert sind in C z.B. folgende Ausddrücke: i++ + i++;

oder

v[i] = i++;

oder

f(v[i],i++);

(vgl. http://www.research.att.com/~bs/bs_faq2.html#evaluation-order ) SoulWind 13:55, 30. Nov 2005 (CET)

NPOV

Der Artikel ist nicht NPOV (dürftige Bibliotheken, keine Überprüfung, keine Objektorientierung). C wurde als Sprache zur Implementation eines Betriebssystems (UNIX) definiert und 1972 publiziert. Selber schuld, wenn man's für andere Zwecke einsetzt. Die Kritikpunkte können zwar erwähnt werden, aber dringend umformulieren! Hubi 09:34, 8. Feb 2004 (CET)

Ich schliesse mich Hubi's Kritik an - es sind teilweise auch einige falsche Informationen in dem Text:

• fehlende Objektorientierung: Es ist zwar wahr, dass der Sprachumfang von C Objektorientierung nicht in der Form unterstuetzt wie es z.B. C++ oder Java macht, aber es ist sehr wohl moeglich, in C objektorientiert zu programmieren - Vererbung, virtuelle Methoden und aehnliche Konzepte aus der OOP koennen sehr einfach nachgebaut werden.
• Leistungsschwache Biblitheken? Was bitte soll das denn heissen? Das Statement als solches ist eine Beleidigung all jener Leute, die C-Bibliotheken programmieren und verbreiten.

Zusaetzlich kommen die wirklichen Schwaechen von C - wie z.B. Unbestimmtheit von bestimmten Ausdruecken - nicht im Artikel vor. Michael 11:42, 9. Feb 2004 (CET)

Zur Bemerkung von Michael über OOP: OOP ist ja eben eine "Methode für das Strukturieren von Software" (siehe Objektorientierte Programmierung) und keine Spracheigenschaft. Daher hatte ich auch den Satz "C ist nicht objektorientiert" rausgenommen und durch "C unterstützt OOP nicht" ersetzt, weil meiner Meinung nach eine Programmiersprache nicht objektorientiert sein kann; vielmehr kann die Sprache objektorientierte Programmierung unterstützen. Und das macht doch eigentlich C wirklich nicht, oder!? Keine Vererbung, Klassen, etc., d.h. mens muß den ganze OOP-Krempel selbst codieren. (Das es geht ist ja, wie gesagt, nicht die Frage!)

(BTW: Wenn ich Recht habe, müßte sich auch unter echtem Ur-BASIC objektorientiert programmieren lassen! ;-) Ralf 12:49, 9. Feb 2004 (CET)

Na ja, sowas wie struct und Zeiger auf Funktionen werden schon benötigt, d.h. BASIC genügt wohl nicht. Aber Gnome-GTK und das Virtual File System im Linux-Kernel sind konkrete Beispiele in vielfachem Einsatz, wie man sowas unter C hinbekommt. Und der alte cfront von AT&T setzt auch nur C++ in C um. Hubi 13:12, 9. Feb 2004 (CET)

---

Ich finde, jemand sollte auch einen Abschnitt zu den Stärken von C schreiben, nur die Schwächen aufzulisten ist ja wohl kaum NPOV. -- 195.33.105.17 17:13, 20. Feb 2004 (CET)

---

Also Kernighan ist zwar Mitautor des Standardwerks mit D.M. Ritchie, gilt aber meines Wissens nicht als Mitschöpfer, sondern nur Richtie/Thompson Hubi 08:17, 25. Feb 2004 (CET)

Zu Portabilität. Liest man die frühen Dokumente von Ritchie/Thompson, kommt man drauf, dass die vielbeschworene Portabilität (ja C ist nun mal portabel) erst auf's Tapet kam, als sie von der alten PDP auf die neuere VAX portieren mussten. Grundgedanke von C (und Unix) ist m.E. viel mehr, generelle, jedoch überall anwendbare Konzepte zu erfinden. Portabilität ergibt sich dann im Nachhinnein. Ich erinnere mich mit einiger Wahrscheinlichkeit (weiss aber momentan die Quelle nicht so genau), dass Ritchie einmal schrieb portability was an afterthought, nämlich als sie finanzielle Mittel für die VAX beantragten. Das Design von C zeigt hier die Weitsicht ihrer Schöpfer Hubi 08:30, 25. Feb 2004 (CET)

Nochmal zu leistungsschwache Bibliotheken. Und was hatten denn die anderen Sprachen wie das z.B. die vom hochverehrten Niklaus Wirth entwickelte PASCAL? Nicht mal einen Linker. Also nicht nur leistungsschwache Bibliotheken, sondern gar keine! Bibliotheken gehören eher zum Betriebssystem/Entwicklungsumgebung als zur Sprache. Daher werd ich's entfernen. Und Wirth's gemeines und unpassendes Zitat auch (vgl. PASCAL). Hubi 08:39, 25. Feb 2004 (CET)

Portabilitätsprobleme? Der Verzicht auf genaue Längendefinition von short/int/long ermöglicht gerade die Portierung auf Itanium und auf PIC. C-Compiler gibt's für 8-Bit wie für 64-Bit und die halten sich an den Standard. Und ein frühes Unix-Programm namens lint entdeckt nicht portable Konstrukte. Mehr kann man kaum tun. Der Verzicht ist also eine Stärke von C. Sonst hätten wir PDP-gemäß vielliecht 18-Bit integer und 36-Bit long. Lange Zeit glaubten viele Programmierer, dass int, long und pointer alle 32-Bit lang wären (wie auf VAX, 68000, mit Einschränkung i386, ...) und murksten durch beliebige Typkonvertierung rum, ohne aufzupassen und sich an den Standard zu halten. Daher die Probleme mit 64 Bit-Portierungen. Hubi 08:49, 25. Feb 2004 (CET)

Mangelhafte Stringunterstützung? Wenn man die Sprachziele (einfache, generelle Konzepte) nimmt, ist mangelhaft wohl übertrieben. Und nimmt man wieder das etwa zur selben Zeit entstandene PASCAL, so sah's da noch düsterer aus (kennt jemand noch den Datentyp Alpha?). Und bei der Implementation von Betriebssystemen ist die Stringunterstützung genau richtig. Wer will da schon dynamische Allokierung haben. Niemand. Hubi 09:03, 25. Feb 2004 (CET)

Objektorientierung? Simula-67 hat dies zwar, aber das kam doch erst später. Daher kann man dies kaum der Sprache als Schwäche anlasten. Als ob die Sprache von Ignoranten, die nicht auf der Höhe der Zeit waren, entwickelt worden wäre. Werd ich einfach entfernen. Hubi 09:13, 25. Feb 2004 (CET)

Der Programmierer muss den dynamischen Speicher selbst verwalten. Hierzu stehen in der Regel Bibliotheksfunktionen zur Verfügung. Zunächst muss die erforderliche Größe an die Allokierungsfunktion übergeben werden. Die Routine gibt die Adresse zurück, die anschliessende Umwandlung in den entsprechenden Datentyp muss explizit durchgeführt werden. Die notwendige doppelte Angabe des Datentyps ist fehleranfällig. Auch die Freigabe von nicht mehr benötigtem Speicher muss über eine Bibliotheksfunktion durchgeführt werden. Sie wird oft vergessen, unbelegter Speicherplatz wird dann nicht freigegeben

Was soll der Absatz eigendlich? Dynamische Elemente muss man in fast allen Sprachen selbst anlegen, der Unterschied zwischen malloc/free und new/dispose liegt imho nur darin das ich die Größe des Speichers den ich brauche in C mit angeben muss. Freigeben muss ich den Speicher in vielen anderen Sprachen ebenfalls von Hand, ausser man hat einen garbage collector. Was die Typumwandlung angeht, ich hab zwar schon ewig keinen k&r compiler mehr benutzt aber das der überhaupt eine warnung bei "struct whatever_t *s = malloc(sizeof(struct whatever_t));" statt "struct whatever_t *s = (struct whatever_t *)malloc(sizeof(struct whatever_t));" ausgeben würde, das wage ich zu bezweifeln. Das man den Typ ein paar mal schreiben muss, seh ich ein aber irres ge'cast'e gibt auch in moderneren Sprachen ;-) Im übrigen das hat wenig mit dem Thema "Speicherverwaltung" zu tun, darunter würde ich verstehen das man die komplette Verwaltung des Heap von Hand machen müsste.195.243.149.235 20:53, 25. Feb 2004 (CET)

Na ja, aber da gibt's immer wieder Probleme. Der ursprüngliche Artikel hatte einen Abschnitt Speicherverwaltung, der noch schlechter war. Das mit dem cast/sizeof kann man in C ja elegant durch ein Makro lösen :-). Allerdings sehe ich schon ein Problem (doppeltes free, falsche Pointerübergabe). Also kommt das wieder raus, ok? Hubi 07:27, 26. Feb 2004 (CET)

Ich hab mal den ersten Satz dringelassen. Die Speicherverwaltung ist meines Erachtens ein Manko. Bei Bedarf ändern oder ganz weg. Hubi 07:38, 26. Feb 2004 (CET)

Zur nachträglichen Aufklärung: malloc() gibt ein void* zurück und void* kann ohne expliziten Cast in jeden anderen Zeiger verwandelt werden. Einen expliziten Cast zu verlangen wäre bei einem Zeiger auf ein void auch grenzdebil. --Andreas B. 00:22, 27. Feb 2004 (CET)

Zur nachnachträglichen Aufklärung. void * ist nicht Bestandteil von K&R C Hubi 10:17, 27. Feb 2004 (CET)

---

Ich ahne Kritik, die sich über meine brutale Änderung zusammenbraut, daher sollte ich das ausführlicher erklären:

• fehleranfällig/produktiv sind Programmierer. Es gibt eigentlich recht saubere/schnelle C kompiler. Natürlich hat die Sprache Einfluß darauf, wie leicht dem Programmierer Fehler passieren/wie schnell sich ein Programm entwickeln läßt. Die Ansicht das mit C leichter Fehler passieren als mit anderen Sprachen sollte man daher:
  • klarer formulieren was gemeint ist
  • als oft gehörte Kritik und nicht als Tatsache dastellen
  • den Zusammenhang mit einem bestimmten Anwendungsgebiet deutlich machen
• ob die Bibliotheken »zugehörig« sind oder nicht sollte keine Rolle spielen. Es gibt genügend leistungsfähige Biblotheken in und für C.

Ich schlage vor, dass wir langfristig versuchen, Tatsachen über C und Meinungen über C in getrennten Kapiteln unterzubringen. --Hokanomono 16:39, 7. Mär 2004 (CET)

---

Ich finde es etwas seltsam als Schwäche von einer der portabelsten Sprachen überhaupt von Portabilitätsproblemen zu sprechen... Und das (eine der portabelsten) war sie schon *bevor* der fixed-size types aus ISO C...

--TooLazyToSignUp ;)

---

Literaturliste

Die Literaturliste ist viel zu lang, außerdem fehlen die Jahreszahlen. Meines Erachtens handelt es sich nicht ausschließlich um wesentliche Literatur, da viele Bücher auf Verlagen stammen, die nach meiner Erfahrung eher das Konzept Masse statt Klasse verfolgen und oft Laien als Autoren beschäftigen (M+T, Franzis, Econ etc.). Sollte man kürzen --Hubi 12:10, 4. Mai 2004 (CEST

---

Die englische Version macht einen ziemlich guten Eindruck, auch bzgl. ausführlicher Erklärung verschiedener Sprachstandards usw. Es wäre schön, wenn sich mal jemand, der im Moment mehr Zeit hat als ich, die Mühe machen könnte, das in die deutsche zu übernehmen. Mh 16:03, 21. Mai 2004 (CEST)

Die Standardbibliothek

Die Standardbibliothek ist Bestandteil der Sprache C. Sie sollte also in jedem Fall im Abschnit "Programmieren in C" angesprochen werden. --Claudio Carobolante 14:09, 14. Jul 2004 (CEST)

Löschung von Abschnitt "Programmieren in C"

Sollte der Abschnitt konsequent ausformuliert werden, dann ist mit einer Flut von Artikeln zu rechnen. Die Diskussion um assert.h lässt mich vermuten, dies ist nicht erwünscht. Auch kann "Wikipedia:Was_Wikipedia_nicht_ist" entsprechend interpretiert werden.

Ich schlage daher vor, den Abschnitt "Programmieren in C" ersatzlos zu löschen. In der Konsequenz habe ich ebenfalls die Löschung der Seiten Anweisung (Programmiersprache C), Kommentar (Programmiersprache C) und Schlüsselwort (Programmiersprache C) beantragt. --Claudio Carobolante 17:22, 14. Jul 2004 (CEST)

Erstaunlich. Gerade als Benutzer angemeldet und schon auf einem Löschkreuzug quer durch die Wikipedia. Erstaunlicherweise kennst Du Dich dennoch mit den "Internas" der Wikipedia bestens aus. Ich glaube daher, dass das ein (weiterer?) Fake-Account zum Löschen von Inhalten ist. Denn produktiv trägst Du nicht bei. Diese Form des Löschens ist Vandalismus in Reinform. Darf ich Dich Benutzer:Checkup nennen oder besser Benutzer:Sprezzatura?! Du hast etwas gegen Wissen und Information. TG 00:34, 15. Jul 2004 (CEST)

Erstaunlich. Nephelin hat offensichtlich nicht geschaut, wer die Artikel geschrieben hat. Claudio beantragt die Artikel zu löschen, die er selbst geschrieben hat. Du solltest Dich bilden, statt dumm hier bemühte Schreiber zu diffamieren. --84.129.94.148 11:50, 15. Jul 2004 (CEST)

Hallo TG. Deine Behauptung, ich würde nichts produktives beitragen, ist grob unverschämt. Schau in die Historie der Seiten, die ich für die Löschung vorgeschlagen habe. Dort wirst Du von meinem Namen regelrecht erschlagen werden. Du bist ein Troll, und als solcher hast Du auch das richtige Thema für Deine Seite gewählt. Nur fehlt dort ein Verweis auf Deine Person. OK, wie auch, Du bevorzugst es, annonym Deine Unverschämtheiten zu veröffentlichen. Du darfst mich weder Checkup noch Spezzatura nennen. Ich habe einen Namen und den habe ich auch angegeben. --Claudio Carobolante 18:37, 15. Jul 2004 (CEST)

Da die Seiten über Anweisungen, Kommentare und Schlüsselwörter nicht gelöscht wurden, sehe ich keinen Grund mehr, warum der Abschnitt "Programmieren in C" entfernt werden sollte. Daher ziehe ich meinen Antrag zurück. Ich möchte jedoch mein Bedauern über die Löschung der Seite über den Header assert.h deutlich zum Ausdruck bringen. In der gleichen Konsequenz mit der Löschung der Seite über den Header assert.h ist beispielsweise ebenso eine Seite über den Header stdio.h und somit eine Beschreibung der Funktion printf ausgeschlossen worden. Somit ist die Möglichkeit eines Verweises in Beispielen welche Bibliotheksfünktionen nutzen nicht mehr möglich. Ebenso ist eine Erklärung der häufigsten Fragen die mit der Standardbibliothek zusammenhängen unmöglich gemacht worden. --Claudio Carobolante 02:56, 20. Aug 2004 (CEST)

Kontrollstrukturen

Die Informationen bei "Kontrollstrukturen" sind falsch. Wie sie richtig definiert sind, stand schon mal da. Der Schreiber sollte sich Mühe geben oder die Finger von der Tastatur lassen. --217.233.246.12 14:38, 15. Jul 2004 (CEST)

Bei mir auf nem XP System mit Firefox 0.9 erscheinen alle Sonderzeichen in einem schwarzen FragezeichenSymbol

Thematik des Artikels (Neu im Okt. 2004)

Der Artikel sollte nicht auf Artikel zu diversen Details (Geltungsbereich von Bezeichnern (Programmiersprache C), Bindung von Bezeichnern (Programmiersprache C), u.s.w.) verweisen. Der Ehrgeiz, hier ein Lehrbuch oder eine Sprachreferenz aufzubauen, ist verfehlt.

Zu den Begriffen "Ausdruck" und "Anweisung" u.s.w. kann erstens auf die allgemeinen Artikel in der Wikipedia zu diesen Themen verwiesen werden (die nicht speziell auf C gemünzt sind).

Was sich bei den C-Begriffen dann von den allgemeinen noch unterscheidet, in allgemeinen Worten beschreiben.

Stellt Euch vor, ein Deutschlehrer oder ein Architekt liest den Artikel, um erfahren, was "C" ist. Da sind Details, wie "dieses Semikolon wird leider oft vergessen" fehl am Platz, die gehören eher in ein Lehrbuch. Eine vollständige Beschreibung der Syntax einer Anweisung gehört in ein Nachschlagewerk. In eine Enzyklopädie paßt eine allgemeine Charakterisierung der Sprache.

Für die Details, Lehrwerke ( http://de.wikibooks.org/wiki/C-Programmierung ) und Nachschlagewerke sollte man dann Verweise verwenden, wie ja auch teilweise schon geschehen.

Wer ein Lehrbuch schreiben will, kann am obigen Wiki-Buch mitarbeiten, eine Referenz kann darin auch als Anhang untergebracht werden.

217.231.94.148 16:06, 6. Okt 2004 (CEST)

Voll Zustimmung. Siehe dazu auch den Löschantrag für Ausdruck (Programmiersprache C) vom 5.10.2004: Wikipedia:Löschkandidaten/5._Oktober_2004#Löschantrag zu Ausdruck (Programmiersprache_C). -- D. Düsentrieb ⇌ 17:20, 6. Okt 2004 (CEST)

Ebenfalls Zustimmung. Anweisung (Programmiersprache C) und Kommentar (Programmiersprache C) koennen wohl auch mehr oder wenige in die Referenz von http://de.wikibooks.org/wiki/C-Programmierung, so wie z.B. http://de.wikibooks.org/wiki/C-Programmierung:_Schlüsselwörter und http://de.wikibooks.org/wiki/C-Programmierung:_Ausdrücke_und_Operatoren existieren. Und falls ein Leser es noch nicht gesehen hat: Wikipedia:Löschkandidaten/5._Oktober_2004#Löschantrag_zu_Ausdruck_(Programmiersprache_C) --Sig11 15:02, 7. Okt 2004 (CEST)

----

Kann nicht einer im Artikel angeben, wo es den 3742 Bytes großen C Compiler gibt? Mich würde das sehr interessieren.

Schwächen

C schreibt die Speichergröße verschiedener Typen in der Sprachdefinition nicht vor. Dies ermöglicht die Portierung bestehender Programme auf andere, auch neue Prozessoren. Es ist nur zugesichert, dass ein short int nicht länger sein darf als ein long int. In den 1980er und 1990er Jahren wurden vorwiegend 32-Bit Systeme wie VAX, 68000, i386 eingesetzt. Bei diesen waren Zeiger, int und long alle 32 Bits lang, so dass sich dies als Quasistandard etabliert hat. Dies bereitet Probleme bei der Portierung auf modernere 64-Bit-Architekturen, falls der Programmierer von bestimmten Längen ausgegangen ist. würde ich gern entfernen. Das ist keine Schwäche von C (zumindest keine die über "wilde Zeiger" hinausgeht, sondern eine schwäche der Programmierer. In jedem vernünftigen C-Buch steht, man soll nicht davon ausgehen, das Zeiger die selbe Grösse hätten wie int-Varablen. Oder seh ich das falsch?--EoltheDarkelf 01:41, 21. Apr 2005 (CEST)

Ich stimme dem zu. Abgesehen davon ist der Satz C schreibt die Speichergröße verschiedener Typen in der Sprachdefinition nicht vor. IMHO so nicht korrekt / missverständlich. Beispielsweise schreibt der Standard vor, dass der Typ short int mindestens Werte zwischen -32.767 und +32.767 aufnehmen kann - und eben nicht nur, dass ein short int nicht länger sein darf als ein long int. -- Daniel 00:53, 26. Mai 2005 (CEST)

---

C sollte ein scherz sein

In einer Anküdigung, die die Computer-Industrie verblüffte, haben Ken Thompson, Dennis Ritchie und Brian Kerninghan zugegeben, dass das von ihnen geschaffene Betriebssystem Unix und die Programmiersprache C ein raffinierter Aprilscherz sind, der sich über 20 Jahre am Leben erhalten hat. Bei einem Vortrag vor dem letzten UnixWorld-Software-Entwicklungsforum enthüllte Thompson: "1969 hatte AT&T gerade die Arbeit am GE/Honeywell/AT&T-Multicasprojekt beendet. Brian und ich experimentierten zu diesem Zeitpunkt mit einer frühen Pascal-Version von Professor Niklaus Wirth vom ETH-Laboratorium in der Schweiz und waren beeindruckt von seiner eleganten Einfachheit und Mächtigkeit. Dennis hatte gerade 'Der Herr der Klinge' gelesen, eine spöttische Parodie auf Tolkiens große Trilogie 'Der Herr der Ringe'. Im Übermut beschlossen wir, Parodien zur Multics-Umgebung und zu Pascal zu verfassen.

Dennis und ich waren für die Betriebssystemumgebung verantwortlich. Wir sahen uns Multics an und entwarfen ein neues System, das so komplex und kryptisch wie möglich sein sollte, um die Frustration der gelegentlichen Nutzer zu maximieren. Wir nannten es Unix in Anspielung auf Multics und fanden es auch nicht gewagter als andere Verballhornungen.

Danach entwickelten Dennis und Brian eine wirklich perverse Pascal-Version names 'A'. Als wir bemerken, daß einige Leute tatsächlich versuchten, in A zu programmieren, fügten wir schnell einige zusätzliche Fallstricke hinzu und nannten es 'B', 'BCPL', und schließlich 'C'. Wir hörten damit auf, als wir eine saubere Übersetzung der folgenden Konstruktion erhielten:

for(;P("\n"),R--;P(";")) for(e=E;e--;P("_"+(*u++/8)%2)) P(" "-(*u/4)%2);

Der Gedanke, daß moderne Programmierer eine Sprache benutzen würden, die solch eine Anweisung zuließ, lag jenseits unseres Vorstellungsvermögens. Wir dachten allerdings daran, alles den Sowjets zu verkaufen, um ihren Computer- Fortschritt 20 Jahre und mehr zu verhindern.

Unsere Überraschung war groß, als dann AT&T und andere US-Unternehmen tatsächlich begannen, Unix und C zu verwenden! Sie haben 20 weitere Jahre gebraucht, genügend Erfahrung zu sammeln, um einige bedeutungslose Programme in C zu entwickeln, und das mit einer Parodie auf die Technik der 60er Jahre ! Dennoch sind wir beeindruckt von der Hartnäckigkeit (falls nicht doch Gemeinsinn) des gewöhnlichen Unix- bzw. C-Anwenders. Jedenfalls haben Brian, Dennis und ich in den letzten Jahren nur in Pascal auf einem Apple Macintosh programmiert, und wir fühlen uns echt schuldig an dem Chaos, der Verwirrung und dem wirklich schlechten Programmstill, der von unserem verrückten Einfall vor so langer Zeit ausging."

Namhafte Unix- und C-Anbieter und Benutzer, einschließlich AT&T, Microsoft, Hewlett-Parkard, GTE, NCR und DEC haben vorläufig jede Stellungnahme abgelehnt. Borland International, ein führunder Anbieter von Pascal- und C- Werkzeugen, einschließlich der populären Turbo Pascal, Turbo C und Turbo C++, meinte, sie hätten diesen Verdacht schon seit Jahren gehegt und würden nun dazu übergehen, ihre Pascal-Produkte zu verbessern, und weitere Bemühungen um die C-Entwicklung stoppen.

CS 28.04.2005

---

Das klingt nett, aber kann man die Quelle dazu angeben? Almdudi 13:59, 10. Dez 2005 (CET)

Literaturhinweis

Joachim Goll, Ulrich Bröckl, Manfred Dausmann: C als erste Programmiersprache - Vom Einsteiger zum Profi, Teubner, ISBN 3-519-32999-9

Manfred Dausmann oder Michael Dausmann? Quellen gibt's für beide Varianten, Michael wird allerdings wesentlich häufiger genannt. -- RainerBi ✉ 12:04, 2. Mai 2005 (CEST)

div. Haarspaltereien

stdio.h erklärt; "hosted" überall da eingefügt, wo es fehlte (hrmpf!), "Performanz" entschärft - das ist ein Märchen, guckt euch mal den Assembler-Output an, C hat Eigenschaften, die Optimierung geradezu verhindern, z.B. die ganze Pointer-Aliasing-Geschichte; dass C-Programme fix sind, liegt daran, daß die anderen Sprachen noch lahmer sind, OOP-Bloatgeil sind oder ihre Programmierer knechten. Daß C ein Highlevel-Assembler ist, wird dadurch "widerlegt", daß man Betriebssysteme in C schreibt?!!! Oh Mann. (und allein die *Idee* ein OS in C++ zu schreiben.. oh gott. operator knew oder was?!). "Algorithmen" entfernt (was soll das?) --Miez 08:23, 13. Jun 2005 (CEST)

Insgesamt finde ich Deine Änderungen nicht sehr gelungen. Zu einigen tiefergehenden fachlichen Aspekten kann ich nichts sagen, aber was haben Bemerkungen wie kleinen Text gibts leider nicht (Doch, gibts? Oder worauf bezieht sich das?) oder Hinweis: Solche Programme tun für gewöhnlich nichts Nützliches. in einem Enzyklopädie-Artikel zu suchen? Auch was ein ("hosted") C-Compiler ist erschliesst sich dem Laien kaum und trägt nicht gerade zur Klärung bei. Auch der Sinn Deiner Löschungen bei den Stärken und Einfügungen bei den Schwächen (was bitte ist ein Carry-Flag?) erschliesst sich mir nicht. Bitte bedenke das der Artikel sich nicht in erster Linie an C-Cracks, die sowieso schon alles wissen was darin steht, richten sollte, sondern dem (interesierten) Laien Informationen liefern soll. Und da sind Deine Änderungen leider wenig hilfreich. Trotzdem möchte ich nicht alles einfach reverten, sondern Dich bitten, Deine Änderungen unter den oben genannten Gesichtspunkten nocheinmal zu überarbeiten.--EoltheDarkelf 14:23, 13. Jun 2005 (CEST)

Stimmt, kenne nicht jeden Wikibefehl auswendig. Wird ausgebessert. Das nix Nützliches war ein SCNR. Ich formuliere das mal in Richtung erträglich um (oder versuche es zumindest). Bei hosted und Carry schau ich mal. --Miez 16:29, 13. Jun 2005 (CEST)

Der Quatsch mit "sooo viele Betriebssysteme in C geschrieben beweisen, daß C kein Highlevel-Assembler ist" wurde wieder eingefügt. "Ich glaube nicht, daß es draußen regnet, denn es sieht so feucht aus", oder was? Bei einem Betriebssystem will man einen portablen Highlevel-Assembler, das war ja das Tolle an C und UNIX (vor C wurden die nämlich mühselig in Assembler geschrieben). Und Betriebssysteme in C++ ... ach macht doch was ihr wollt ;( --Miez 06:54, 14. Jun 2005 (CEST)

Lass Dir doch von unkommunikativen IP's nicht die Lust verderben! Das kommt leider immer mal wieder vor, dass jemand ohne irgendeine Begruendung was aendert, und man sich wundert, was das soll. Vor allem IP's tendieren dazu. Das gibt sich - oder man gewoehnt sich dran - ja nachdem :-). Zum konrekten Fall: der Abschnitt "Ueberblick" sieht aus wie ein Sammelsurium von Fakten, die immer mal wieder jemand eingefuegt hat - ohne dass diejenigen den Abschnitt als Ganzes bearbeiten wollten - auch das passiert hier leider zimlich oft (macht aber wohl jeder - ist Wiki-bedingt). Wenn das als Ganzes umgearbeitet wuerde, wuerde wohl irgendow wieder was von Kernels stehen - aber halt im richtigen Zusammenhang. Dann waere wohl jeder gluecklich. Nut trau ich mich nicht an sowas ;-) --Sig11 ? 10:38, 14. Jun 2005 (CEST)

Literaturliste, Weblinks und Bewertung der Sprachmerkmale

Der Artikel ist momentan in wirklich keinem besonders guten Zustand. Besonders störend ist die ellenlange Liste der Vor- und Nachteile von C und die lange Literaturliste und schlecht ausgesuchten Weblinks. Bei der Literaturliste scheint mir inzwischen bald jedes Anfängerbuch über C aufgelistet zu sein. Weiter Meinungen? Ideen wie man weiter vorgehen kann? -- Daniel 19:14, 11. Jul 2005 (CEST)

Bezüglich der Literatur- und Linkliste kann ich dir nur zustimmen. Schmeiß raus was nicht reinpasst!
Die Liste der Vor- und Nachteile könnte man vielleicht in Fließtext umwandeln. --Kadeck 17:49, 27. Aug 2005 (CEST)

Newbiefrage

Ich habe WinXP, wie starte ich da das C-Programm? Oder muss ich es mir erst herunterladen und installieren? Ich meine, einfach so mit cmd die DOS-Box öffnen und programmieren ist ja nicht. Wo also gebe ich die C-Programmbefehle ein? 84.172.209.147 03:41, 12. Jul 2005 (CEST)

Wie bei allen Programmiersprachen wird ein Interpreter oder Compiler benötigt. Ersterer führt die Programmzeilen direkt aus, zweiterer macht ein klassischen Programm (beispielsweise .exe) aus dem Quelltext. Bei C wird üblicherweise ein Compiler verwendet, ich weiss jedenfalls von keinem C-Interpreter. Bei Windows ist meines Wissens kein C-Compiler dabei. Aber Du kannst ja mal eine Suchmaschine anwerfen, es gibt viele kostenlose C-Compiler, da wird doch der eine oder andere für Windows dabei sein. -- Dishayloo [ +] 10:49, 12. Jul 2005 (CEST)

Probier mal DevCpp - hat eine nette GUI, ist relativ einsteigerfreundlich (im Vergleich zu anderen IDEs) und kostenlos bzw. sogar Open Source! Xell 16:10, 12. Jul 2005 (CEST)

Am besten im Zusammenhang mit einen guten Anfängertutorial --Jonathan Hornung 08:23, 31. Jul 2005 (CEST)

Was ich nicht ganz glauben kann: Dass Windows keinen eingebauten Interpreter/Compiler haben soll. Aber zuzutrauen wärs denen ja. 84.172.215.166 13:13, 2. Aug 2005 (CEST)

Ein Interpreter für C - das wär wohl die Lahmheit in Person. (Ich meine, mich erinnern zu können, von sowas mal gehört zu haben - lang ists her!) Aber ein interessantes Projekt. Sollte man mal den GCClern andienen. Unter XP gibts mit Sicherheit keinen C-Compiler. Wofür auch? Der Kernel wird gekauft, mit einigem Geld bezahlt und mit mehreren hundert MB DLLs auf der Platte verfeinert. Es braucht keine Neucompilate wie bei Linux, wenn man mal was neues einbauen möchte. Einfache eine neue DLL - und scho isch de Kiddl gflickt. Und wenn man Office sein eigen nennt - VBA ist auch noch verfügbar. NIL Problem... Im Übrigen: My favorite free C: LCC (Little C Compiler)

Zur ursprünglichen Frage: C-Programmbefehle gibt man in ein Textfile mit der Endung „.c“ ein. Diese wiederum gibt man einem C-Compiler (hinter dem wiederum ein Linker hängen muß) als Futter, der wiederum daraus ein ausführbares Programm mit der Endung „.exe“ macht. Dieses File wiederum kann XP als Programm ausführen. Es macht dann das, was die Prammbefehle im auftragen.

Ein „C-Programm“ in dem Sinn wie z.B. EXCEL oder Paint gibts so nicht. Normalerweise redet man in dem Zusammenhang von einer „Integrierten Entwicklungsumgebung“, neudeutsch IDE (Integrated Development Environment, was auch mein geliebter LCC ist). Die liefert alles, was man zur Entwicklung von Programmen in der Programmiersprache C braucht: Texteditor (schreiben der Programmbefehle), Compiler (Übersetzen der Programmbefehle in Maschinencode), Bibliotheken (für Funktionen, die man nicht selbst schreiben muß), Linker (der den ganzen Gammel in ein ablauffähiges Programm zusammenbaut). --Harald Wehner 02:22, 6. Okt 2005 (CEST)

Fehlende Relevanz

Eine exotische Programmiersprache namens "GOC" hat nicht den gleichen Stellenwert wie z.B. C++. Dies sollte auch im Artikel nicht so dargestellt werden. Daher habe ich den Eintrag wieder entfernt. --Kadeck 11:15, 13. Aug 2005 (CEST)

-62.180.172.92 19:50, 25. Aug 2005 (CEST) GOC ist keine exotische Programmiersprache, sondern C mit erweiterten Befehlen zur objektorientierten Programmierung und dies sehr viel mächtiger als in C++. GOC IST C. Also hat es hier was zu suchen.

GOC ist nicht C. Warum schreibst du nicht über GOC einen eigenen Artikel? :-) --Kadeck 17:55, 27. Aug 2005 (CEST)

Hallo-Welt-Programm: printf oder puts?

Gibt es irgendeinen tieferen Grund für die komplizierte Variante

printf("%s", "Hallo Welt!\n");

wenn man auch einfach

puts("Hallo Welt!");

schreiben könnte?--Gunther 15:48, 21. Sep 2005 (CEST)

Gute Idee! Ich bin für puts. Auf keinen Fall printf ("Hallo Welt!\n"); wie es verbreitet ist. -- Hokanomono 16:00, 21. Sep 2005 (CEST)

printf wird auch in K&R benutzt und wurde in vielen anderen Büchern so übernommen. Ich sehe da auch keine großen Vorteile puts zu benutzen. Das "%s" ist sowieso überflüssig. -- 141.70.109.83 10:08, 22. Sep 2005 (CEST)

Ich hab die Bibel nie gelesen: Hat K&R eigentlich schon puts() - oder ist das später dazugekommen? --Harald Wehner 02:27, 6. Okt 2005 (CEST)