3. [GELÖST] Problem mit istream

[GELÖST] Problem mit istream

  • S

    Ich arbeit gerade daran die Rechenoperatoren zu interpretieren.
    Und die float/double-Konstruktoren werden dann zu Brüchen generiert.

    Also wenn man folgend Code hat:

    ...

int main()
{
    Bruch br(2.58);

    cout << br << endl;

    return 0;
}

    Dann kommt dabei das raus.

    17/8

    Ich finde diese automatische Umwandlung sehr praktisch, deswegen habe ich sie interpretiert.

    0
  • C

    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 😉

    0
  • S

    Dann kommt 1/10 raus...

    0
  • C

    StringMath-Projekt schrieb:

    Dann kommt 1/10 raus...

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

    0
  • S

    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?

    0
  • C

    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.

    0
  • S

    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?

    0
  • C

    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() ).

    0
  • S

    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
    0
  • C

    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.

    0
  • S

    ok.

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

    0
Anmelden zum Antworten