Neues SDK kompiliert nicht alles, was das alte SDK kompiliert

    Ich habe folgende Funktion definiert:

    Code
    FloatNum exp(FloatNum zahl1)
{ 
  FloatNum zahl3;
  
  FloatPushNumber(&zahl1);
  FloatExp();
  FloatPopNumber(&zahl3);
  return(zahl3);
}

    Das alte SDK hat kein Problem damit und die Funktion funktioniert dann auch.

    Das neue SDK sagt:

    Hm?

    Ich habe nur ein Beispiel mit word als Parameter- und Return-Type:

    Code
    word _pascal Random(word max)
{
 // Calculate a random number
 FloatWordToFloat(max); // S1 = m
 FloatRandomN();        // S1 = rnd(m)
 // Return the result from the FP stack
 return FloatFloatToDword();
}

    Vielleicht hilft schon einmal _pascal bei der Definition.

    Oder das Problem liegt daran, dass Watcom keinen 80-bit Float-Typ unterstützt. Um das anzupassen kann man sich ein Makro basteln. Uli musste das bei seinem GeoCosmos auch machen. Details dazu wissen sicher fast alle anderen aktiven Programmierer...

    Hallo Wilfried,

    FloatNum sollte (muss) eigentlich gehen. Die Meldung kommt ja auch nicht im Code, sondern in der GOH. Stimmt die Definiton in der goh exakt mir der im Code überein?

    Das Problem dahinter ist, das bei BCC "long double" 10 byte waren, in Watcom sind es nur noch 8. Das war ein Schock und wurde so gefixt, dass die Float~ Routinen nur noch die Struktur FloatNum akzeptieren, "long double" geht nicht mehr. In vielen Fällen reicht es, "long double" einfach durch FloatNum zu ersetzen.

    Wenn du allerdings damit rechnen willst, wird es aufwändiger. Dann hilft vielleicht folgendes Beispiel:
    pcgeos\Appl\Breadbox\testapps\mathtest

    LG
    Rainer

    Es gibt 10 Arten von Menschen - die einen wissen was binär ist, die anderen nicht.

    Hallo Wilfried,

    leider befinden wir uns da in einem Bereich, der zwischen altem BC-basierten SDK und neuem WATCOM-basierten SDK unterschiede aufweist. Das Problem ist, dass wir im neuen SDK double float haben die 64bit weit sind, im alten SDK dagegen 80bit. Aus dem Grund war es im alten SDK standard, das man double und FloatNum synonym verwenden konnte, das geht leider mit dem neuen SDK nicht und man muß aktiv Konvertierung machen. Das betritt GrafCalc leider an vielen Stellen, ich habe das schon irgendwo mal exemplarisch übertragen. Ich begebe mich mal auf die Suche und schicke Dir es per E-Mail, wenn ich es finde!

    Viele Grüße, Falk \\ blueway.Softworks

    Edited once, last by frehwagen (December 5, 2024 at 8:11 PM).

    Oh oh, das kann ja heiter werden.;(

    Aber zumindest ist das Problem gelöst.:)

    Eigentlich ist es für mich ja kein Problem, da ich beide SDKs betreibe. Sollte aber eins meiner Projekte mal in FreeGeos aufgenommen werden, dann muss der Code natürlich vom aktuellen SDK übersetzt werden können...

    Dazu kommt noch (hab ich gerade gesehen), dass meine Funktion exp in der aktuellen math.h definiert ist, in meiner alten math.h aber nicht.

    Beispiel von Falk für den Euroconverter:

    FloatNumStruct changes;
        double tmpChanges;
    tmpChanges = dm;
        FloatIEEE64ToGeos80(&tmpChanges);
    FloatPopNumber(&changes);
    w = FloatFloatToAscii_StdFormat(tempBuffer,
    &changes,
    FFAF_FROM_ADDR | FFAF_NO_TRAIL_ZEROS,
    INPUT_VALUE_TEXT_LEN,
    5);
    bool = FloatAsciiToFloat(FAF_STORE_NUMBER,15,tempBuffer,&dmx);


    Gruss von Nico