XProfan

Deutsch

KHR

Hallo miteinander,

als stolzer neuer Anwender von P2CPP bin ich gerade dabei einige Programme auf P2CPP "umzustricken"

Dabei hat mich das Verhalten von P2CPP bei schreiben von INI-Dateien einige Zeit gekostet.
Erst nach längerem Suchen habe ich dann den Unterschied entdeckt.

Xprofan wandelt Variablenwert (integer und float) automatisch richtig um, P2CPP macht das nur bei integer richtig, floats wandelt es in integer um.

Natürlich kann man das leicht mit @str$(float) umgehen, aber man muß erst mal drauf kommen, was und wieso da nun anders läuft. Vielleicht nutze ich da ja auch nur was, das eher ungewollt in Xprofan funktioniert und so nicht zur Verwendung gedacht ist.

Hier mein Beispiel-Programm und die Ergebnisse:
Kompilieren Markieren Separieren

declare INI_Datei$
declare temp1%
declare temp2!
 $IFDEF P2CPP
INI_Datei$ ="D:\TMP\P2CPPTEST.INI"
 $ENDIF
 $IFDEF COMPILER
INI_Datei$ ="D:\TMP\XP11TEST.INI"
 $ENDIF

whileloop 8

    temp1% = @rnd(500)
    temp2! = @rnd()*500
    WriteIni INI_Datei$,"Integer","Parameter-"+@trim$(@str$(&loop)) = temp1%
    WriteIni INI_Datei$,"Float","Parameter-"+@trim$(@str$(&loop)) = temp2!

endwhile

Als Ergebnis erhalte ich bei P2CPP:

[Integer]
Parameter-1=405
Parameter-2=373
Parameter-3=29
Parameter-4=183
Parameter-5=160
Parameter-6=119
Parameter-7=146
Parameter-8=200
[Float]
Parameter-1=0
Parameter-2=281
Parameter-3=96
Parameter-4=404
Parameter-5=292
Parameter-6=239
Parameter-7=175
Parameter-8=447

und bei Xprofan:

[Integer]
Parameter-1=0
Parameter-2=430
Parameter-3=136
Parameter-4=159
Parameter-5=186
Parameter-6=41
Parameter-7=35
Parameter-8=29
[Float]
Parameter-1=15.689970
Parameter-2=101.290483
Parameter-3=335.827209
Parameter-4=80.897733
Parameter-5=212.836884
Parameter-6=237.397032
Parameter-7=420.427217
Parameter-8=146.648286

Egal ob nun Bug oder feature - man sucht ne weile bis man die Ursache findet

Gruß
Karl-Heinz
WIN XP home/Pro / XPROFAN 11 / P2CPP
ATMEL + BASCOM Fan

17.12.2008 ▲

Vollständiges Zitat

Absatzweise zitieren Zeilenweise zitieren

RGH

KHR

Egal ob nun Bug oder feature - man sucht ne weile bis man die Ursache findet

Weder Bug noch Feature, sondern falscher Parametertyp: Laut Hilfe ist der letzte Parameter bei WriteIni ein String, also wäre man mit @Str$() auf der sicheren Seite.
Lässt man dieses weg, greift bei XProfan die automatische Typumwandlung (siehe Hilfe, Abschnitt 7.8 ), die den numerischen Wert in einen Sttring umwandelt, wobei die Einstellungen durch @Set("Decimals",...) und @Set("NumWidth",...) berücksichtigt werden.
XProfan benutzt für WriteIni mit Ini-Dateien ausschließlich die API-Funktion WritePrivateProfileString.
Möglicherweise nutzt P2CPP bei numerischen Werten die API WritePrivateProfileInt, was erklären würde, dass hier die Umwandlung in einen Integer erfolgt.

Wenn man auf der sicheren Seite sein möchte, sollte man nichts dem Zufall und die Typumwandlung nicht der Programmiersprache überlassen. ;)

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

17.12.2008 ▲

Vollständiges Zitat

Absatzweise zitieren Zeilenweise zitieren

Sebastian
König

Hallo,

auch in Profan2Cpp findet eine automatische Typenumwandlung statt (es gibt mehrere Versionen für WriteIni() und je nach Typ des letzten Parameters wird die passende aufgerufen). Das Problem ist, dass Fließkommazahlen dabei bisher nicht explizit berücksichtigt werden und C++ offenbar in diesem Fall lieber die Integer- als die String-Version benutzt. Ich werde das in der nächsten Version ändern, damit das Verhalten in Profan2Cpp und XProfan gleich ist. Abgsehen davon hat Roland natürlich recht damit, dass die Verwendung von str$() in jedem Fall die sicherste Variante ist ;).

MfG

Sebastian

Windows XP, XProfan/Profan² 4.5 bis 11
Profan2Cpp-Homepage: [...]

Alte Profan²-Seite: [...]

17.12.2008 ▲

Vollständiges Zitat

Absatzweise zitieren Zeilenweise zitieren

RGH

Wenn man auf der sicheren Seite sein möchte, sollte man nichts dem Zufall und die Typumwandlung nicht der Programmiersprache überlassen. ;)

Gruß
Roland

Jau!

Die automatische Typumwandlung gestaltet das Fehlerfinden manchmal ziemlich langwierig.

Es gibt aber eine undokumentierte Schreibweise (xpse) welche die Voraussetzungen erfüllt, dass Funktionen auch nur den definierten Typ zurückgeben (können).

Normales XProfan:
Kompilieren Markieren Separieren

proc meineProc

    parameters a%,b%,c%
    return a%+b%+c%

endproc

Kleines XPSE 1: (keine Parameters Zeile)
Kompilieren Markieren Separieren

proc meineProc(a%,b%,c%)

    return a%+b%+c%

endproc

Kleines XPSE 2: (kein PROC und ENDPROC, statt dessen wie z.B. in c#, php und js geschweifte Klammer für Block.)
Kompilieren Markieren Separieren

meineProc(a%,b%,c%){

    return a%+b%+c%

}

Kleines XPSE 3: (Wegfall der Variablensuffixe, statt dessen wie z.B. in c#, php, js und pascal/delphi)
Kompilieren Markieren Separieren

meineProc(int a,b,c){

    return a+b+c

}

Kleines XPSE 4: (Funktion "meineProc" zum Typ "int" deklarieren um z.B. sicher zu stellen, dass z.B. kein String zurückgegeben wird)
Kompilieren Markieren Separieren

int meineProc(int a,b,c){

    return a+b+c

}

setzt man den Typ vor dem Namen einer Funktion, wird der Funktionswert auch nur von diesem Typ zurückgegeben. Folgende Varianten sind seither vorhanden:
Kompilieren Markieren Separieren

bool meineProc(int a,b,c){return a+b+c}
int meineProc(int a,b,c){return a+b+c}
long meineProc(int a,b,c){return a+b+c}
float meineProc(int a,b,c){return a+b+c}
string meineProc(int a,b,c){return a+b+c}

(natürlich muss man dann die Funktionen nicht (wie hier im Beispiel) in eine einzige Zeile "ziehen")

Wenn es mal interessant wird, dann könnte xpse also auch die Rückgabewerte von Funktionen bei Zuweisungen auf Typengleichheit überprüfen - wo er doch eh als Überbringer unangenehmer Botschaften gefeiert wird.

@KHR: XPSE war damals auch wegen Profan2CPP entstanden, funktioniert {$cpp} bei Dir oder nutzt XPSE nicht?

17.12.2008 ▲

Vollständiges Zitat

Absatzweise zitieren Zeilenweise zitieren