Kryptische Fehler bei "Endgültig"- (Release-) Kompilierung



  • Alexander:
    Zeile 232 ist die Zeile mit der abschliessenden geschweiften Klammer ('}').



  • Wird wohl daran liegen, daß OleVariant kein Datentyp sondern eine Klasse ist und so der Cast auf int als Fehlerursache zu sehen ist.



  • Ich würde eher auf einen Compilerfehler tippen.
    Beim BCB5 existiert nur ein Operator __fastcall operator unsigned short() const

    unsigned short ist allerdings kompatibel zu int ,also sollte das Ganze funktionieren.
    Probier mal folgendes :

    return CurVal.operator unsigned short();
    


  • Peter, Case:
    für OleVariant sind cast operatoren für alle gängigen Datentypen definiert (zumindest bei BCB6, zumindest über ihre Basisklasse Variant).
    Peter,

    return CurVal.operator unsigned short();
    

    funktioniert auch nicht (auch nicht mit -int() ). War aber eine gute Idee.



  • Läßt sich denn das Ganze kompilieren, wenn Du einfach eine 0 zurückgibst?
    Also anstatt

    int WordWrapper::ReadInt (void)
    {
        OleVariant CurVal;
        //... langweilige Berechnungen ...
         return (int)CurVal;
    }
    
    int WordWrapper::ReadInt (void)
    {
        OleVariant CurVal;
        //... langweilige Berechnungen ...
         return 0;
    }
    


  • Alexander:
    im Debug-Modus lässt es sich so oder so kompilieren, im Release-Modus nicht.

    Ich habe auf Deine Frage hin ein wenig mit verschiedenen Casts, Neudefinitionen und Rückgabewerten experimentiert: es kam immer der gleiche Fehler.

    Wenn ich den Code für die "langweiligen Berechnungen" allerdings ausgeklammert habe, ging's!

    Etwas Probieren hat ergeben, dass es nicht am o.g. Casting liegt, sondern vermutlich an der Zeile:

    CurVal = (OleVariant)CurRange->get_Value();
    

    Wie gesagt, nur im Release Modus.



  • Tilsiter schrieb:

    Etwas Probieren hat ergeben, dass es nicht am o.g. Casting liegt, sondern vermutlich an der Zeile:

    CurVal = (OleVariant)CurRange->get_Value();
    

    Und von welchem Typ ist CurRange und was gibt get_Value() zurück?



  • Sorry, hatte ich ganz vergessen:

    OleVariant  CurVal;
    RangePtr    CurRange;
    

    RangePtr ist in der Excel-TLB definiert, ein Zeiger auf eine Range (= Bereich innerhalb eines Worksheets), also COM / Office-Automatisierung.

    Und get_Value() gibt ein tagVARIANT Objekt zurück. Sollte kompatibel sein mit OleVariant. Ist es wohl auch, sonst würde das Programm ja nicht in der Debug-Version funktionieren.

    CurVal und CurRange sind nicht in der Funktion definiert (wie ich oben angedeutet hatte), sondern in der Klasse als private Member.



  • Anstatt

    CurVal = (OleVariant)CurRange->get_Value();
    

    kannst Du's ja mal testweise nur mit dem Funktionsaufruf probieren,
    um den Fehler weiter einzugrenzen.

    CurRange->get_Value();
    

    Wenn's dann funktioniert, ist wohl was mit dem cast nicht in Ordnung,
    sonst wird's schwierig (zumindest für mich).



  • Ich hatte die Ursache der Fehlermeldung inzwischen irgendwann mal isoliert, und wollte nur nochmal mein Ergebnis hier festhalten, für den Fall dass jemand ein ähnliches Problem lösen muss.

    Das Problem ist die Kompilierung mit der Optimierungsoption "Register". Ein Register hat halt keine Speicheradresse, und das beisst sich wohl mit dem Rückgabewert, den der Compiler vermutlich in einem Register unterbringen will (Himmel weiss warum) statt auf dem Stack.

    Es liegt einzig an dieser Option. Wenn "register" Optimierung ausgeschaltet ist, funktioniert alles einwandfrei. Es ist ein Fehler des Compilers, und könnte auch in anderen Konstellationen vorkommen.

    Schade, dass man keine "bloss-kein-register" Speicherklasse angeben kann 😉


Anmelden zum Antworten