Wieder einmal ein groer... ^1 ^1 ^1 ^1 ^1 ^1 ^3 ^3 Heute: Reactions auf vorherige Streite! ^3 >> Bcherwurm: Lieber Real Adok, ich mchte dir gar nicht ausreden, da Basic eine tolle Einsteigersprache sein kann. Schlielich war schon das allererste Spaghetti-Basic 1960 als "Beginner's All-purpose Symbolic Instruction Code" konzipiert. Eine All- zweck-Anfngersprache also. Zehn Jahre spter folgte Pascal als Lehrsprache fr das Informatikstudium, also ebenfalls als Einstiegssprache. Turbo Pascal und Power Basic bieten inzwischen weit mehr als was fr eine Anfngersprache ntig wre. Schn, du magst Basic, Pascal aber nicht. Ich hingegen bin sicher, da mein einst so teures QuickBasic/MS Basic fr fast alle meine Zwecke dem Gespann Turbo Pascal/Turbo Assembler weit unterlegen ist. Die Geschmcker sind eben verschieden. Deshalb schreibe ich nicht. Aber deine Pascal-Kritik ist sachlich vllig falsch! Deine Irrtmer fangen schon beim ersten Programmbeispiel an. Lieber Real Adok, in Turbo Pascal schreibe ich eine Endlosschleife statt mit "Do:Anweisung:Loop" eben mit "Repeat;Anweisung; Until False;" oder mit "While True Do Anweisung;". Richtig, Turbo Pascal ist etwas langatmiger und pingeliger. Und es gibt kein "Do:Loop". Aber der Grund dafr ist wohl, da es keine einzige "Do:Loop"-Schleife gibt, die sich nicht innerhalb von 10 Sekunden als "While"- oder "Repeat"-Schleife formulieren lt. Es gibt eben nur 2 Mglichkeiten, eine Abbruchbedingung abzufragen: vorne oder hinten. Warum den Compiler mit unntigem Kontrollstruktur-Germpel belasten? Ich bezweifle, da die vielen Befehle mit mehreren Anwendungsmglichkeiten ein Vorteil von Basic sind. Bei den Kontrollstrukturen mag das ja noch angehen. Aber bei Funktionen aus der Laufzeitbibliothek? Sptestens wenn du ein Programm compilierst, wirst du wenig Freude daran haben! Mchtige, vielfltige Befehle werden blicherweise in riesige, langsame Blcke bersetzt. Compilierte Basic-Programme neigen deshalb zu einer gewissen Dickleibigkeit. Der Vorwurf der "Verschwendung" von Variablennamen durch die vielen Pascal- Befehle ist ein weiteres Miverstndnis. In Turbo Pascal 7.0 gibt es ganze 49 reservierte Wrter (plus zwei weitere in Objekttyp-Deklarationen), in PowerBasic 3.0 habe ich 333 gezhlt! TP erlaubt dir, eine Prozedur oder Funktion z.B. Line zu nennen. So kannst du die Funktion Line aus der Laufzeitbibliothek (Unit Graph) durch eine selbstdefinierte gleichnamige Prozedur ersetzen. Versuch das lieber nicht mit dem Basic-Befehl Line! Ich hatte frher einige QuickBasic-Programme mit einem Array Dir$(). Dann bekam ich MS Basic PDS und hatte das Vergngen, alles umschreiben zu drfen, weil Dir$ reserviert war... Nun zum angeblich nicht existenten Exit in Pascal. Prozeduren und Funktionen kann man schon seit Turbo Pascal 4.0 mit Exit verlassen. In Turbo Pascal 7.0 geht's endlich auch bei Schleifen mit For, Repeat oder While. Nur heit der Befehl dort "Break". Zustzlich gibt's noch den "Continue"-Befehl, der gleich die nchste Schleife bearbeiten lt. Wie mache ich so etwas unter QBasic? Mit Goto? Auch ich habe frher die Nase darber germpft, da die Pascalisten erst jede Variable definieren muten. Und dann brtete ich viele Stunden vor meinen Basic-Programmen, in denen irgendwo eine Variable mit Tippfehler versteckt war. Basic akzeptiert so etwas klaglos; bei Turbo Pascal merkst du den Fehler schon beim Compilieren. brigens sorgt $DIM ALL bei PowerBasic 3.0 dafr, da alle Variablen deklariert werden mssen. Rate mal, wozu das eingefhrt wurde! Tja, die Stringverwaltung von Basic ist wirklich ganz nett. Leider sind alle Strings variabler Lnge unter QBasic/QuickBasic zusammen mit den globalen Variablen und dem Stapel auf maximal 64 kB beschrnkt. Hast Du schon mal die Zuweisung A$=SPACE$(30000) versucht? Ergebnis: Zu wenig Speicher. Oder A$=SPACE$(15000):B$=A$? Gleiches Resultat! Darum meine Frage: Was ntzt dir denn ein riesenlanger String, wenn er dein Programm zum Absturz bringt? Unter PowerBasic klappt's wahrscheinlich besser, weil hier der ganze Speicher fr Strings variabler Lnge verwendet werden kann. Allerdings ist die schne Stringverwaltung stets ein wenig sperrig, Verwaltung und Herumschieberei der Strings kostet Zeit. Die komplizierten Kontrollstrukturen vereinfachen nicht gerade die gemischtsprachliche Stringverarbeitung. Manche Basic-Strukturen zur Speicherverwaltung sind sogar undokumentiert. Die Zugriffe aus Assembler-Routinen gehen dann nur mit umstndlichen Prozeduraufrufen. Bei Turbo Pascal ist so etwas undenk- bar. Jeder Variablentyp ist exakt dokumentiert. "Klassische" Pascal-Strings sind tatschlich auf maximal 255 Zeichen+1 Lngebyte beschrnkt. Seit TP 7.0 knnen aber auch Zeichenketten bis nahezu 64 kB Gre verarbeitet werden - nullterminierte Strings nach C-Vorbild. Basic kennt keine so langen Strings. Wirklich schrecklich, diese "Speicherverschwendung" durch die Boolean- Variablen in Pascal. Aber in Basic ver(sch)wendest du fr das Bit Information statt eines Bytes doch gleich eine Integer mit 2 Byte Lnge! Es ist eben gar nicht so einfach, Einzelbits zu verarbeiten und verwalten. Gut, das Betriebssystem tut's manchmal, auch ich habe unter TP schon Bitarrays benutzt. Aber ein Compiler? Stell dir mal 8 einzelne Booleans mit 8 Variablennamen vor. Wie soll der Compiler die zusammenfassen? ndert sich die Reihenfolge, wenn ich mitten unter den Variablen eine neue definiere? Wo finde ich sie dann aus einer Assembler-Prozedur heraus? Vielleicht kannst du ja Borland mal einen heien Tip geben! >> The Real Adok: Hallo Bcherwurm! Eigentlich will ich diesen Prospenstreit um Basic und Pascal nicht noch einmal aufflammen lassen, denn seitdem ich ihn geschrieben habe, ist schon mehr als ein halbes Jahr vergangen, und in dieser Zeit hat sich mein Programmier-Weltbild sehr verndert. Trotzdem will ich auf deinen Beitrag nher eingehen. Ich habe nichts gegen Pascal und finde, da es eine hervorragende Sprache ist, die einen leichten Einstieg mit einer hohen Flexibilitt verbindet. Ursprnglich ging es bei diesem Prospenstreit auch nicht darum, ob Basic oder Pascal schlecht sei, sondern darum, da viele Leute Basic angegriffen und Falsches behauptet haben. Beim Thema "DO-LOOP und quivalente" gebe ich dir recht. Jedenfalls werden hier in Pascal zwei verschiedene Kontrollstrukturen bentigt, wohingegen in Basic blo ein einziger, vielfltig anwendbarer Block notwendig ist. Nun zu den Befehlen mit den vielen Anwendungsmglichkeiten: Es stimmt, da diese Befehle sehr viel Speicherplatz bentigen. Beispielsweise SCREEN, wobei ich jetzt nur die einfachste Anwendung, das Wechseln des Bildschirm- modus, bercksichtigen will: Fr jeden Bildschirmmodus wird im Grunde genommen eine andere Wechsel-Routine bentigt. Die meisten Modi lassen sich zwar mit dem Interrupt 10h Funktion 0 einstellen, jedoch haben sie dort eine andere Nummer als in Basic. So wird der Basic-Bildschirmmodus 13 zu Modus 13h (hexadezimal), also 19 (dezimal). Allein das Konvertieren der Nummer des Bildschirmmodus nimmt schon einigen Platz in der EXE-Datei ein, der eigentlich fast zur Gnze unntig ist, weil meistens ohnehin nur einige Bildschirmmodi vom Programmierer verwendet werden (0, 12, 13) - die anderen sind relativ uninteressant und belegen nur zustzlichen Speicherplatz. Um dies zu umgehen, knnte der Compiler, wenn er 'n bichen "intelligenter" programmiert wre, so vorgehen, da er zuerst im Sourcecode nachsieht, welche Bildschirmmodi vom Programm verwendet werden, und danach nur jene SCREEN-Routinen in die EXE-Datei einbindet, die fr diese Modi bentigt werden. So knnten trotz Befehle mit vielfltigen Anwendungsmglichkeiten relativ kleine EXE-Dateien erzeugt werden. Das Ganze htte aber einen Haken: In Basic gibt es auch die Mglichkeit, SCREEN x zu verwenden - dann wird auf den Bildschirmmodus umgeschaltet, dessen Nummer in der Variablen x steht. Da der Compiler nie von vornherein wei, welchen Wert x enthlt - es sei denn, x wre eine Konstante -, mu er alle SCREEN-Routinen einbinden. Aus dem Beispiel SCREEN x ergibt sich gleich eine weitere Quelle des hohen Speicherplatzbedarfs: die Fehlerabfangroutinen. Wenn wir schon bei SCREEN x bleiben: Enthlt x beispielsweise den Wert 1000, so mte das ohne Fehler- abfangroutinen zu einem Programmabsturz fhren, denn in Basic existiert kein Bildschirmmodus mit dieser Nummer. Dank der Fehlerabfangroutinen von Basic wird der Fehler aber dennoch abgefangen (Wortspiel!?). Das ist in diesem Fall auch gut so. Aber wenn der Programmierer sein Programm so geschrieben hat, da ein solcher Fehler nicht auftreten kann, sind diese Fehlerabfangroutinen doch total berflssig! Jau, jetzt noch ein zweites Beispiel fr einen Befehl mit vielfltigen Anwendungsmglichkeiten: LINE. Mit diesem Befehl lt sich folgendes machen: ^0 1. eine Linie zeichnen ^0 2. ein Rechteck zeichnen ^0 3. ein Rechteck zeichnen und mit einer Farbe ausmalen Daraus kann man schon erkennen, da man es im Grunde genommen mit drei verschiedenen Befehlen zu tun hat! Der Compiler bindet aber die Routinen fr alle LINE-Varianten in die EXE-Datei ein, auch wenn nur eine Variante bentigt wird. Und noch schlimmer: Es wird gleich die ganze Laufzeit- bibliothek eingebunden, die Routinen fr Grafikbefehle enthlt. Abgesehen davon werden die LINE-Befehle geradezu mit Parametern zugestopft, die selten eine Verwendung finden. Folge: Nicht bentigte Parameter werden auf den Stack gepusht und mssen von den LINE-Routinen abgearbeitet werden. Das kostet einige Taktzyklen Zeit. Nicht umsonst sind maschinennahe Routinen schneller als Basic-Befehle gleicher Funktion. NEXTer Punkt: Verschwendung von Variablennamen. Ja, genau! Hier habe ich etwas Falsches behauptet. Das Problem mit Dir$ httest du aber ganz leicht mit einem Editor beheben knnen, der Search & Replace beherrscht... Oder du schreibst ein Programm, da das Listing byteweise auf die Zeichenfolge Dir$ absucht und sie dann in Vrz$ oder so ndert... Also, meine Kritik, da in Pascal jede Variable am Programmanfang definiert werden mu, bezog sich vielmehr auf temporre Variablen mit einfachen Namen wie i ! In C ist es so, da eine temporre Variable direkt im Kopf eines beliebigen Blocks oder einer Schleife definiert werden kann. Dann wird zur Laufzeit der Speicherplatz fr die Variable angefordert und am Ende des Blocks wieder freigegeben. Beispiel: ^0 for(char i=start;i<=ende;i++) {/*...*/} Hier ist der Schleifenzhler i eine temporre Variable, deren Speicher- bedarf nach dem Ende der for-Schleife freigegeben wird. (ber Sinn und Unsinn dieser Methode lt sich natrlich immer noch streiten. Bei nherem Betrachten stellt man fest, da eigentlich auch in den meisten Fllen kein Speicherplatz gespart wird... Hu(g)i, warum so viele unntige Worte ("eigentlich auch in den meisten Fllen" ???) Nullterminierte Strings lassen sich auch in Basic erzeugen - hndisch natrlich! Entweder ein Array aus BYTE-Variablen (Power Basic only) erzeugen, die ASCII-Codes reinschreiben und nach dem letzten Zeichen CHR$(0) setzen, oder gleich Zeiger verwenden und Speicherplatz anfordern. Aber lassen wir den Quatsch. Der Vorteil von Basic's Stringverwaltung ist, da sie auch von Anfngern kapiert werden kann... (Unsinn, ich schreibe besser "fr Anfnger, die erst damit begonnen haben, in die Programmierung einzusteigen und deshalb noch wenig Erfahrung damit haben, verstndlich ist"), sonst nix. Der Zugriff von Assembler-Routinen auf normale Basic- Strings ist schwierig, aber auch nicht unschaffbar! Wer Assembler-Routinen in Basic einbindet, kann ja auerdem gleich nullterminierte Strings mit BYTE-Array verwenden und mu dann eben eigene Stringfunktionen coden, aber lassen wir das. Basic wurde ja immerhin nicht fr systemnahe Programmierung geschaffen. Zum Schlu noch eine kurze Anmerkung zu den Boolean-Variablen. Ja, du hast natrlich vollkommen recht! Schon wenn der Compiler 8 Booleans zu einem Byte zusammenfassen sollte, bereitet es Probleme, die einzelnen Booleans in Assembler anzusprechen, falls man nicht wei, in welcher Reihenfolge sie im Byte abgespeichert werden, also welche Boolean-Variable welches Bit ist. Definiert man noch dazu nach dem Schreiben der Assembler-Routinen eine weitere Boolean-Variable, ndert sich unter Umstnden die Reihenfolge der Booleans im Byte, und die ASM-Routinen mssen noch einmal berarbeitet werden. Stimmt. Ich sehe es ein, da es keine andere Lsung fr die Boolean-Variablen gibt, als ein ganzes Byte zu belegen. Mein Vorschlag ist deshalb: Wer kein Programmieranfnger mehr ist, soll einfach auf Boolean- Variablen weitgehend verzichten, stattdessen eine Byte/Char-Vary nehmen und mit AND und OR die einzelnen Bits ansprechen. (Siehe auch Hugi #1!) Nun, jetzt habe ich ja schon viel mehr geschrieben, als ich ursprnglich vorhatte. Ok, ich erklre hiermit den Streit "Basic gegen Pascal" !!!MEINERSEITS!!! fr beendet, da heit, ich werde mich nicht mehr daran beteiligen! Aber unten geht's noch weiter, also scroll down. ^4 Euer The Real Adok. >>TOXO: Hi Bcherwurm !! Du schreibst zu Beginn deines Textes: ^0 >> Schn, du magst Basic, Pascal aber nicht. Ich hingegen bin sicher, da ^0 mein einst so teures QuickBasic/MS Basic fr fast alle meine Zwecke dem ^0 Gespann Turbo Pascal/Turbo Assembler weit unterlegen ist. << Mmmh, das ist zweifelsohne richtig. Sicher, TP/Turbo Assembler ist bestimmt Quickbasic berlegen. Aber ich finde, es kommt darauf an, was man daraus macht. Wenn man in Basic ein Prog (z.B. ein Demo) schreibt, es so schreibt, da das Letzte aus der Sprache rausgeholt wird, wird das Ergebniss sicher nicht so gut sein wie ein "normales" TP-Proggi, d.h. es wird langsamer, ruckeliger usw. laufen. Dennoch wrde ich das Basicprog fr besser halten, da dort halt das Letzte aus der Maschine rausgeholt wurde. Dabei ist es egal, ob es ein Basic- und ein Pascal-Programm oder ein C- und ein Logo-Prog ist. Ich finde, es kommt beim Programmieren darauf an, ein Programm zu schreiben, das die jeweilige Programmiersprache am besten ausnutzt. Da sich The Real Adok in manchen Punkten geirrt hat, stimmt schon. Ich fange auch grade mit Pascal an und mu sagen, da mir die Sprache sehr gut gefllt. Aber ich denke, ich werde vorlufig doch erst noch bei QBASIC bleiben, da ich dort noch lange nicht alles ausgeschpft habe. Greetz, TOXO.