| |
| |
|
| - Seite 1 - |
|
Georg
Teles | Guten Abend,
nun bastel ich an meinem Cryptsystem & unter Anderem wollte ich ein Quellcode zu etwas Ähnlichem hier posten und stelle fest, dass mit XPSE kompilierte Programme in nativen Prozeduren mit Schleifen einen Wert immer um 7 größer zurückgeben als er sein sollte...
hier 2 Beispiele als Quelltexte:
mit XProfan kompilierter Text, Prozedur gibt richtigen Wert zurück (55619):
KompilierenMarkierenSeparierenDeclare dat#,dat&,res&
Declare wert$
Dim dat#,8
CLS 0
Word dat#,0 = 9812,3484,60000,22315
res& = cryrst_(dat#,8)
wert$ = Str$(res&)
print wert$
Waitinput
Proc cryrst_
Parameters ber#,ps&
Declare s&,res&
If ps& MOD 2 = 0
s& = (ps&\2)-1
Else
s& = (ps&\2)
EndIf
WhileLoop 0,s&
res& = res&+word(ber#,&loop*2)
If res& > 20000
res& = (res&-20000)
Endif
EndWhile
res& = (res&+ps&)
Return res&
EndProc
haargenau selber Code in XPSE, gibt den richtigen Wert der um 7 größer ist (also 55626):
KompilierenMarkierenSeparieren {$cleq}
Declare dat#,dat&,res&
Declare wert$
Dim dat#,8
CLS 0
Word dat#,0 = 9812,3484,60000,22315
res& = cryrst_(dat#,8)
wert$ = Str$(res&)
print wert$
Waitinput
nProc cryrst_
Parameters ber#,ps&
Declare s&,res&
If ps& MOD 2 = 0
s& = (ps&\2)-1
Else
s& = (ps&\2)
EndIf
WhileLoop 0,s&
res& = res&+word(ber#,&loop*2)
If res& > 20000
res& = (res&-20000)
Endif
EndWhile
res& = (res&+ps&)
Return res&
EndProc
gibt es hierfür eine Erklärung ? |
|
| |
| |
| |
|
 |
« Dieser Beitrag wurde als Lösung gekennzeichnet. » |
|
 | In nProcs mit declare deklarierte Variablen haben nicht gleich den Wert 0,
die Variable wird zwar deklariert aber es wird ihr kein Wert zugewiesen und der Wert
kommt dann aus dem Speicher und kann beliebig sein.
Anders ist es (natürlich) wenn man innerhalb nProcs mit var deklariert z.B.
KompilierenMarkierenSeparieren
oder kürzer:
KompilierenMarkierenSeparieren |
|
| |
| |
| |
|
|
|
| Bereichsvariablenparameter sind kein nativ unterstützer Typ,
übermittle mal die Adresse als Long. (also addr(ber#) statt (ber).
Nach logischen Fehlern habe ich beim Überfliegen nicht geschaut. |
|
| |
| |
| |
|
|
Georg
Teles | |
| |
| |
| |
|
|
Georg
Teles | Problem gelöst:
ich merke, dass es bei XPSE es sehr wichtig ist, definierte Variablen, mit denen man arbeitet, auf 0 oder einen Wert zu setzen, den man braucht...
KompilierenMarkierenSeparieren
nun liefert sowohl mit XProfan kompilierte & gelinkte Quelltext als auch mit XPSE den selben korrekten Wert  |
|
| |
| |
| |
|
|
E.T. | Hm, das verwundert mich doch etwas:
Sollten den neu declarierte Variablen >Declare c&,d& < nicht eigentlich auf "0", d.h. leer sein ?? 
Ach, sehe gerade:
Im Eingans-Posting declarierst du res& 2x, einmal beim Programm-Start und dann nochmal in der Proc / nProc.
Bei "Problem gelöst" declarierst du dann im "nProc-Schnipsel" c& und b& , also neue Variablen.
Ich denke mal, im "Doppel-Declare" liegt der Hase begraben (ungetestet).
Was mich wundert ist, das XProfan bei deinem ersten Beispiel im ersten Post nicht meckert, das die Variable bereits declariert ist  .
In der Hilfe ist nur zu lesen
Alle Variablen, die in Prozeduren deklariert werden, sind nur dort lokal gültig. Der verwandte Speicherplatz wird bei Verlassen der Prozedur wieder freigegegen
Was passiert, wenn in der Proc Variablen declariert werden, welche schon im Hauptprogramm decl. wurden, das kann uns wohl Roland beantworten 
Frag jetzt bitte nicht, warum genau "um 7 mehr"...
... vlt. hat IF ja für diesen Fall "Die glorreichen Sieben" in XPSE eingebaut  |
|
| |
| Grüße aus Sachsen... Mario  WinXP, Win7 (64 Bit),Win8(.1),Win10, Win 11, Profan 6 - X4, XPSE, und 'nen schwarzes, blinkendes Dingens, wo ich das alles reinschütte... | 17.09.2014 ▲ |
|
| |
|
|
Georg
Teles | E.T. (17.09.14)
Ach, sehe gerade:
Im Eingans-Posting declarierst du res& 2x, einmal beim Programm-Start und dann nochmal in der Proc / nProc.
...
Ich denke mal, im "Doppel-Declare" liegt der Hase begraben (ungetestet).
Negativ, habe gerade mit anderen Variablen getestet, selbes Ergebnis, exakt um 7 größer wenn ich die Variablen nach dem Declare nicht nulle
möglicherweise darf keine Variable 0 sein und das Declare der "leeren Variable" den Wert 7 zuweist ?
E.T. (17.09.14)
Was passiert, wenn in der Proc Variablen declariert werden, welche schon im Hauptprogramm decl. wurden, das kann uns wohl Roland beantworten
das würde mich aber auch interessieren, meiner Erfahrung nach geht lokal vor global, habe in meinen Programmen aber nie diesen Fehler gemacht, nur in Codesnippets getestet |
|
| |
| |
| |
|
|
RGH | Wenn in einer Prozedur Variablen deklariert werden, die auch schon im Hauptprogramm deklariert sind, dann sind die im Hauptprogramm deklarierten Variablen in der Prozedur nicht sichtbar, d.h. sie können in der Prozedur weder gelesen noch geändert werden.
Gruß
Roland |
|
| |
| XProfan X2Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD - ATI Radeon HD 4770 512 MB - Windows 7 Home Premium 32Bit - XProfan X4 | 17.09.2014 ▲ |
|
| |
|
|
| In nProcs mit declare deklarierte Variablen haben nicht gleich den Wert 0,
die Variable wird zwar deklariert aber es wird ihr kein Wert zugewiesen und der Wert
kommt dann aus dem Speicher und kann beliebig sein.
Anders ist es (natürlich) wenn man innerhalb nProcs mit var deklariert z.B.
KompilierenMarkierenSeparieren
oder kürzer:
KompilierenMarkierenSeparieren |
|
| |
| |
| |
|
|
Georg
Teles | Ahh, vielen Dank ! Nun sind beide Fragen geklärt worden.
Das mit Declare erklärt auch, dass in jedem Beispielcode Ende% vor der Whilenot-Schleife tradiztionell mit Clear gelöscht bzw als var ende% = 0 deklariert und zur Sicherheit auf 0 gesetzt wird.
Dies ist seit Programmiertanfang an bei mir zum Standard geworden weil bei meinen Programmen oft selbe Variablen mehrmals verwendet werden, zB. temporäre, aber genauer darauf habe ich nur noch nie geschaut  |
|
| |
| |
| |
|
(890)
Deutsch
English
Français
Español
Italia