[GELÖST] Problem mit istream

[hustbaer]

Wie tu ich dann Null in deine Klasse rein, wenn der Zähler 1 sein muss?
Ich denke mal du hast das verwechselt: der Nenner darf nicht Null sein.

0/1 = 0
1/0 = ....

[StringMath-Projekt]

Stimmt! Hab ich in dem Meont ganz verwechselt.

[CStoll]

StringMath-Projekt schrieb:

Ich hatte das mit "den Großen Drei" nicht verstanden. (Weil ich das so nicht kannte) Und den Kopierkonstruktur kann ich dann wirklich rausnehmen, nur die Leere Zuweisung(Bruch ohne Argumentenliste) bleibt, weil die die beiden long-Werte nicht 0 sein dürfen. Der zaehler MUSS nämlich 1 sein.

Der Default-Konstruktor ist auch kein Problem. Aber ansonsten kannst du auch die impliziten Umwandlungen nutzen, die der Compiler bietet - und alle Ganzzahl-Konstruktoren zu einem zusammenfassen: Bruch(long long z=0,long long n=1); (das erschlägt auch den Default-Konstruktor). Was die float/double-Konstruktoren machen sollen, bin ich mir auch nicht sicher.
Auf der anderen Seite dürfte die implizite Umwandlung nach int ein Problem darstellen, wenn du mit gemischten Operationen zu tun hast (wird der Ausdruck "i*b" jetzt mit int-Arithmetik oder mit Bruch-Operatoren berechnet?).

[StringMath-Projekt]

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.

[CStoll]

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

[StringMath-Projekt]

Dann kommt 1/10 raus...

[CStoll]

StringMath-Projekt schrieb:

Dann kommt 1/10 raus...

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

[StringMath-Projekt]

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?

[CStoll]

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.

[StringMath-Projekt]

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?

[CStoll]

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

[StringMath-Projekt]

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

[CStoll]

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.

[StringMath-Projekt]

ok.

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