Diskussion:C (Programmiersprache)/Archiv/2004

message: 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:<BR/>
<U>Schritt 1a: Auswertung des 1.Increment-Operatoren:</U>
 b++ -> 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 -> 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
Als Gesamtergebnis bekommt man also:
 a=(b+1)*(b+1)*(b+1); b=b+2;
MikeTheGuru 16:57, 24. Feb 2004 (CET)
replies: text: 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)
replies: text: 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)
replies: text: 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)
replies: text: 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)

text: 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)
thread_title:  Angebliche Mehrdeutigkeit 

message: 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)
thread_title:  "Unvollständigkeit der Spezifikation" entfernt 

message: 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)
replies: text: 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)

text: 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)

text: 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)

text: 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)
replies: text: Zur nachnachträglichen Aufklärung. void * ist nicht Bestandteil von K&R C Hubi 10:17, 27. Feb 2004 (CET)
thread_title:  NPOV 

message: 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)
replies: text: 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)
replies: text: 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)

text:  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)
thread_title:  Löschung von Abschnitt "Programmieren in C" 

message: 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 ( b: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)
replies: text: 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)

text: Ebenfalls Zustimmung. Anweisung (Programmiersprache C) und Kommentar (Programmiersprache C) koennen wohl auch mehr oder wenige in die Referenz von b:C-Programmierung, so wie z.B. b:C-Programmierung: Schlüsselwörter und b: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)
thread_title:  Thematik des Artikels (Neu im Okt. 2004) 

message: 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)
thread_title:  Literaturliste 

message: 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)
thread_title:  Die Standardbibliothek 

message: 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)
thread_title:  Kontrollstrukturen