Diskussion:C (Programmiersprache)/Archiv/2004

aus Wikipedia, der freien Enzyklopädie
Zur Navigation springen Zur Suche springen

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 ;)

Löschung von Abschnitt "Programmieren in C"

Letzter Kommentar: vor 17 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt

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)

Hab mich des Abschnitts mal angenommen. Jetzt ist's besser, da verständlicher. --Schweikhardt 21:55, 28. Nov. 2007 (CET)

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 ( 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)

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

Literaturliste

Letzter Kommentar: vor 20 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt

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)

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

Abgerufen von „https://de.wikipedia.org/w/index.php?title=Diskussion:C_(Programmiersprache)/Archiv/2004&oldid=210621746“