op>> + op<< + stream

[Columbo]

Sollte der operator>> nicht besser friend der Klasse fraction sein (um dann direkt die Member zu setzen)?

Warum denn das?

[Th69]

Was ist denn dann deine Alternative dazu?

Eigentlich sollte m.E. so eine Klasse (bzw. Struktur) immutable sein - dann kann man jedoch den operator<<() nicht benutzen, sondern müsste eine Funktion

fraction read(std::istream &istr)

o.ä. erzeugen.

[volkard]

Arcoth schrieb:

Sollte der operator>> nicht besser friend der Klasse fraction sein (um dann direkt die Member zu setzen)?

Warum denn das?

Um die Attribute privat zu halten.

[Columbo]

Das war nicht sarkastisch gemeint. Ich dachte Th69 will total ueberfluessigerweise einen friend draus machen.

Ich wusste ja nicht dass ihr die Struktur nach aussen hin immutable machen wollt - das halte ich naemlich nicht fuer sinnvoll. Warum?

[volkard]

Arcoth schrieb:

Ich wusste ja nicht dass ihr die Struktur nach aussen hin immutable machen wollt - das halte ich naemlich nicht fuer sinnvoll. Warum?

Naja, ein Setter dürfte es schon sein, getrennt vom Getter. Solange kein Bedarf an sowas ist, mache ich nicht auf. Und siehe da, in 4 Wochen gibt's immernoch keinen Setter. Irgendwann kommt man daher und kürzt die Brüche oder erzwingt, daß demom!=0 oder gar positiv. Das halte ich mir einfach offen.

[Th69]

@Arcoth: du hast trotzdem noch nicht meine Frage beantwortet - was ist deine Alternative zum friend (ohne Setter)?

[Columbo]

(sowie gleiches bei denom()) finde ich doch arg unsauber (dann kann man gleich public Member nehmen). Sollte der operator>> nicht besser friend der Klasse fraction sein (um dann direkt die Member zu setzen)?

Wo steht da auch nur ansatzweise irgendwas von Immutability? Du hast nur darauf hingewiesen dass man lieber public Member anstelle von derartigen Funktionen nehmen kann. Solange man die Member von außen direkt verändern kann braucht man kein friend.

[camper]

volkard schrieb:

Arcoth schrieb:

Ich wusste ja nicht dass ihr die Struktur nach aussen hin immutable machen wollt - das halte ich naemlich nicht fuer sinnvoll. Warum?

Naja, ein Setter dürfte es schon sein, getrennt vom Getter. Solange kein Bedarf an sowas ist, mache ich nicht auf. Und siehe da, in 4 Wochen gibt's immernoch keinen Setter. Irgendwann kommt man daher und kürzt die Brüche oder erzwingt, daß demom!=0 oder gar positiv. Das halte ich mir einfach offen.

Man sollte aber schon wissen, ob man Brüche oder rationale Zahlen implementieren will...

[volkard]

Arcoth schrieb:

(sowie gleiches bei denom()) finde ich doch arg unsauber (dann kann man gleich public Member nehmen). Sollte der operator>> nicht besser friend der Klasse fraction sein (um dann direkt die Member zu setzen)?

Wo steht da auch nur ansatzweise irgendwas von Immutability? Du hast nur darauf hingewiesen dass man lieber public Member anstelle von derartigen Funktionen nehmen kann. Solange man die Member von außen direkt verändern kann braucht man kein friend.

"(dann kann man gleich public Member nehmen)" war wie "(dann kann man sich auch gleich erschießen)". Das war doch keine Handlungsempfehlung! Trink erstmal nen Kaffee, ist noch sehr früh am Tag.

[volkard]

camper schrieb:

volki schrieb:

Naja, ein Setter dürfte es schon sein, getrennt vom Getter. Solange kein Bedarf an sowas ist, mache ich nicht auf. Und siehe da, in 4 Wochen gibt's immernoch keinen Setter. Irgendwann kommt man daher und kürzt die Brüche oder erzwingt, daß demom!=0 oder gar positiv. Das halte ich mir einfach offen.

Man sollte aber schon wissen, ob man Brüche oder rationale Zahlen implementieren will...

Ach, das halte ich mir vielleicht am besten auch noch offen.

[Th69]

@Volkard: genau so war es gemeint - irgendwie kommt mein Sarkasmus wohl nicht immer an!?