XProfan

Italia

KHR

Hallo miteinander,

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

Dabei hat mich das Comportamento di P2CPP bei schreiben von INI-File 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 corre. 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!

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

17.12.2008 ▲

Vollständiges Zitat

Absatzweise Citazione Zeilenweise Citazione

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 Aiuto 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 Aiuto, 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 per WriteIni mit Ini-File 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. ;)

Saluto
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 Citazione Zeilenweise Citazione

Sebastian
König

Ciao,

auch in Profan2Cpp findet eine automatische Typenumwandlung statt (es gibt mehrere Versionen per 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 naturalmente 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 Citazione Zeilenweise Citazione

RGH

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

Saluto
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%

endpr

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 per 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}

(naturalmente muss man dann die Funktionen nicht (wie hier im Beispiel) in un einzige Zeile "ziehen")

Wenn es mal interessant wird, dann potuto 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 Citazione Zeilenweise Citazione