BlueBasic Compiler
Erweiterte Konstrukte
Freitag, 16. Juli 2010 von Thunder
Hallo,
länger ist es her, dass hier ein Eintrag gemacht wurde - das liegt an meinem Parallelprojekt MaxNet. Vergessen habe
ich BlueBasic allerdings nicht.
Ich habe jetzt Select-Case-Default sowie Repeat-Until implementiert. Ersteres muss noch genauer auf Lauffähigkeit
geprüft werden.
Wie ich schon oft gesagt habe, wird man mit BlueBasic einige Einschränkungen vorfinden (zB: kein On-The-Fly Deklarieren
von Variablen, Select-Case-Default eingeschränkt ...). Daher will ich dem Nutzer dennoch einiges an nützlichen Funktionen
bieten, die man bei BlitzBasic doch vermisst.
Eine, neuimplementierte, dieser Art ist das aussteigen aus verschachtelten Schleifen. Ich gehe in meinen Beispielen in
dem Eintrag von folgendem Code aus:
BlitzBasic: [AUSKLAPPEN]
Global x%,y%=1
Repeat
x=1
Repeat
Print x+" x "+y+" = "+(x*y)
x=x+1
Until x>10
y=y+1
Until y>10
Print "Fertig!"
End
Dieser Code gibt mit Hilfe von zwei Variablen und zwei verschachtelten Repeat-Until-Schleifen das 1x1 aus.
Wenn ich das 1x1 allerdings nach der Rechnung 5x5 abbrechen will, muss ich einen unschönen Umweg gehen:
BlitzBasic: [AUSKLAPPEN]
Global x%,y%=1
Repeat
x=1
Repeat
Print x+" x "+y+" = "+(x*y)
If x=5 And y=5 Then x=100
x=x+1
Until x>10
If x=101 Then Exit
y=y+1
Until y>10
Print "Fertig!"
End
(Dies ist nur eine Möglichkeit von vielen)
Nicht besonders schön - besonders eklig wird es, wenn man die Schleifen erweitern will. Deshalb habe ich mir ein Feature
von der Programmiersprache Ada abgeschaut: Man kann Schleifen Namen geben.
An den Befehl Exit stellt man einfach den Schleifennamen hinten ran und man kann aus einer beliebigen Schleife (in der man
auch drinnen ist
) aussteigen:
BlueBasic und nicht BlitzMax: [AUSKLAPPEN]
Global x:Int,y%=1
Repeat schleifenname
x=1
Repeat
Print x+" x "+y+" = "+(x*y)
'nach 5x5 abbrechen:
If x=5 And y=5 Then Exit schleifenname
x=x+1
Until x>10
y=y+1
Until y>10
Print "Fertig!"
End
Wer genau hinschaut bemerkt, dass ich für Variablen auch die BlitzMax-Specifier zulasse (allerdings nur Int, String und Float).
Obiger BlueBasic-Code lässt sich bereits problemlos kompilieren und ausführen
mfg Thunder
Riesenfortschritte II
Dienstag, 6. Juli 2010 von Thunder
Überraschung!
Auch BlueBasic habe ich erweitert. Ich habe einen Import-Befehl implementiert, der eine C-Datei mit einer IMP-Datei importiert.
Die IMP-Datei listet auf, welche Funktionen dem BlueBasic-Compiler bekannt sein sollen, also welche der Programmierer verwenden
kann.
Außerdem habe ich Strings implementiert, doch leider gibt es Probleme mit Stringvergleichen. Wie bei BlueBasic-1 sind folgende
Stringvergleiche möglich:
BlitzBasic: [AUSKLAPPEN]
Local s1$,s2$
If "jalsldf"="kdlsfjsld" Then ...
If "jklsdjf"=s1 Then ...
If s2="jkdlsf" Then ...
If s1=s2 Then ...
Die Strings dürfen nicht in der If manipuliert werden, weil es dann zu folgendem Problem kommen würde:
Code: [AUSKLAPPEN]
If Lower(s1)=Lower(s2) Then ...
;C-Code:
if(strcmp(lower(s1),lower(s2))==0){ ...
Lower muss, um nicht den echten String zu manipulieren, eine Kopie anlegen und einen Zeiger auf diese Kopie (die danach auch verändert
wurde) zurückgeben. Dieser Zeiger zeigt (logischerweise) auf einen allokierten Speicherbereich. Der Vergleich würde funktionieren, doch
würde ich die Adressen der Speicherbereiche, und damit 8 KB Speicher, verlieren. Wenn diese Vergleiche in einer Schleife (die z.B. 10000
Mal ausgeführt wird) vorgenommen werden, hat man in den Speicher ein Loch von 78 MiB gebohrt. Schlimmer wird es, wenn diese Funktionen
verschachtelt aufgerufen werden: Trim(Mid(Upper(s$),5,-1))
Daher habe ich das rausgelassen. Man darf Strings manipulieren, aber nicht in Vergleichen.
Außerdem gibt es einen von BlitzBasic abweichenden Befehl Clr, der einen String "freigibt". Man könnte es mit str="" vergleichen, es ist
aber besser, weil auch der Speicher freigegeben wird. Ich werde trotzdem versuchen, das auf eine Zuweisung von "" zu übertragen.
Weiters sind jetzt Print und Write einigermaßen implementiert. Folgende Syntax:
Code: [AUSKLAPPEN]
<print-syntax> = Print String | Variable | ( Rechenausdruck )
Wenn man innerhalb von Print rechnen will, muss man den Rechenausdruck in Klammern schreiben:
BlitzBasic: [AUSKLAPPEN]
Global daumen=5
;Nicht zulässig:
Print "Hier ist Pi mal Daumen: "+3.14*daumen
;Zulässig:
Print "Hier ist Pi mal Daumen: "+(3.14*daumen)
;Außerdem unzulässig:
Print "In Klammern dürfen nur Rechenausdrücke stehen"+(" es ist leichter zu parsen und außerdem schreibt kein Mensch einen String in Klammern^^")
mfg Thunder
PS: Ja, "Riesenfortschritte I" war nicht in dem Worklog, sondern hier: http://www.blitzforum.de/worklogs/369/
Ifs
Mittwoch, 9. Juni 2010 von Thunder
Hallo,
ich habe den Vorschlag von Noobody umgesetzt und die Entfernung der Kommentare in den Compiler selbst verlegt damit
keine Probleme entstehen. Bis jetzt funktioniert es so, ich könnte mir allerdings vorstellen, dass ich irgendwas
vergessen habe...
Das nächste wären If-Bedingungen. Auch diese wurden fürs erste nur für Ints und Floats eingebaut. Ich habe einige
Tests gemacht; dieser Quelltext:
BlitzMax: [AUSKLAPPEN]
Local x%=2,y%=1 'Kommentar
If x=y Then 'Kommentar
inlinec printf("x=y\n"); 'Kommentar
ElseIf x=y+1'Kommentar
If y=x-1 Then inlinec printf("x=y+1 und y=x-1\n"); 'Kommentar
Else 'Kommentar
inlinec printf("else\n");'Kommentar
EndIf 'Kommentar
... wird zu ...
Code: [AUSKLAPPEN]
#include "test.h"
int main(int argc, char** argv){
BB_INT x = 2;
BB_INT y = 1;
if(x==y){
printf("x=y\n");
}else if(x==y+1){
if(y==x-1){
printf("x=y+1 und y=x-1\n");
}
}else{
printf("else\n");
}
return 0;
}
Es scheint also zu funktionieren und es kostete mich nur 30 Zeilen Code (am Anfang mehr, ein bisschen Optimierung und
alles wird besser; aprospros First make it run, then make it run fast (Brian Kernighan) passt gut dazu).
Im Moment sind einzeilige If-Verschachtelungen oder If-Elseif oder If-Else oder If-Elseif-Else Kombinationen nicht möglich:
BlitzMax: [AUSKLAPPEN]
'Wir sind nicht möglich:
If x=0 Then If y=0 Then ...
If x=0 Then x=1 Else x=0
'...
Außerdem wird wahrscheinlich eine weitere Regel bleiben: Mehrzeilige If -> 'Then' ist optional ; Einzeilige If -> 'Then'
ist verpflichtend. Das ist geplant (oder auch nicht) um soetwas zu vermeiden:
BlitzMax: [AUSKLAPPEN]
If x=0 If y=2 y=3 'nicht cool
Ich weiß, ich habe euch wahrscheinlich nicht mit großartigen Neuigkeiten überschwemmt, aber jetzt ist einmal der Schulstreß
vorbei (heute war der letzte Test gewesen) und ich werde versuchen mehr zu machen.
Bis zum nächsten Eintrag,
Thunder
rekursive Includes
Montag, 7. Juni 2010 von Thunder
Hallo,
ich melde mich wieder mit einer neuen Version BlueBasic, die jetzt Includes unterstützt. Diese werden durch
rekursive Funktionsaufrufe meiner Präprozessorfunktion (die auch Kommentare entfernt etc.) interpretiert. Es ist
erstaunlich wie gut sich das mit Hilfe von Rekursion in 37 effektiven Zeilen (=Zeilen in denen was steht) lösen lässt.
(sauber - nicht gepfuscht! ok, ich gebs zu; zuerst gepfuscht und dann sauber neugeschrieben )
Die Rekursivität der Includes im Titel betrifft natürlich nicht die Funktion, mit der diese interpretiert werden,
sondern, dass sie auch rekursiv inkludiert werden können, zB test.bb inkludiert test2.bb, das test3.bb inkludiert.
Übrigens gibt es eine Warnung, wenn versucht wird eine Datei doppelt zu inkludieren.
Info:
- Note heißt, es wird ein Text ausgegeben, der dem Benutzer etwas sagt, was aber nicht unbedingt
wichtig ist. Wird nur in einem der Verbose-Modes des Compilers angezeigt:
-v ... be verbose
-V ... be very verbose
- Warnung heißt, es wird ein Text ausgegeben, aber der Kompiliervorgang wird fortgesetzt.
- Error heißt, es wird ein Text ausgegeben und die Kompilation beendet.
Außerdem habe ich das Kommentarzeichen von ; auf ' geändert, jedoch sehr modular, zwei Schläge auf die Tastatur und
es ist wieder beim Alten.
Der Grund für die Änderung war die Einführung der Funktion InlineC. Diese kann man auf 2 Möglichkeiten aufrufen:
BlitzBasic: [AUSKLAPPEN]
InlineC printf("Hallo Welt!\n"); 'Einzeilig
InlineC ' wenn nach dem Befehl eine neue Zeile anfängt...
printf("Hallo Welt!\n");
'... wird er als mehrzeilig interpretiert.
EndInlineC
Der Strichpunkt am Ende der C-Befehle hat es ausgemacht. Dieser würde nämlich schon vom Präprozessor entfernt und der
Compiler bekäme ihn gar nicht zu Gesicht. Der Strichpunkt hätte automatisch eingefügt werden können, doch das ist 1. unpraktisch
und 2. höherer Aufwand (nicht unbedingt viel höher, aber schon um einiges und ich mag keine vollgestopften Funktionen, die ich
später nicht mehr lesen kann).
Nicht dass ihr jetzt denkt ich sei faul^^, aber InlineC ist für mich eine ganz wichtige Funktion, weil ich theoretisch Teile
der BlueBasic-Funktionsbibliothek in BlueBasic selbst schreiben könnte (mit einigen InlineC-Aufrufen).
Wie ich schon letztes Mal sagte erstellt der Compiler die Datei irgendwas.prep.bb die dann kompiliert wird. Diese beinhaltet schon
alle Includes und keine Kommentare mehr.
Mal sehen, was ich bis zum nächsten Mal mache...
Bis dahin,
Thunder
Funktionsaufrufe und optionale Parameter
Sonntag, 6. Juni 2010 von Thunder
Hallo,
ich habe jetzt einen einfachen Funktionsaufruf aus dem Programm implementiert (noch nicht in mathematischen Ausdrücken).
Auch optionale Parameter durften nicht fehlen, doch da sie von ANSI-C nicht unterstützt werden, musste ich da nachhelfen.
Mein System mit optionalen Parametern ist nicht so komfortabel wie das von BlitzBasic, aber es ist definitiv einfacher zu
programmieren und braucht in meinem Quelltext etwa 30 Zeilen. Ich weiß noch nicht ob ich es umstellen werde. Mein System
sieht so aus:
BlitzBasic: [AUSKLAPPEN]
Function EineFunktion(a%,b%=20,c%=30)
End Function ; in BlueBasic ist auch EndFunction erlaubt: BlitzMax-Style
;Aufrufe:
EineFunktion(30,40,50)
EineFunktion(40,,20)
EineFunktion(10,1,) ;Das ganze geht natürlich auch ohne Klammern
EineFunktion(10,,)
Wie wird das verwirklicht? Der Compiler geht die Datei zweimal von oben bis unten durch. Beim ersten Mal wird alles mögliche
zusammengetragen, woran mich C hindern würde (Funktionen, die weiter oben verwendet werden, müssen vordeklariert sein ...).
In diesem Durchlauf werden auch die Funktionen im Speicher des Compilers vordeklariert, damit er weiß, dass es sie gibt. Der
Compiler erstellt dann einen String mit den Parametern der Funktion. Ein Beispiel:
BlitzBasic: [AUSKLAPPEN]
Function IrgendeineFunktion(s$,i%=1337,k%,f#=3.14,s1$="Hallo")
Bei solch einer Funktion generiert der Compiler diesen Parameterstring: $%=1337%#=3.14$="Hallo"
Aus dem kann er bei Funktionsaufrufen lesen, welcher Parameter welchen Typs ist und ob er optional ist und was eingesetzt werden
soll, falls er optional ist und nicht angegeben wird.
Ein kompiliertes Beispiel:
BlitzBasic: [AUSKLAPPEN]
Local POSx=22,POSy%=11
Local x%,y#=55.5,w=100.2,h%=23
Global isinside=(posx>=x And posx<=x+w) And (posy>=y And posy<=y+h)
add50(,,)
add50(50,40,30)
add50(,20,)
add50(,20,30)
add50(60,,)
add50(70,50,)
add50(70,,54)
Function Add50(X=20,Y=30,Z=40)
Local z%=(x+y+z) Mod 50
End Function
Sieht in C so aus:
Code: [AUSKLAPPEN]
#include "test.h"
BB_INT add50(BB_INT x, BB_INT y, BB_INT z){
// BlueBasic macht alle Variablen- und Funktionsnamen klein.
BB_INT z = (x+y+z) % 50;
}
int main(int argc, char** argv){
BB_INT posx = 22;
BB_INT posy = 11;
BB_INT x = 0;
BB_FLOAT y = 55.5;
BB_INT w = 100.2;
BB_INT h = 23;
isinside = (posx>=x && posx<=x+w) && (posy>=y && posy<=y+h);
add50(20,30,40);
add50(50,40,30);
add50(20,20,40);
add50(20,20,30);
add50(60,30,40);
add50(70,50,40);
add50(70,30,54);
return 0;
}
(test.h):
BB_INT isinside;
Bis zum nächsten Mal,
Thunder
Matheconverter & Modularität
Samstag, 5. Juni 2010 von Thunder
Hallo,
glaubt nicht, was ich sage! Es ist kein Mathe-Parser - ich würde es eher als Mathematik-Syntax-Converter
bezeichnen; jedenfalls ist es so ziemlich fertig, was auch immer es jetzt ist. Schwer war es nicht, weil ich
nur einiges zu konvertieren hatte ( => zu >=, Shr zu >> ...); zwar fehlen noch ein paar Elemente, diese sind
aber nicht grundlegend und können später ohne weiteres eingefügt werden.
Außerdem habe ich eine Theorie aufgestellt und zwar darüber, wieso BB Variablen, die zum ersten Mal benutzt werden,
deklariert. Zumindest, wenn man nach C kompiliert (ich habe keine Ahnung was blitzcc macht - ich bleibe bei meiner
Theorie, die besagt, dass BlitzBasic NICHT kompiliert wird) ist es viel einfacher wenn man einfach alles deklariert,
was einem in den Weg kommt. Ich hätte es viel leichter gehabt, aber ich wollte eine strikte Deklaration von Variablen.
Übrigens versuche ich alles so modular wie möglich zu halten, um Änderungen schnell an vielen Elementen vornehmen zu
können. Ein Beispiel: Früher hatte ich 3 Funktionen für Deklaration von Variablen/Konstanten: GlobalDec, LocalDec, ConstDec.
Jetzt ist es eine (Declaration), die einen Parameter übergeben bekommt, um welche Deklaration es sich handelt. Das ist
um einiges praktischer, wenn man nach C kompiliert. Diese 3 Funktionen waren ein Überbleibsel aus der Kompilierung nach
Assembler.
Es ist immernoch nicht mehr möglich, als Variablen zu deklarieren und Funktionen. Jetzt eine Beispieldatei:
BlitzBasic: [AUSKLAPPEN]
Local posx=22,posy%=11
Local x%,y#=55.5,w=100.2,h%=23
Global isinside=(posx>=x And posx<=x+w) And (posy>=y And posy<=y+h)
Function Add(x%,y)
Local z%=x+y
End Function
...wird zu...
Code: [AUSKLAPPEN]
#include "test.h"
BB_FLOAT Add(BB_INT x, BB_INT y){
BB_INT z = x+y;
}
int main(int argc, char** argv){
BB_INT posx = 22;
BB_INT posy = 11;
BB_INT x = 0;
BB_FLOAT y = 55.5;
BB_INT w = 100.2;
BB_INT h = 23;
isinside = (posx>=x && posx<=x+w) && (posy>=y && posy<=y+h);
return 0;
}
Sollte also alles klappen. Diese Datei hieß beim kompilieren test.bb
Zu den Includedateien: Es werden 2 Dateien inkludiert nämlich test.h und standard.c
test.h: Der Compiler erstellt 3 Dateien (Beispiel: test.bb): test.prep.bb (wird nachher gelöscht), test.c, test.h
test.h enthält die Deklarationen der globalen Variablen - so war es einfacher diese in den Griff zu bekommen.
standard.c: Das ist die Library die bei jeder BlueBasic-generierten C-Datei hinzugefügt wird. Sie enthält alle
Deklarationen etc. unter Anderem die von BB_INT, BB_FLOAT und BB_STRING (auch ein Teil des Modularitätsprinzips)
Bis zum nächsten Eintrag,
Thunder
Edit: ich habe gerade bemerkt, dass die Beispieldatei (Rückgabetyp der Funktion) falsch kompiliert wird. Ich werde das beheben. - funktioniert jetzt!
Es geht weiter und der Code ist recht schön
Freitag, 4. Juni 2010 von Thunder
Hallo,
wie gesagt: es geht weiter! Ich habe nun Funktionsdeklarationen so gut wie fertig (eigentlich fertig, aber ich
weiß noch nicht, ob sie fehlerlos funktionieren). Globale Deklarationen müssen noch ein wenig abgeändert werden,
weil in BB folgendes möglich ist:
BlitzBasic: [AUSKLAPPEN]
Local x=55,y=22
Global z=x*2-y
Das sähe in C bei Übernahme des Codes so aus:
Code: [AUSKLAPPEN]
int main(int argc, char **argv){
int x=55,y=22;
return 0;
}
Dieser Schritt der Initialisierung bei globalen Variablen wird in die main-Funktion verlegt:
Code: [AUSKLAPPEN]
int main(int argc, char **argv){
int x=55,y=22;
z=x*2-y;
return 0;
}
Eigentlich ist es recht einfach das umzusetzen, doch ich möchte zuerst den Matheparser schreiben, damit ich den auch
gleich einfügen kann. Das heißt, wenn ich Glück habe, seht ihr nächstes Mal eine funktionierende Global Deklaration,
Local Deklaration, Const Deklaration (alles vorerst nur für Int und Float) und eine funktionierende Funktions Deklaration.
Übrigens habe ich (von mir so genannte) Befehlsattribute eingeführt; auf ein Global(zum Beispiel) darf ein Doppelpunkt folgen,
dem ein bestimmtes Attribut folgt (zB Static):
BlitzBasic: [AUSKLAPPEN]
Global:Static x,y ;auf diese Variablen kann nur in dieser Datei zugegriffen werden
Ich hoffe ihr verliert trotz des Neuschreibens nicht die Hoffnung/das Interesse, ich gebe mein Bestes!
Bis zum nächsten Mal,
Thunder
Neuauflage
Mittwoch, 2. Juni 2010 von Thunder
Hallo,
ich hatte in letzter Zeit einige Probleme mit dem Quelltext. Da der Compiler in den Anfangszeiten dazu
gedacht war, nach Assembler zu kompilieren und ich mir nicht die Mühe gemacht habe, den Compiler direkt
nach dem Umstieg auf C umzuschreiben, habe ich versucht alles so gut wie möglich zurechtzupfuschen...
Mit mäßigem Erfolg.
Nun gibt es mehrere Probleme:
- Es sind ungenutze Funktionen drinnen, die nur auf andere Funktionen umleiten (Abwärtskompatiblität)
- Der rekursive Baum, der beim kompilieren aufgebaut wird, ist immernoch an die Assemblersyntax angepasst.
- Es wurde in den verschiedenen Funktionen immer wieder das Dateihandle manipuliert durch Aufrufe von Pos und Seek - diese sollen nun komplett durch Rekursion ersetzt werden, da sie sehr zur Unübersichtlichkeit beitragen.
- (das schlimmste!) Der rekursive Baum wird nicht aufgelöst! Das Programm wird einfach abgebrochen und der Programmfluss wird unterbrochen - eine Qual für den Leser. Das Hauptprogramm ruft eine Funktion Main auf, die program aufruft, die prolog aufruft ...
Daher habe ich mich entschlossen das ganze neuzuschreiben; eine Taktik die ich oft verwende - ist der
Code nichts mehr Wert -> neuschreiben (natürlich vorher den alten sichern - man kann ja Ideen übernehmen) und
genau das habe ich vor...
Diesmal wird von den Stützpfeilern aus begonnen. Ich habe auch schon (theoretisch) ein System, das Funktionen
mit optionalen Parametern nach C konvertieren kann. Implementiert sind auch schon Variablendeklarationen und
Konstantendeklarationen - Funktionsdeklarationen sind gerade dabei, geschrieben zu werden.
diesmal muss es einfach klappen
mfg Thunder
Es geht weiter...
Sonntag, 9. Mai 2010 von Thunder
Hallo,
Ich habe eine längere Pause gemacht(in der ich mich kein bisschen mit BlueBasic beschäftigt habe),
weil ich in letzter Zeit ein bisschen Streß mit der Schule hatte.
Daher muss ich mich jetzt wieder ein bisschen in den Code einarbeiten, aber da ich den Code schön in
Includes aufgeteilt habe sollte das kein Problem sein.
Große Neuerungen habe ich nicht zu verkünden, weswegen die Versionsnummer nicht angehoben wird.
Changelog:
Code: [AUSKLAPPEN]
Versionsnummer: 0.00.20-2
+ String-Vergleiche eingefügt
+ Input für Strings eingefügt
--|
Bis jetzt sind Stringvergleiche allerdings auf statische Strings beschränkt. Das heißt, dass in der If
keine Manipulation des Strings erlaubt ist. Also gibt es insgesamt 4 Möglichkeiten Strings auf Gleichheit
zu überprüfen:
BlitzBasic: [AUSKLAPPEN]
Local string1$,string2$
If "Hallo"="Irgendwas" Then Print "1"
If "Hallo"=string1 Then Print "2"
If string1="Hallo" Then Print "3"
If string1=string2 Then Print "4"
Input kann bis jetzt nur einen komplett-statischen String übernehmen, d.h. irgendein Ausdruck der zwischen
Anführungszeichen steht. Werde ich hoffentlich noch verbessern.
Der Anlass für diesen Eintrag ist allerdings eher dieser Screen:
Bis zum nächsten Mal,
Thunder
Matheparser - wie oft noch...
Sonntag, 25. April 2010 von Thunder
... hoffentlich nicht zu oft.
Hallo,
Möglicherweise ist schon am Titel erkennbar, dass ich den Matheparser neugeschrieben habe. Es gab beim alten
ein schweres Problem mit der Rekursion, weil der Matheparser manchmal Klammern geschlossen hat, die noch von
anderen Teilen des Compilers verwendet worden wären, gab es manchmal Fehler und manchmal nicht.
Daher habe ich zum ersten Mal von Strg+A + Backspace Gebrauch gemacht und das ganze neugeschrieben. Ich glaube
er ist ein bisschen kürzer und funktioniert jetzt, soweit ich das beurteilen kann.
Winkelfunktionen (Sin, Cos, Tan, ASin, ACos, ATan) funktionieren jetzt! An dieser Stelle Danke an D2006, der
mich darauf hingewiesen hat, dass ich die Grad in Radianten umrechnen muss.
Auch bei Strings gibt es einige Probleme. Sie funktionieren zwar, aber ich bin mir nicht sicher, ob BlueBasic
mit BlitzBasic in Sachen Stringmanipulation(nämlich Geschwindigkeit) mithalten kann. Denn vor jeder Operation,
die mit dem String durchgeführt werden soll, muss überprüft werden, ob dieser schon initialisiert wurde. Außerdem
muss der String, bevor er manipuliert wird, in einen Puffer kopiert werden, falls er sich selbst im String-Ausdruck
verwendet. Dh:
BlitzBasic: [AUSKLAPPEN]
Local s$=" programmiere "
s="Ich"+s+"BlueBasic"
Das wird sich herausstellen, wenn ich Millisecs() implementiert habe ...
Changelog
Code: [AUSKLAPPEN]
Versionsnummer: 0.00.20
-+ Matheparser neugeschrieben
-+ Stringparser zum Teil neugeschrieben
o Änderung in der Mathe-Lib: Winkelfunktionen in BlitzBasic verwenden Grad und Winkelfunktionen
aus C Radianten. Umrechnung eingefügt.
o Interne Funktion bearbeitet. Ab jetzt sollte man überall(!) Kommazahlen verwenden können.
o Print überarbeitet. Funktionen, die von Print aus aufgerufen werden, sollten von nun an, auch
Terme als Parameter annehmen (noch keine StringTerme!).
o Ab jetzt wird bei jeder Funktion, deren Verwendung nicht empfohlen ist, eine Warnmeldung ausgegeben.
Wenn man den Compiler mit dem Argument -nd aufruft, führt ein Aufruf zum Kompilierabbruch(mit Errormeldung).
Dazu zählen bis jetzt: Goto, Gosub, Asm
--|
Hier stand so lange kein String-Beispiel mehr. Da muss ein neues her!
BlitzBasic: [AUSKLAPPEN]
Global s$="Hallo Welt!"
Print s
s=s+" und Hallo Mond!"
Print s
s="Hallo Natur! "+s
Print s
End
In der nächsten Zeit möchte ich Funktionen mit optionalen Parametern versehen, da ich das komplett vergessen habe.
Da C das nicht kann, werde ich es in den Compiler integrieren müssen.
Eingefallen ist mir das erst, als ich Funktionen wie Mid und Instr in die String-Lib einbauen wollte.
Bis zum nächsten Mal,
Thunder