| |
|
|
- Seite 1 - |
|
| So V0.1.6 is raus!
Größeres XPSE-Update! Bitte den alten noch aufheben, in V0.1.6 wurden viele neue Features hinzugefügt, die Kontrollen verbessert und und und...
Umlaute werden jetzt auch unterstütz! <offtopic>Was natürlich nur ein Bug sein kann! </offtopic>
Was ist neu:
Die Variablenerkennung ist deutlich verbessert. Die Variablen werden jetzt auch den Prozeduren zugeordnet und die Typen werden geprüft.
Headerfiles: Werden nun eingelesen und deren Anwendung überprüft! Im Source benutzte Strukturen, Apis oder Konstanten werden vom XPSE nun direkt umgesetzt und die Headerfileangaben werden aus dem Source entfernt - was zu Folge hat das der XProfankompiler die Headerfiles nicht mehr benötigt.
Warum das XPSE tut? Weil er die Umsetzung um ein Vielfaches schneller macht als der XProfankompiler und der XProfankompiler auch noch weniger zu tun hat und schneller kompiliert.
Durch das Einlesen der Headerfiles kann XPSE auch Strukturendefinitionen und Anwendungen überprüfen - und muss diese nicht mehr übergehen. Falschgeschriebene Konstanten werden nun auch angemeckert.
Benutzte APIs aus den Headerfiles werden nicht einfach nur als Externals in den Source umgewandelt! Das schnellere Call wird verwendet und die Prozeduradresse aus der DLL wird einmalig bezogen. Das macht die Abarbeitung von ApiCalls aus Headerfiles auch noch schneller.
Nur noch fremde Headerfiles müssen angegeben werden! Die StandardHeaderFiles windows.ph, messages.ph, commctrl.ph, structs.ph, Avi.ph, gdi.ph, OpenGL.ph, richedit.ph und shellapi.ph hat XPSE intus! Die Angabe der Headerfiles ist nicht mehr nötig! Werden die Files trotzdem angegeben nutzt XPSE die angegebenen und nicht die eingebauten!
Durch das Weglassen von Headerfileangaben wird das Kompilieren jedoch noch schneller! Weder XPSE noch der XProfankompiler müssen die Headerfiles einlesen!
Das ~ muss nicht mehr verwendet werden! Es kann - aber es muß nicht! Nur wenn der Name vielleicht mit einem anderen kollidiert müsste das ~ verwendet werden.
APIs, Strukturen und Konstanten können also einfach verwendet werden ohne diese zu deklarieren und ohne das ~ Zeichen.
Einfach probieren! KompilierenMarkierenSeparieren |
|
|
| |
|
|
|
| |
|
- Seite 1 - |
|
| Update auf V0.1.6x
Es gibt einen neuen Variablentypen! Suffix: NIX (garnichts) Kein Suffix! Kein Suffix? Nö! Kein Suffix. Was ist das für ein Typ? Alles was Du willst! String, Long, Integer oder Float.
Okok neuer Variablentyp ist falsch, es gibt keinen neuen Typen - die vorhandenen Typen bleiben. Aber eins ist neu: Keine Suffixe mehr - wenn man möchte!
Wie das geht? Ganz einfach - wie bisher - man deklariert z.B. drei Long:
long a,b,c
oder 4 strings?
string s,t,r,u
Das wars.
Als besonderes Feature könnte ich erwähnen das man auch gleich innerhalb der Deklaration (wie seit X10 möglich) die Werte zuweisen kann. So: (jetzt mal integer)
int a=10
oder
int a=10,b=20,c=a+b,d=50 <-- jau das geht auch! Lecker? Lecker!
Später im Programm dann einfach a statt a% schreiben. Kann man sich glaub ich gut merken ^^ Wer a% schreibt ist aber auch nicht schlechter bedient - beides geht!
int a%=10 <-- geht aber nicht! int a=10 <-- geht!
Und Bereichsvariablen?
Nixda! Floats, Longs, Ints und Strings.
Demo? Kla: KompilierenMarkierenSeparieren Wie in C? Ja so ähnlich. |
|
|
| |
|
|
|
| Ab XPSE V0.1.6y funktionierts jetzt auch lokal... (alles experimentell!) KompilierenMarkierenSeparieren
proc test(long a,b,c,d,e,string s)
string h="argh!"
proc luma(int a,b,c)
int h=a*b*c
return str$(h+b+c)+s
endproc
s=str$(gettickcount)
print a,b,c
print "Tick:",s
endproc
oder KompilierenMarkierenSeparieren *bang*
Somit kann auch innerhalb von Prozeduren ohne Variablensuffixe gearbeitet werden, sogar das Angeben von Parametern kann ohne Suffixe geschehen, und auch bei verschachtelten Prozeduren funktioniert es. (Sichtweite -1 pro Schachtel) KompilierenMarkierenSeparieren |
|
|
| |
|
|
| |
|
- Seite 2 - |
|
|
| Aaaalso - Variablen Deklarieren: KompilierenMarkierenSeparieren//strings?
string a,b,c,d,e
//schon sind a,b,c,d und e vom typ String!
//oder gleich mit Zuweisung?
string a="lol",b="bla",c,d,e="huch?"
//ein paar longs deklarieren?
long i,o,p
//oder mit zuweisung - aber als int?
int meinint=20,bla=30
//das alles klappt a) global, und b lokal in procs.
//procs haben aber parameter - diese müssten ja dann doch wieder mit suffixen angegeben werden.
//sei denn man schreib:
proc test(int i,o,p)
endproc
//geht auch:
proc test
parameters int i,o,p
endproc
//geht auch:
proc test (int i,long h,long v,z,p,string s1,s2,s3)
endproc
Lecker? Lecker!
Im nächsten Schritt will ich mal zusehen das das Überladen von Funktionen auch per C-Syntax ermöglicht wird.
Wem das zu kompliziert ist: Es gibt einfach die Schlüsselworte Int Long Float und String. Einfach davor schreiben und danach die Variablenbezeichnungen. Klappt bei Parameterangaben oder als Variablendeklaration. |
|
|
| |
|
|
|
| Nachtrag: Hey ich kanns kaum glauben soll mir das wirklich gelungen sein? Nach der Syntax keine Variablensuffixe mehr? oO (ausgenommen Bereichsvariablen/Arrays) |
|
|
| |
|
|
|
Michael Wodrich | Sind bei Long, Float und String wirklich keine Kollisionen zu befürchten?
String Alfa, Bravo = Test
Ich glaube, daß macht die ganze Sache eher etwas unübersichtlicher. Wer soll dann in solchen Quellen nach Fehlern suchen.
Wären da nicht wenigstens andere Schlüsselworte angebracht?
Schöne Grüße Michael Wodrich |
|
|
| Programmieren, das spannendste Detektivspiel der Welt. | 09.11.2006 ▲ |
|
|
|
|
| Wenn Du Long im üblichen Sinne nutzt nimmst ja eine Bereichsvariable. Hier gibts also keine Kollision.
Wo sollte da was kollidieren?
String Alfa, Bravo = Test...
Deklariert halt alfa und bravo als strings - bravo wird auch gleich auf Test gesetzt - ist doch ok?! |
|
|
| |
|
|
|
| |
|
| |
|
|
|
Michael Wodrich | [quote:b6ff5934a1]Wo sollte da was kollidieren?
String Alfa, Bravo = Test...
Deklariert halt alfa und bravo als strings - bravo wird auch gleich auf Test gesetzt - ist doch ok?![/quote:b6ff5934a1] Wenn Alfa und Bravo allerdings Longints sind dann wird ab Adresse in Alfa ab Offset in Bravo der String Test abgelegt.
Und diese Mehrdeutigkeiten in einem Code (evtl. in einem fremden Code) zu entdecken wird dann immer schwieriger. Je mehr Bedeutungen String und Co. bekommen desto furchtbarer.
Schöne Grüße Michael Wodrich |
|
|
| Programmieren, das spannendste Detektivspiel der Welt. | 09.11.2006 ▲ |
|
|
|
|
| Nein es ist ganz einfach! Wenn String (oder Long) nicht zur deklaration sondern zum Füllen von Werten benutzt werden soll dann ist einfach ein Variablensuffix anzugeben. |
|
|
| |
|
|
|
| Update auf V0.1.6zb
Einige kleine Bugfixes. |
|
|
| |
|
|
|
| Update! auf V0.1.6zc
Einige Bugfixes! Auch bei Dateihandleangaben kann jetzt auf das Varialbensuffix verzichtet werden. KompilierenMarkierenSeparieren Ebenso wird jetzt - wenn vorhanden - eine xpse.inc grundsätzlich includiert. Wird das Namensraumsymbol ?_ in der xpse.inc verwendet so wird es in xpse. ersetzt. |
|
|
| |
|
|
|
| Kleiner Nachtrag: Grundsätzlich rate ich von der Nutzung einer xpse.inc ab! Ich habe das Feature aber eingebunden weil es gewünscht wurde. Warum ich abrate? Man könnte schnell vergessen das die Befehle welche in der xpse.inc stehen immer eingebunden werden, nur erfahrene Programmierer sollten das nutzen.
Und wenn schon damit gearbeitet wird dann empfehle ich das dort definierte Prozeduren wenigestens mit dem Namespacesign ?_ deklariert werden sollten. |
|
|
| |
|
|