Path: csiph.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Stefan Reuther Newsgroups: de.alt.folklore.computer Subject: Re: Pascal auf Nr. 10 ;-) Date: Fri, 5 Sep 2025 18:46:45 +0200 Lines: 74 Message-ID: <109fb6m.258.1@stefan.msgid.phost.de> References: <26f84d3bd29d92a0485841d3dc2c08f1@wxp-nb-01.mouse.local> <109cnbj.480.1@stefan.msgid.phost.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: individual.net wlK+Hgf0asRwde9kSH2jMg0gnhUa9Wwn0w2G89n9xm2XRsl0E6 Cancel-Lock: sha1:ygcPlxsz+VYWdsPWk/N8uOIi/Lc= sha256:UDexF0F2i9O3X4QpSHFJQ1QeZdKhd/eX9jN4Ev7ugvQ= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 Hamster/2.1.0.1538 In-Reply-To: Xref: csiph.com de.alt.folklore.computer:51993 Am 05.09.2025 um 08:33 schrieb F. W.: > Am 04.09.2025 um 18:55 schrieb Stefan Reuther: >>> Es gibt ja nicht mal case für Strings in C. >> >> In Pascal auch nicht, schon gar nicht "damals". Genauer gesagt gab es >> in Pascal "damals" nicht mal ernsthafte Strings. > > Och, PACKED ARRAY OF CHAR finde ich aber aussagekräftig. Das ist das gleiche wie 'char[]'. >>> Die klassische Form für Menüs damals. Von den unklaren >>> Parameterübergaben an Funktionen mal ganz zu schweigen. By reference? >>> By value? Egal. War alles erlaubt. Und alles dazwischen auch. >>> Erkannte man sowieso nicht auf Anhieb. >> >> In C ist das einfach. Es ist *immer* by value. In Pascal muss ich >> hingegen den Funktionskopf anschauen, ob der Parameter als VAR >> übergeben wird oder nicht. > > Aber man kann es erkennen. In C auch, nur einfacher. Wenn eine Adresse übergeben wird, erkennbar am Datentyp oder dem '&'-Operator, möchte wohl jemand den Wert verändern. C++ hingegen.... ist an der Stelle wie Pascal. Man muss den Funktionskopf anschauen, um zu wissen, was passiert. >>> Außerdem konnte man jahrelang in Speicher schreiben, der nicht >>> alloziert wurde. Oder man überschrieb einfach die Null-Termination >>> bei Strings und landete im gepflegten Nirgendwo. > >> Die "damals" üblichen Pascal-Dialekte von Borland haben Pascal >> erweitert. Zum einen um Strings, die zugegebenermaßen sehr bequem sind >> (allerdings mit ihrer Schallmauer von 255 Zeichen auch sehr limitiert >> und unflexibel). Zum anderen um allerlei Typcasts usw., damit man die >> ganzen Pointer-Fehler, die man in C machen kann, in Pascal endlich >> auch machen kann. Nimmt sich also am Ende nichts. > > Diesen Teil von Pascal versuche ich zu meiden. Besonders das Typecasting > geht bei mir zu 90 % irgendwie in die Hose. Pointer gehen noch so. NEW > und ^ sind verständlich. ...und damit ist der Funktionsumfang identisch zu dem von C. >> Und jemand, der sich Gedanken darüber macht, wie man eine >> Programmiersprache sinnvoll benutzt, ist mir tausendmal lieber als >> jemand, der religiös runterbetet "nehmt Sprache X, dann seid ihr alle >> Probleme los". Denn, Spoiler: seid ihr nicht. Use-after-free oder >> out-of-bounds-access oder null-pointer-dereference kannst du in Pascal >> genauso einfach bauen wie in C. Und die Mittel, es zu vermeiden, sind >> genau die gleichen. > > Der Trick bei Pascal u. a. ist, dass man das machen kann, es aber auch > bleiben lassen kann. Vor allem verkettete Listen oder Bäume kann man in > Pascal bauen. Man kann aber auch ohne sie gut leben. In C auch. Und dann hat man die Vorteile einer umfangreichen Infrastruktur. Ein nichttriviales Pascal-Programm von einem Compiler auf einen anderen zu übertragen ist ein Projekt. Gescheites C ist eine Sache von "einfach neu compilieren". Zumindest ist die Teilmenge der von allen C-Compilern unterstützten Funktionen deutlich größer als bei Pascal. OK, es gibt FreePascal. Für x86 und ARM. Was ist mit PIC? Xtensa? M32R? Was ist mit Betriebssystemen außerhalb der großen *ixe? QNX? FreeRTOS? Integrity? Eine Sprache mit C++-Features aber Pascal-Syntax wäre nett gewesen. Aber der Zug ist halt abgefahren. Stefan