XPSE

- Seite 2 -

Kleines Update wg. BugFix auf 11.0.1.7.t [...]

Ein größerer Quelltext von Jac hatte xpse abstürzen lassen, der Fehler ist behoben.

@Jac: Danke!

26.06.2008 ▲

Experimentelle Version 11.0.1.7.u [...]

, einfacherer Umgang mit Arrays

Arraydefinitionen (auch Funktionsparameter) einfach über Plural der Typenangaben, Wegfall des Variablensuffix und -Tippen. Es ist einfach herrlich...

nach wie vor:
Kompilieren Markieren Separieren

//als Beispiel am long: long(s) definieren:
long a,b,c,...
//auch möglich
long a=20,b=50,c=a*b
//oder Beispiel als Funktionsparameter
myFunc1(long a,b,c) ...

So jetzt auch bei Arrays:
Kompilieren Markieren Separieren

//als Beispiel an Long-Arrays: longarray(s) definieren:
longs a,b//longs statt long!
//jetzt können wir hier:
a[100]=20
b[50]=a[100]
print sizeOf(a)//wenn man a&[] meint reicht ein einfaches a
//bzw.
myFunc1(longs a,b)...

statt: (Langsyntax*)
Kompilieren Markieren Separieren

declare a&[]
declare b&[]
//jetzt können wir hier:
a&[100]=20
b&[50]=a&[100]
print sizeOf(a&[])
//bzw.:

proc myFunc1

    parameters a&[],b&[]

endproc

Arraydefinitionen nach der Langsyntax bleiben natürlich hiervon unberührt.

* XProfan-Syntax

Update: [...]

RGH

Und wie unterscheidest Du die Variablen a!, a%, a&, a$, a![], a%[], a&[] und a$[]?

Gruß
Roland

Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD - ATI Radeon HD 4770 512 MB - Windows 7 Home Premium 32Bit - XProfan X4

Jac
de
Lad

Ich nehme mal an, dass long nur für Variablen ist und longs nur für arrays.

Profan² 2.6 bis XProfan 11.1+XPSE+XPIA+XPRR (und irgendwann XIDE)
Core2Duo E8500/T2250, 8192/1024 MB, Radeon HD4850/Radeon XPress 1250, Vista64/XP

a!, a%, a&, a$, a![], a%[], a&[] und a$[] sind Langsyntax - also Unterscheidung per Variablensuffix, so wie Du es vormachst*.

Einem Variablenbezeichner mehrere Typen zuzuordnen halte ich nicht für lehrwürdig.

Deklariert man Variablen nach Kurzsyntax, so sind den deklarierten Variablenbezeichnern natürlich die Typen per Deklaration zugeordnet und Redeklarationen werden angemeckert**. (Wie auch in C#, Pascal (Delphi) und anderen lehrwürdigen Sprachen...)

Beispielsweise ist imho in Delphi auch nicht zulässig;
Kompilieren Markieren Separieren

;var a,b,c:boolean
;var a,b,c:longint

oder in C nicht ohne Warnung:
Kompilieren Markieren Separieren

;bool a
;long a

Es bleibt nach wie vor dabei: XPSE-Codes unterliegen strengeren Richtlinien was durchschnittlich betrachtet zu besseren Programmen/Ergebnissen führt.

* Gleiche Variablenbezeichner per Langsyntax mit unterschiedlichen Typen deklarieren wird von XPSE nicht immer geduldet, im Falle werden Warnmeldungen ausgegeben.

** Es gibt syntaktische Situationen in denen XPSE nicht wissen kann (also möchte), ob eine Redeklaration zulässig ist bzw. als Redeklaration angesehen werden kann, da XPSE den Code nicht zur Laufzeit betrachten kann. In diesem Fall schweigt XPSE lieber statt mit einer Redeklarationsfehlermeldung abzubrechen.

Beispielsweise ist es daher unter Umständen auch ohne Warnung möglich:
Kompilieren Markieren Separieren

string a,b,c
long a,b,c

zu deklarieren was nach
Kompilieren Markieren Separieren

var A$=
var B$=
var C$=
var A&=0
var B&=0
var C&=0

aufgelöst wird.

Verwendet man jedoch nun a ohne Variablensuffix, so wird die erste Typendeklaration (im Beispiel: string) verwendet um a nach a$ aufzulösen. Verwendet man jedoch a mit Variablensuffix, so gilt natürlich dieses - vorrausgesetzt vorhergehender Deklaration nach beliebiger Syntax da andernfalls eine Warnung ausgegeben wird.

Jac

Ich nehme mal an, dass long nur für Variablen ist und longs nur für arrays.

Exakt, auch wenn das imho nicht Rolands Frage war.

Statt long, string, int, bool, mem und float für Arrays einfach: longs, strings, ints, bools, mems und floats

Hiernach ein Stringarray definieren und gleich mal befüllen:
Kompilieren Markieren Separieren

strings myArray
myArray[100]=test
print sizeOf(myArray)

nach Langsyntax etwas umständlicher:
Kompilieren Markieren Separieren

declare myarray$[]
myarray$[100]=test
print sizeof(myarray$[])

Aber das wirklich Tolle ist das folgendes möglich ist:
Kompilieren Markieren Separieren

strings myArray=explode(so ist es, )

Bei Deklaration können einem Array sofort Werte zugewiesen werden z.B. aus Funktionen welche ein Array zurückliefern oder aus vorhandenen Arrays.

RGH

Hallo iF,
die Lehrwürdigkeit ist nicht mein Thema. Einbuchstabige Bezeichner sind prinzipiell nicht lehrwürdig. Variablennamen sollten immer sprechend sein und in Sparchen ohne Typkennzeichen den Typ durch Prefix im Namen haben, wie es unter C++- und anderen Programmierern schon immer gang und gebe ist (siehe auch Bezeichner in Windows-API-Dokumentation).

Gruß
Roland

Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD - ATI Radeon HD 4770 512 MB - Windows 7 Home Premium 32Bit - XProfan X4

Update auf 11.0.1.7.v [...]

- Anpassung an XProfan 11, unter anderem wegen des END-Befehls.

12.07.2008 ▲

Update auf V11.0.1.7w [...]

- profalt.inc macht nun keine Probleme mehr.

16.07.2008 ▲

Ooops! Da ist mir wohl ein Malör passiert, ich werd wohl eine funktionierende Version nachreichen müssen.

16.07.2008 ▲

Update auf V11.0.1.7y [...]

- profalt.inc macht nun keine Probleme mehr. (hatte noch etwas übersehen...)

17.07.2008 ▲

Update auf V11.0.1.7z [...]

- Fehler in For-Schleifen wegen veraltetem ADD behoben.

Dank an:
Jens-Arne Reumschüssel

Bei FOR-Schleifen, die eine andere Schrittweite als 1 haben, wird
von XPSE z.B. der Befehl "ADD i%,10" verwendet. XPSE selbst meckert
dies dann beim Syntax-Check an (Prozedur ADD nicht deklariert),
sodaß das entsprechende Programm nicht mehr aus XPSE heraus
kompilierbar ist. Ich denke, statt "ADD" sollte "INC" verwendet
werden, da "ADD" ab XProfan 11 veraltet ist und nicht mehr verwendet
werden kann.

Ich gebe zu, daß dies vielleicht kein echter Bug ist, weil XProfan11
erst heute offiziell herausgekommen ist, aber immerhin meckert XPSE
ja selbst den veralteten Befehl an.

Danke Jens!

27.07.2008 ▲

Update auf V11.0.1.7za [...]

- XPSE kannte %BmpB nicht.

08.08.2008 ▲