„Diskussion:C (Programmiersprache)“ – Versionsunterschied

Versionsgeschichte interaktiv durchsuchen

Inhalt gelöscht Inhalt hinzugefügt

Inline

Aktuelle Version vom 3. Juni 2025, 22:35 Uhr

Diese Diskussionsseite dient dazu, Verbesserungen am Artikel „C (Programmiersprache)“ zu besprechen. Persönliche Betrachtungen zum Thema gehören nicht hierher. Für allgemeine Wissensfragen gibt es die Auskunft.

Füge neue Diskussionsthemen unten an:

Klicke auf Abschnitt hinzufügen, um ein neues Diskussionsthema zu beginnen.

Archiv

2004 2005 2006 2007 2008 2009 2010 2011 2012 2015 2016 2017 2018 2019
Wie wird ein Archiv angelegt?

Auf dieser Seite werden Abschnitte ab Überschriftenebene 2 automatisch archiviert, die seit 7 Tagen mit dem Baustein {{Erledigt|1=--~~~~}} versehen sind.

Paradigma

Die Sprache C ist prozedural. Das Paradigma ist eine echte Untermenge imperativer Sprachen. Die Angabe "imperativ" ist daher redundant und sollte entfernt werden, insb. weil sehr oft falsch dargestellt (steht auch richtigerweise nicht in der Info-Box).

Im englischen Wikipedia C17 und nicht C18

Letzter Kommentar: vor 1 Monat2 Kommentare2 Personen sind an der Diskussion beteiligt

Im englischen Wikipedia C17 und nicht C18

Dojqe albanish --2003:C6:E700:B875:9C48:9D4D:7D56:E0A 21:50, 3. Jun. 2025 (CEST)Beantworten

Laut https://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html wäre beides korrekt - und der GCC stellt beide Optionen (tatsächlich 4) zum Steuern des Compilerverhaltens bei. Keine Ahnung wie man das im Artikel sinnvoll darstellen sollte. Gruß, --Burkhard (Diskussion) 22:35, 3. Jun. 2025 (CEST)Beantworten

@@ Zeile 1: / Zeile 1: @@
+{{Diskussionsseite}}
-==Angebliche Mehrdeutigkeit==
+{{Archivübersicht|{{Archiv-Liste Jahre|{{FULLPAGENAME}}/Archiv/|richtung=aufsteigend}}}}
-Der Ausdruck
+{{Autoarchiv|Alter=90|Ziel='((Lemma))/Archiv/((Jahr))'|Mindestbeiträge=1|Mindestabschnitte=1|Frequenz=ständig}}
- a = b++ * ++b * b
+{{Autoarchiv-Erledigt
-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.
+ |Alter=7
+ |Ziel='Diskussion:C (Programmiersprache)/Archiv/((Jahr))'
+}}
+== Paradigma ==
-Die Multiplikation ihrerseits assoziiert von links nach rechts (die Increment-Operatoren von rechts nach links).
+Die Sprache C ist prozedural. Das Paradigma ist eine echte Untermenge imperativer Sprachen. Die Angabe "imperativ" ist daher redundant und sollte entfernt werden, insb. weil sehr oft falsch dargestellt (steht auch richtigerweise nicht in der Info-Box).
+== Im englischen Wikipedia C17 und nicht C18 ==
-Voll ausgeklammert ergibt sich daher folgender Ausdruck:
- a = (b++ * ++b) * b
+Im englischen Wikipedia C17 und nicht C18
-Das obige Beispiel wird also wie folgt ausgewertet werden:<BR/>
-<U>Schritt 1a: Auswertung des 1.Increment-Operatoren:</U>
- b++ -&gt; b'=(b+1)
-unter Beibehaltung des Originalwertes von b für die Berechnung des Gesamtausdruckes!<BR/>
-<U>Schritt 1b: Auswertung des 2.Increment-Operators:</U>
- ++b -&gt; b"=(b'+1)
-unter Ersetzung von b durch (b+1) für die Berechnung des Gesamtausdruckes!<BR/>
-<U>Schritt 2: Auswertung der Multiplikation:</U>
- ((b+1) * (b+1)) * (b+1)
-<U>Schritt 3: Ersetzen von b durch den Zwischenwert b":</U>
- b = b+2
+Dojqe albanish --[[Spezial:Beiträge/2003:C6:E700:B875:9C48:9D4D:7D56:E0A|2003:C6:E700:B875:9C48:9D4D:7D56:E0A]] 21:50, 3. Jun. 2025 (CEST)
-Als Gesamtergebnis bekommt man also:
- a=(b+1)*(b+1)*(b+1); b=b+2;
-[[Benutzer:MikeTheGuru|MikeTheGuru]] 16:57, 24. Feb 2004 (CET)
+:Laut https://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html wäre beides korrekt - und der GCC stellt beide Optionen (tatsächlich 4) zum Steuern des Compilerverhaltens bei. Keine Ahnung wie man das im Artikel sinnvoll darstellen sollte. Gruß, --[[Benutzer:Drahkrub|Burkhard]] ([[Benutzer Diskussion:Drahkrub|Diskussion]]) 22:35, 3. Jun. 2025 (CEST)
-: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. [[Benutzer:Schoos|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. [[Benutzer:Hubi|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. [[Benutzer:Schoos|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. --[[Benutzer:Andreas B.|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. -- [[Benutzer:Andreas B.|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. -- [[Benutzer:Andreas B.|Andreas B.]] 15:16, 1. Mär 2004 (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! [[Benutzer:Hubi|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.
-[[Benutzer:Schoos|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! ;-)
-[[Benutzer:ratopi|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. [[Benutzer:Hubi|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. -- [[Benutzer:195.33.105.17|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 [[Benutzer:Hubi|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 [[Benutzer:Hubi|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). [[Benutzer:Hubi|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. [[Benutzer:Hubi|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. [[Benutzer:Hubi|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. [[Benutzer:Hubi|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.[[Benutzer:195.243.149.235|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? [[Benutzer:Hubi|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. [[Benutzer:Hubi|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. --[[Benutzer:Andreas B.|Andreas B.]] 00:22, 27. Feb 2004 (CET)
-::Zur nachnachträglichen Aufklärung. void * ist nicht Bestandteil von K&R C [[Benutzer:Hubi|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.
---[[Benutzer:Hokanomono|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 --[[Benutzer:Hubi|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. [[Benutzer:Mh|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.
---[[Benutzer:Claudio Carobolante|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.
---[[Benutzer:Claudio Carobolante|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 das ist ein weiterer Fake-Account zum Löschen von Inhalten. Denn produktiv trägst Du nicht bei. Diese Form des Löschens ist reiner [[Vandalismus]]. Darf ich Dich [[Benutzer:Checkup]] nennen oder besser [[Benutzer:Sprezzatura]]?! [[Benutzer:Nephelin|TG]] 00:34, 15. Jul 2004 (CEST)