Diskussion:C (Programmiersprache)

aus Wikipedia, der freien Enzyklopädie

Du hast neue Nachrichten (Unterschied zur vorletzten Version).

[Bearbeiten] Header

Die Theorie zur Entwicklung des Namen ist umstritten. Es wäre schön wenn jemand auch die anderen Theorien darstellen könnte.

[Bearbeiten] 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

[Bearbeiten] 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)

[Bearbeiten] "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)

[Bearbeiten] 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 ;)

[Bearbeiten] 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)

[Bearbeiten] 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)

[Bearbeiten] 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)

[Bearbeiten] 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

[Bearbeiten] 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)

[Bearbeiten] ----

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

[Bearbeiten] 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)

Hi ich finde den Letzten abschnitt Mangelnde Eignung für größere Projekte ist doch irgendwie durch den Abschnitt Stärken Fast alle Kernels der bekannten Betriebssysteme sind in C implementiert. widerlegt. bin also für das löschen, da es offensichtlich eine ganze Menge von großen Projekten gibt die sich unter C Programmieren lassen. Auch die Aussage: Die Speicherverwaltung ist fehleranfällig halte ich in dieser form für reihe Polemik. sie ist nicht schlimmer als anderen Sprachen, malloc & Co liefern im Fehler fall null zurück das kann man anfragen. Eine Exectipon muss nicht sein. Also sollte diese Aussage etwas Konkretisiert werden oder ersatzlos gestrichen. Imon 12:50, 05. Juni 2006 (CEST)

Der Widerspruch liegt leider in C selbst. C ist geeignet für große Projekte und wurde und wird immer wieder dafür eingesetzt. Und C ist gleichtzeitig völlig ungeeignet, weil es fast sämtliche Erkenntisse der modernen Softwaretechnik ignoriert. Der C-Standard verhindert ja sogar einen C-Compiler, der auch nur eine Option "Feldgrenzenprüfung" zuläßt. Das geht in C einfach nicht. Viele große Projekte könnten mit anderen Sprachen schneller und mit besserem Ergebnis programmiert werden. Die Existenz großer verwendbarere Libraries in C ist oft das einzige Argument für die Wahl dieser Programmiersprache. Und natürlich das klassische "das ham wir schon immer so gemacht". Viele Programmierer sind in C ausgebildet und programmieren in C; Viele Softwarefirmen haben große Teile ihres Codes in C; ein Umstieg zu anderen Sprachen bedeutet Aufwand (Lernaufwand) und Kosten.

[Bearbeiten] 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)

Der Text Stammt wohl von Netzmafia.de. Als Quelle ist dort angegeben "Quelle: Bernhard L. Hayes, NetNews-Gruppe"

[Bearbeiten] 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)

[Bearbeiten] 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)

[Bearbeiten] 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)

Ich finde die Literaturliste ist mittlerweile viel zu kurz geraten - einzig auf Kernighan&Ritchie zu verweisen finde ich beileibe nicht ausreichend; natürlich gehört es mit in die Liste, aber kein Mensch lernt wirklich nur anhand diesen Buches. Drum werde ich nun wieder mein favourisiertes (noch dazu nativ deutsches) Buch eintragen, welches sich sowohl für den Einsteiger als auch den ambitionierten Nutzer zu lesen lohnt. Des Weiteren hoffe ich, dass es nicht wieder binnen eines Monates aus der Liste verschwindet, denn ich gehe stark davon aus, dass Menschen sich positiv daran bereichern können. Darüber hinaus gibt's von mir noch einen Weblink, denn das Buch gibt es auch frei verfügbar im Netz - auch das passt meiner Ansicht nach viel besser als ein Link auf "Programming in C" aus dem Jahr 1974! --preek Thu Dec 29 20:46:21 CET 2005

[Bearbeiten] 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)

Cinterpreter gibt es mehrere. Zum einen das undürchschaubare cint([1]), das nochnichteinmal bison oder lex benutzt, aber immerhin sich selber interpretien kann und cinter([2]), die Entwicklung scheint eingeschlafen zu sein, es läuft aber manches. Schlecht ist das aber nicht wenn man mal eben ein kleines Programm mit ca20 zeil zum Luafen bringen will.(beide könne auch c++)

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)

[Bearbeiten] 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)

[Bearbeiten] 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)

Also zumindest in der 2. Ausgabe finden sich hinweise zu Puts sowohl in dem I/O Abschnitt als auch im Appendix B

Der Hauptgrund für printf ist seine Vielseitigkeit. Gerade in einem Lehrbuch (und das war K&R) sollten am Anfang nicht zu viele Konzepte gleichzeitig vorgestellt werden. printf ist für sehr viele Arten von Ausgabe geeignet (Strings, Zahlen in verschiedensten Formaten, Zeichen). Die Alternative wäre gewesen, puts für das Hello-World-Beispiel zu verwenden und danach nie wieder. --RolandIllig 22:17, 8. Jan 2006 (CET)

Ich halte es nicht fuer sinnvoll printf einzufuehren, es schaft komplexitaet die man als anfaenger eher umgehen sollte und die in einem Beispiel nichts zu suchen hat. Wenn man schon printf benutzen moechte, dann bitte auch mit printf ("%s\n", "Hello, world"). -- FaUl

Wieso nicht printf("Hello%s%c\n", ", world", '!');? Die einfachste printf-Variante ist wohl printf("Hello, world!\n"); und so wuerde das wohl auch nahezu jeder schreiben. Daran ist nichts komplex oder undefiniert und es ist auch kein Sicherheitsproblem. Problematischer dagegen finde ich dagegen puts() und aehnliches zu verwenden ganz besonders da fputs() im Gegensatz zu puts() keinen Zeilenumbruch anhaengt. Diese Funktionen sind prinzipiell voellig ueberfluessig und verwirren bloss. Um *printf() kommt man als C-Programmierer sowieso kaum herum und die Komplexitaet haelt sich fuer das Gros der Anwendungsfaelle nun wirklich in Grenzen. --82.141.61.74 15:47, 20. Jan 2006 (CET)

[Bearbeiten] "Gleiches Verhalten"

Folgenden Abschnitt berichtigt: "Verwendet ein Programm lediglich den Sprachkern gemäß der Sprachdefinition und die Standardbibliothek, so ist es auf jedem System, das einen ANSI-kompatiblen Compiler zur Verfügung stellt, übersetzbar und zeigt auch auf allen Systemen das gleiche Verhalten."

Beispiel für einen Progammausschnitt, der die Aussage widerlegt:

 long l;
 char* str = "----++++" ;
 strncpy(str, &l, 4);

--84.163.185.101

Das ist zwar syntaktisch in Ordnung, aber semantisch gesehen, ist das Verhalten ab der 3. Zeile undefiniert. "Gleich" ist natuerlich wie bei jeder Sprache etwas relativ zu sehen, z.B. kann die Ausgabe auf einem Farbbildschirm, einem Drucker, einem Dummy-Terminal oder was auch immer geschehen. --82.141.61.74 15:36, 20. Jan 2006 (CET)

[Bearbeiten] C++ in der Einleitung

Was hat denn C++ in der Einleitung eines Artikels über C zu suchen? Wenn überhaupt, gehört sowas ans Ende in ein »siehe auch ...«. -- Pingi 21:34, 28. Feb 2006 (CET)

Naja - anscheinend macht hier jemand werbung für C++ - sonst müsste ja auch Objective-C erwähnt werden. Hab den absatz sogar schon mal rausgelöscht, aber ein paar tage später war er wieder da. --Liebeskind 20:35, 25. Sep 2006 (CEST)

Sehe auch keinen Grund dies so explizit bereits in der Einleitung hervorzuheben. Der Satz "Zahlreiche weitere Sprachen, wie..." bringt den notwendigen Querverweis zu den anderen Sprachen und dort werden dann auch die Details besprochen. Wenn es keine begründeten Einwände gibt, werfe ich den Abschnitt wieder raus. --Revvar (D RT) 08:35, 26. Sep 2006 (CEST)

Man könnte ja stattdessen weiter unten einen absatz machen, in dem eben solche versuche C um objektorientiertheit zu erweitern (wie etwa C++ und Objective-C und gegebenenfalls andre die ich noch nicht kenne) aufgelistet werden. --Liebeskind 16:17, 26. Sep 2006 (CEST)

[Bearbeiten] "aufwärtskompatibel" - schreibfehler?

Im ersten Absatz heißt es Die wesentlich neuere Sprache C++ stellt eine annähernd aufwärtskompatibele Weiterentwicklung von C dar und wurde gegenüber C unter anderem um Möglichkeiten zur objektorientierten und generischen Programmierung erweitert.. Müßte es nicht (abgesehen davon dass es falsch geschrieben ist) abwärtskompatibel heißen? Oder will der Autor spitzfindig ausdrücken, dass c++ aufwärtskompatibel sein wird? Grüße Hoderlump 13:41, 24. Apr 2006 (CEST)

[Bearbeiten] IRC

Hab den Dummfug gelöscht der seit ein paar Tagen unter dem Titel "IRC" zu finden war, hoffe das geht in Ordnung. -- 138.190.15.46 10:50, 24. Mai 2006 (CEST)

[Bearbeiten] Impliziter Kode

Danke fuer die Eroeffnung des Edit-Wars... Kannst Du mir mal erklaeren, wie Du Dir das vorstellst? Soll ich jedesmal, bevor ich mein Wissen beitrage, es erst ausdiskutieren? Soll ich Dir jetzt eine Abhandlung ueber Kompilerbau geben? Oder besser dem Anonymous? --Montauk 23:03, 19. Jun 2006 (CEST)

Du gehoerst zu den Leuten, die mir die Wikipedia verleiden. Meine Zeit ist mir zu schade, um mein Fachwissen, das ich tagtaeglich an einer Hochschule vermittle, in dieser Weise in Frage stellen zu lassen. Ich habe nichts gegen unmittelbare Sachdiskussion einzuwenden (die der Anonymous haette eroeffnen muessen), aber ich werde mich nicht gegenueber dem selbsternannten Wikipolizisten Kadeck rechtfertigen. Basta. --Montauk 17:21, 25. Jun 2006 (CEST)

Was ist denn kurz gesagt ein „impliziter Programmcode“? Mir fällt da ad hoc so was wie „isxxx“ ein. Den Begriff habe ich aber als jahrelanger Praktiker bislang noch nirgends gelesen. Ich bin weit weg von der Uni... --Harald Wehner 22:51, 26. Jun 2006 (CEST)

Harald, gerne waere ich auf einen Diskussionsbeitrag wie den Deinigen eingegangen. Aber meine Zeit mit Wikipedia ist vorbei. Sie ist zu kostbar, um Leuten wie Kadeck Einhalt zu gebieten. --Montauk 14:39, 8. Jul 2006 (CEST)

@Montauk, du kannst diese Art der Diskussionen umgehen, indem du in der Zusammenfassung gleich eine Quelle angibst (wissenschaftliches Arbeiten geht dir ja sicher leicht von der Hand, bei deinem Hintergrund). Das du es selbst hier weniger bei Anderern sehen wirst, das gute Quellenangaben auch ohne Aufforderung dazugepackt werden, ist imho ein großes Problem der WP. Also schlaf bitte einfach noch ein paar Nächter über deinen Ausstieg hier - bei zukünftigen Problemen helfe/vermittle ich gerne. Schönen Gruß --Revvar (D RT) 15:13, 8. Jul 2006 (CEST)

[Bearbeiten] Einfügen von & nbsp

Einfügen von & nbsp ist wie von Lehmzwerg gemacht typografisch nicht üblich. --Eozae 23:12, 18. Jul 2006 (CEST)

Wie bitte? Wie kommst Du darauf? Natürlich ist das sinnvoll! Als alter TeX-Benutzer bin ich jetzt auf Deine Gegenbeispiele und Referenzen gespannt. Lemzwerg 23:24, 22. Jul 2006 (CEST)

[Bearbeiten] Bewertung von Sprachmerkmalen

Ich hätte einen Vorschlag zur Neugliederung des Abschnitts Bewertung von Sprachmerkmalen: Statt Sprachmerkmale als Stärken und Schwächen zu klassifizieren sollte nach Sprachmerkmalen gegliedert werden. Bei jedem Merkmal könnten dann direkt die individuellen Stärken und Schwächen angegeben werden. In der bisherigen Version tauchen manche Merkmale sowohl bei den Stärken als auch bei den Schwächen auf. Das finde ich eher ungünstig. Was meint ihr? --Joblech 09:13, 4. Okt 2006 (CEST)

Ich stimme dir zu, du hast vollkommen Recht. Nach Sprachmerkmalen zu gliedern halte ich für eine gute Idee. ~~Digedag1234

[Bearbeiten] C-Hasser in 10 Tagen - den Link stelle ich jetzt mal in Frage.

Seid ihr wirklich der Meinung, dass dieser Link in den Artikel gehört? Um nur mal grob zu beschreiben was mir an dem Text nicht gefällt: Er ist alles andere als sachlich, die Begründungen sind absolut schwach. Vor allem die Tabelle ist schwach. Ich bin Programmieranfänger und komme mit der C - Syntax sehr gut zurecht.

Bsp.: while(i<10) i--; - so eine Zeile kann man nur programmieren wenn man während des Tippens sein Gehirn abgestellt hat. Das ist für mich kein Argument. Außerdem gibt es für derartige Fehler IDEs. Also: Habe ich irgendetwas nicht mitbekommen und ihr seid wirklich der Meinung, dass dieser Link in den Artikel gehört? ~~Digedag1234

[Bearbeiten] Schwächen - Überarbeiten

Der Abschnitt ist viel zu aufgeblasen. Viele Details beruhen auf ein und der selben Ursache (zum Beispiel der hardwareabhängigen Darstellung und Ausrichtung von Variablen und Strukturen). Die Schlussfolgerungen - fehlende Portabilität sind "so absolut" - falsch. Wenn sich nichts ändert werde ich mich nach Weihnachten mal ransetzen, hoffe aber ein Nutzer vom Fach finde dazu eher Zeit und Lust. --Revvar (D RT) 19:52, 29. Nov. 2006 (CET)

Dann aber bitte auch die Stärken kräftig entschlacken; die meisten Punkte sind Feststellungen und haben nichts mit Stärken zu tun ! Ich möchte ausdrücklich betonen, dass meine Ausführungen nicht polemisch gemeint sind. Ich habe immer wieder den Eindruck, dass sich viele Programmierer einfach nicht von ihren alten Zöpfen trennen können und krampfhaft an technisch völlig überholten Werkzeugen festhalten.

Zeigerarithmetik ermöglicht die effiziente Behandlung von Feldzugriffen, Parametern usw.

Das war wichtig, als es 8 MHz-CPUs gab und ist heute wegen der möglichen Buffer-Overflows eher eine Schwäche.

Präprozessor zur Spracherweiterung und bedingten Übersetzung

Rhetorische Frage: Ist das ein Bug oder ein Feature ?

Linker (Binder) (C war eine der ersten Sprachen, die das Einbinden von externen vorübersetzten Routinen in der Sprachdefinition berücksichtigt)

Heute brauchen wir Loader, die zur Laufzeit linken, damit die Programme effizient und sicher arbeiten. Wie lange braucht denn zum Beispiel Windows XP zum Booten ?

Viele Optimierungen sind bei der Übersetzung möglich.

Ist es wirklich entscheidend und wünschenswert, wenn ein Programm ein Promille schneller läuft, weil keine Index-Checks gemacht werden ? Das ist doch Schnee von gestern.

Fast alle Kernel der bekannten Betriebssysteme sind in C implementiert.

Ist das eine Stärke oder ein Hinweis auf die Innovationsscheu der Entwickler ?

Sehr portabel und sowohl assemblernahe als auch abstrakte Programmierung möglich.

Wie ist denn portable, assemblernahe Programmierung möglich ? Unter abstrakt verstehe ich echte objektorientierte Programmierung (Module, Typensicherheit, Garbage Collection) und nicht das, was uns C++ oder gar C bietet.

Nach wie vor ist C eine häufig benutzte Programmiersprache, nicht nur für Referenzimplementierungen.

Das ist bestenfalls eine Feststellung und im übrigen gereicht es sicherlich nicht zur Ehre einer innovativen Industrie. Was sind denn bitteschön Referenzimplementierungen ? Heute sollten wie andere Maßstäbe für Referenzen anlegen.

Bautsch 16:52, 6. Dez. 2006 (CET)

die Begriffe Stärken und Schwächen sind in diesem Artikel völlig unangebracht. Wie wärs mit Spracheigenschaften? Das ist neutral. Dass C nicht heute entworfen wurde, steht ja hoffentlich irgendwo. Die Sprache hatte und hat seinen festen Platz, wo der Einsatz Sinn macht. --Kurt Seebauer 21:25, 6. Dez. 2006 (CET)

Der Meinung binich auch. Ich habe mal exemplarisch einen Punkt nach oben gezogen (ich denke, man kann das Schritt für Schritt machen), was denkt Ihr? --62.225.37.69

Von „http://de.wikipedia.org../../../c/_/%28/Diskussion%7EC_%28Programmiersprache%29_4a56.html“