Nexus-Office Migration CL5.2 nach XBase

[Martin Altmann]

Hallo Rolf,
ja - Xbase++ ist in wenigen Dingen strikter als Clipper.
Das RETURN ohne Rückgabewert bei einer FUNCTION gehört z.B. dazu.

Viele Grüße,
Martin

[FlashNash]

Okay Martin, ich werde über das WE mal noch das Eine/Andere testen ... mal sehen wie weit ich komme. Das wichtigste ist ja zuerst, dass XBase meine alten .PRG Files fehlerfrei compilliert. Danach sieht man dann weiter.

Ich werde euch alle NOCH MÄCHTIG AUF DEN SENKEL GEHEN mit meinen Fragen.

[Manfred]

Hi Rolf,

mach Dir mal keinen Kopp, wegen vieler und evtl. blöder Fragen.

Schau Dir meine Beitragszahl an, ziehe 10% ab (Witze erzählt) und dann weißt Du wer hier viele und auch manchmal blöde Fragen stellt.

Also, Du bist auf einem weiten Weg dahin und ich denke einmal, es wird sicherlich noch eine lange Zeit dauern, bis Du mich und ein paar andere hier eingeholt hast. Und mein Pool an blöden Fragen ist noch lange nicht erschöpft, das gebe ich Dir schriftlich.

Und vor allen Dingen: Bisher hat sich keiner (zumindest nicht öffentlich) über meine Fragerei beschwert. Also, immer heraus damit. Wir lernen alle davon.

[Jan]

Es gibt da irgendwo ein Papier von Frank++, in dem er den Umbau der DBU nach Xbase++ beschreibt. Und anhand dessen sehr sehr gut erklärt, was dabei alles (eben nicht sehr viel) umgebaut werden und beachtet werden muß. Ich schau mal heute nachmittag, ob ich das irgendwo ausgraben kann, und stell dann hier den Link rein.

Jan

[Manfred]

Hi Jan,

zu spät:

http://www.alaska-software.com/scripts/ ... IB_SECT=40

Getting started.....

und andere

[Jan]

Manfred,

gut gemeint. Aber nicht das, was ich meinte. Frank ++ (Großheinrich) hat da mal was geschrieben, wie man das Clipper-DBU auf Xbase++ umschreibt. Anhand dieses Beispiels geht er genau durch, was alles in Xbase++ anders ist als in Clipper, und was man da ändern muß, um ein "altes" Clipper-Programm unter Xbase++ ans Laufen zu bekommen.

Und das steht leider nicht in dieser Liste drin.

Jan

[Manfred]

Hi Jan,

bist Du froh, wenn Du Unsinn erzählen kannst?

Seite 21 geht es los

[Jan]

Hallo Manfred,

aber gewonnen hast Du deswegen noch lange nicht! Wenn überhaupt, dann Gleichstand. Denn ich meinte ein Dokument von Frank, in dem es um nichts anderes als diese Geschichte ging. Daß das auch in dem "Getting Started" drinsteht, war mir nicht bewusst.

Jan

[Manfred]

Hi Jan,

na gut. Obwohl ich sehr überrascht bin, ich kenne nur das und habe anhand dieses PDF meine DBU damals umgebaut.

Wenn Du noch mehr hast, dann sage bitte was es sein soll. Es würde auch mich noch interessieren.

Obwohl ich mir ziemlich sicher bin, dass es nur dieses eine Dokument gibt/gab. Aber, man hat schon Pferde......

PS: Nö, jetzt muß ich mal zurückrudern und Dir Recht geben. Ich habe nochmals nachgesehen. Die Anleitung scheint mir doch recht kurz zu sein. Und in meiner Erinerung war auch eine wesentlich länger. Aber verflixt, ich hatte die auch und finde die nicht mehr.

[Martin Altmann]

Hallo Rolf,
was auch noch mit ein Grund sien kann:
Unter Clipper ging das mit den Prozeduren und Funktionen ja z.B. so:

Code: Alles auswählen

PROCEDURE a
PARAMETERS b, c, d
...
RETURN
...
PROCEDURE b
...
RETURN

Das geht unter Xbase++ nicht! Da muss das so heißen:

Code: Alles auswählen

PROCEDURE a( b, c, d )
...
RETURN
...
PROCEDURE b()
...
RETURN

Und auch der Aufruf ändert sich ggf. Unter Clipper ging ja folgendes:

Code: Alles auswählen

DO a WITH "bla", .T., 1
DO b

Unter Xbase++ dagegen:

a( "bla", .T., 1 )
b()

Und auch eine Funktion muß einen Wert zurückliefern! Wenn nicht, mache eine PROCEDURE drauß.

Viele Grüße,
Martin

[Jan]

Und auch eine Funktion muß einen Wert zurückliefern! Wenn nicht, mache eine PROCEDURE drauß

Weil mir das zu blöde ist, immer nach Function und Procedure zu unterscheiden (und weil sich manchmal bei mir im Laufe der Entwicklung des Programmes das auch ändern kann) benutze ich ausschließlich Funktions. Und wenn es denn keine Rückgabe gibt, nehme ich einfach RETURN NIL.

Jan

[Martin Altmann]

Hallo Jan,
das geht so lange gut, bis in einer neueren Version ein strikterer Parser zum Einsatz kommt und der meckert, weil Du die Rückgabe der Funktion nicht auffängst - oder rufst Du Deine NIL-zurückgebende Funktion auch mit a := nix() auf?
Aber egal - es gibt sicherlich auch das andere Extrem: Leute, die grundsätzlich nur PROCEDUREs nutzen - und wenn eine Rückgabe gebraucht wird, den Parameter halt per Referenz übergeben
Und jetzt können sich wieder die Profiler austoben (aber bitte in einem neuen Thread, das schweift hier ab):
Was ist schneller:

• Eine Prozedur die nichts zurück gibt oder eine Funktion, die NIL zurückgibt (aber sonst natürlich das gleiche macht)? Ich tippe auf Prozedur.
• Eine Funktion, die einen Wert zurück gibt oder eine Prozedur, die den zu ändernden Wert per Referenz übergeben bekommt (aber sonst natürlich das gleiche macht)? Ich tippe auch hier auf Prozedur.

Viele Grüße,
Martin

[Jan]

Hallo Martin,

immer diese philosophischen Diskussionen unter logisch denkenden Entwicklern

oder rufst Du Deine NIL-zurückgebende Funktion auch mit a := nix() auf?

Nö. Sollte ich?

Was ist schneller:

Hmmm. Ist ein Argument. Wer schreibt jetzt eine Schleife, die 100.000 mal eine Function bzw. eine Procedure aufruft und das mal misst?

Aber jetzt mal ehrlich (wär doch ein nettes Diskussionsthema für den 23. in Herford, oder?): Selbst wenn das ein paar Millisekunden Zeitersparnis gibt - wer von uns ruft denn dermaßen exzessiv Funktionen auf, daß sich dadurch das gesamte Programm (merklich) verlangsamen würde?

Von daher denke ich, daß jeder das auf seine Art machen kann. Wenn es geht, und keine Knoten in den Code macht, ist das doch praktisch gesehen völlig egal. Oder?

Jan

[Manfred]

Hi ihr 2

ich denke mal, da wird sicherlich Hubert demnächst eine Abhandlung drüber halten, wollen wir wetten?

[Jan]

Sei doch froh daß es hier jemanden gibt, der solche Punkte als Herausforderung sieht und sich da reinvertieft. Da sind ja teilweise schon ganz interessante Ergebnisse rausgekommen.

Wo wir gerade dabei sind: Habt Ihr die Diskussion in der Newsgroup gelesen? Wo Hannes mit einigen anderen die Geschwindigkeit von Xbase++ mit anderen Sprachen vergleicht? Ist in dem ActiveX-Thread unter AutomationObject:dynamicCast() zu finden. Wo Paul Hill eine Geschwindigkeitsbehauptung aufstellt und sie auch belegt. Hannes aber durch eine Codeoptimierung alles ins Gegenteil verkehrt, und siehe da: Xbase++ ist um Längen schneller als alle anderen! Den Code (und die Erklärung dazu!) von Hannes werd ich mir beiseite legen, da kann man sicher noch Nutzen draus ziehen.

Jan

[Manfred]

Hi Jan,

ich bin stinkend wütend, das hier immer Leute sind, die durch interessante Tests und gute Tipps mir und den anderen helfen. Das finde ich unerhört.

[Jan]

... und ich dachte schon, Du wärst nur stinkig auf mich mit meinen gut gemeinten und ständig am Thema vorbei gehenden Ratschlägen Gut zu wissen daß ich nun doch nicht der einzige bin

Jan

[Manfred]

Hi Jan,

stinkig auf Dich? Ach watt. Und außerdem solltest Du in dem Zusammenhang das Wort ständig streichen. So schlimm ist es nun auch wieder nicht. Wenn Du nicht wärest, wen sollte ich denn dann ärgern?

Hubert? Ich werde mich hüten. Martin? Der läßt alles an sich abperlen. Bleibt doch sonst keiner mehr übrig.

Aber ich merke schon, wir blähen den Thread hier unnötig auf und bevor es Haue gibt....

[brandelh]

Hallo Jan,
das geht so lange gut, bis in einer neueren Version ein strikterer Parser zum Einsatz kommt und der meckert, weil Du die Rückgabe der Funktion nicht auffängst - oder rufst Du Deine NIL-zurückgebende Funktion auch mit a := nix() auf?

meinst du das im Ernst ?

eine

Code: Alles auswählen

function A()
Return NIL

ist genauso wie eine

Code: Alles auswählen

procedure A()
Return

ich vermute mal ganz stark, dass Xbase++ intern eine procedure auf eine VOID function umsetzt !
Rückgabewerte kann man immer getrost ignorieren, wenn man sie nicht braucht und das wird sich auch nicht ändern, sonst würde man zig Zeilen alten Codes brechen.

[brandelh]

Hi,

im reinen Quellcode mit "normalen" Befehlen (Schleifen etc.) ist Xbase++ ziemlich langsam, aber es gibt sehr mächtige Befehle wie DBEVAL(), ASORT() etc. diese sind wesentlich schneller wie alles was ich mit PowerBasic selbst geschrieben habe.

[Manfred]

Hi,

also nochmals für alle zum Mitschreiben. Die For Next Schleife an sich ist langsam, nicht das was dazwischen evtl. abgefrühstückt wird!?

[brandelh]

Hallo Manfred,

das natürlich auch, außer man kann einen "SuperBefehl / Funktion" benutzen, die andere nicht haben und selbst programmieren müssen.

[AUGE_OHR]

hi,

was auch noch mit ein Grund sien kann:
Unter Clipper ging das mit den Prozeduren und Funktionen ja z.B. so:

Code: Alles auswählen

PROCEDURE a
PARAMETERS b, c, d
...
RETURN
...
PROCEDURE b
...
RETURN

Das geht unter Xbase++ nicht! Da muss das so heißen:

Code: Alles auswählen

PROCEDURE a( b, c, d )
...
RETURN
...
PROCEDURE b()
...
RETURN

Ergänzung : Wenn Xbase++ z.Z. deinen Code wegen "PARAMETER" an-
meckern sollte dann liegt es daran das PARAMETER unter Xbase++ eine
PRIVATE ist. Wenn du also LOCAL verwendest und PARAMETER "davor"
kommt mag das Xbase++ nicht.

Wenn du das so wie Martin vorgeschlagen hat umschreibst dann denke
daran das die übergebenen "Parameter" dann LOCAL sind und ob sich
das mit deinem Code verträgt oder du die "Parameter" per Referenz
übergibst.

[FlashNash]

Thx @Alle für die erneuten Hinweise. Morgen habe ich wieder etwas freie Zeit und dann werde ich das mit den Return-Errors mal angehen.

Sind zwar nur ein paar wenige (ca. 4...5) aber die müssen ja weg. Mein Ziel ist es, den alten Clipper Code zuerst einmal fehlerfrei mit XBase compillieren zu können. Was danach der Linklauf an Errors liefert, na das werde ich dann sehen.

Wünsche allen einen coolen Wochenstart.

[AUGE_OHR]

hi,

solltest du an irgend einer Stelle deinen Cl*pper Code nicht ändern
wollen/können/dürfen dann kannst du die Konstante "__XPP__" benutzen.

Code: Alles auswählen

#IFDEF __XPP__
   // Xbase++ Code
#ELSE 
   // Cl*pper Code
#ENDIF