[GELÖST] Problem mit istream



  • StringMath-Projekt schrieb:

    Ich arbeit gerade daran die Rechenoperatoren zu interpretieren.

    Da sind dann die operator int() etc. eher ein Problem - und erzeugen Mehrdeutigkeiten:

    bruch b(1,2);
    int i = 5;
    cout << i + b << endl;
    

    Hier kann sich der Compiler nicht entscheiden, ob er i in den Bruch 5/1 umwandelt und deinen Operator nutzt oder b in einen int umwandelt und per eingebautem Operator die Summe berechnet.

    Dann kommt dabei das raus.

    17/8

    Dann versuch das mal mit der Eingabe 0.1 😉



  • Dann kommt 1/10 raus...



  • StringMath-Projekt schrieb:

    Dann kommt 1/10 raus...

    Geraten oder ausprobiert? (wenn letzteres, würde mich mal interessieren, wie der double-Konstruktor aussieht)



  • Zu deinem angespielten Problem:

    Stimmt, das habe ich wohl auch übersehen.

    Gibt es nicht eine Lösung, die dem Compiler sagt, dass er erst die Rechen-Operatoren benutzen soll, bevor er die Umwandlung anwendet?



  • StringMath-Projekt schrieb:

    Gibt es nicht eine Lösung, die dem Compiler sagt, dass er erst die Rechen-Operatoren benutzen soll, bevor er die Umwandlung anwendet?

    Ja, gibt es - verzichte auf unnötige implizite Umwandlungen und wandle lieber explizit um.



  • explict heißt, dass ich für die Umwandlung den Datentyp in Klammerns chreiben muss?
    Also:

    int i = 2;
    Bruch br(25);
    int j = i + (int)br;
    

    Also j = 27?



  • StringMath-Projekt schrieb:

    explict heißt, dass ich für die Umwandlung den Datentyp in Klammerns chreiben muss?

    In der Form funktioniert es leider nur für die Umwandlungs-Konstruktoren (ich bin mir nicht sicher, ob C++0x daran etwas geändert hat), für die Umwandlung in build-in Typen würde ich eine Methode verwenden (ala b.toInt() ).



  • Aber bei den ganzen integer-Typen geht es doch auch!

    Wenn da steht:

    int i =20;
    long j = 1235;
    
    //Beispiel 1:
    
    i + j // ist int
    
    //Beispiel 2:
    
    j + i // ist long
    


  • StringMath-Projekt schrieb:

    Aber bei den ganzen integer-Typen geht es doch auch!

    Bei den integer-Typen ist im Standard auch eine eindeutige Regel festgelegt, wie sie ineinander umgewandelt werden sollen (übrigens sind beide Beispiele vom Typ long). Bei benutzerdefinierten Typumwandlungen gibt es keine Rangfolge - alle Umwandlungs-Konstruktoren und -Operatoren sind gleichwertig bei der Auswahl, wie eine Überladung aufgelöst werden soll.



  • ok.

    Ich werde mir das mit den Funktionen (also toInt(), ...) mal überlegen.


Anmelden zum Antworten