Frage zur Typumwandlung

drakon

Natürlich kann man +,-,/,* so implementieren, wie das drakon schreibt - aber ich finds nicht sooo übersichtlich... (mal davon abgesehen, dass es so falsch ist, wie es drakon geschrieben hat)
hier wäre die richtige implementation:

Ich habe ja geschrieben, dass er auch += nutzen kann. Das andere war ja nur ein Beispiel, dass er auch direkt auf die Variablen zugreifen kann. (Das es ein Bruch ist, habe ich gar nicht richtig gesehen. Ich habe einfach die Member genommen.. Klar kann man die nicht einfach zusammenzählen..)

Würd ich nicht machen - aber das musst du für dich selbst entscheiden...

Und was bitteschön stört dich an der öffentlichen Membern?

unskilled

drakon schrieb:

Das andere war ja nur ein Beispiel, dass er auch direkt auf die Variablen zugreifen kann.

Sollte ja auch kein Vorwurf sein - mir ist schon klar, dass du das nur zeigen wolltest und dabei vrmtl nicht weiter drüber nachgedacht hast - weils auch keine Rolle gespielt hat... Nur, dass es ihn nicht total irritiert...

drakon schrieb:

Würd ich nicht machen - aber das musst du für dich selbst entscheiden...

Und was bitteschön stört dich an der öffentlichen Membern?

Warum soll man von außen den Bruch manipulieren können?
Es zerstört (unsinnigerweise) die gesamte Kapselung... Beim Vector könnte es da ja sicherlich Anwendungen geben - obwohl mir keine einfällt...

Aber beim Bruch...
Mach doch mal nen Bsp., wo so etwas sinnvoll wäre...

bb

Nexus

Ich stimme unskilled hier auch zu, da es wohl selten Fälle geben wird, wo man nur den Zähler oder nur den Nenner ändert (für diese Fälle kann man immer noch Methoden anbieten). Eher wird man gerade den ganzen Bruch neusetzen oder mit den Operatoren manipulieren...

unskilled

Nexus schrieb:

da es wohl selten Fälle geben wird, wo man nur den Zähler oder nur den Nenner ändert

Fällt dir denn ein Fall ein? Mir fällt echt keiner ein...
Vll sollte man noch ne Funktion erweitern hinzufügen (und die kürzen Funktion existiert noch immer nicht - genau so, wie die Vergleichsoperatoren noch fehlen)...

bb

drakon

Ich sehe nicht, warum das die Kapselung stören sollte. Wenn ich einen Zähler, oder Nenner setzen will, dann sollte der auch den Wert bekommen. Bei 0 im Nenner kann man sich natürlich streiten, aber imo hat selbst das nichts in einer Bruchklasse zu suchen.

Aber allgemein habe ich bis jetzt noch nie eine Bruch Klasse gebraucht.

Kürzer. Wie schon gesagt, kannst du das ja alles in einem schreiben, aber macht imo nicht wirklich Sinn. Vor allem kannst du das Verhalten so an einer Stelle abändern, ohne den + Operator anfassen zu müssen.

Nexus

Nunja, in der Praxis wohl eher nicht. Nur wenn man gerade was ausprobiert oder so...

Ich hab mir auch vor einiger Zeit mal eine Bruchklasse geschrieben, da sind die Methoden für das Verändern von entweder Zähler oder Nenner auch noch drin. Gebracht habe ich die aber nie (könnte aber daran liegen, dass ich die gesamte Bruchklasse kaum zum Einsatz kam).

Die Methode Simplify() kürzt den Bruch, AdaptSign() passt das Vorzeichen an (ist nicht unbedingt nötig, ich wollte halt konsistent, dass nur der Nenner negativ sein kann). Ich hab es halt so gemacht, dass nach jedem Rechenschritt gekürzt wird. Ist zwar von der Performance her nicht optimal, aber so werden die Wertebereiche weniger schnell überschritten. Also, hier mal die Schnittstelle meiner Bruchklasse, damit du dich ungefähr orientieren kannst (ist aber nicht unbedingt optimal, wie gesagt könnte man die Setter für Zähler und Nenner weglassen oder beispielsweise eine Umwandlung ToLongDouble() (oder gleich ein Template) implementieren...

class Fraction
{
	private:
		long Num;
		long Denom;

	public:
		Fraction(long Numerator = 0, long Denominator = 1);

		void SetFraction(long Numerator, long Denominator);
		void SetNum(long Numerator);
		void SetDenom(long Denominator);
		long GetNum() const;
		long GetDenom() const;
		float ToFloat() const;
		double ToDouble() const;

		Fraction& Fraction::operator+= (const Fraction& Right);
		Fraction& Fraction::operator-= (const Fraction& Right);
		Fraction& Fraction::operator*= (const Fraction& Right);
		Fraction& Fraction::operator/= (const Fraction& Right);

	private:
		void Simplify()
		void AdaptSign()
};

Zudem sind bei mir noch globale Arithmetik- und Vergleichsoperatoren vorhanden. Ich hab auch Funktionen für kleinstes gemeinsame Vielfache und grössten gemeinsamen Teiler geschrieben, die werden auch intern für das Kürzen verwendet.

const Fraction operator+ (const Fraction& Frac);
const Fraction operator- (const Fraction& Frac);

const Fraction operator+ (const Fraction& Left, const Fraction& Right);
const Fraction operator- (const Fraction& Left, const Fraction& Right);
const Fraction operator* (const Fraction& Left, const Fraction& Right);
const Fraction operator/ (const Fraction& Left, const Fraction& Right);

bool operator<  (const Fraction& Left, const Fraction& Right);
bool operator<= (const Fraction& Left, const Fraction& Right);
bool operator== (const Fraction& Left, const Fraction& Right);
bool operator>= (const Fraction& Left, const Fraction& Right);
bool operator>  (const Fraction& Left, const Fraction& Right);
bool operator!= (const Fraction& Left, const Fraction& Right);

long GreatestCommonDivisor(long Integer1, long Integer2)
long LeastCommonMultiple(long Integer1, long Integer2)

Nexus

drakon schrieb:

Ich sehe nicht, warum das die Kapselung stören sollte. Wenn ich einen Zähler, oder Nenner setzen will, dann sollte der auch den Wert bekommen.

Aber eben genau darum geht es: Wann willst du einzeln einen Nenner oder Zähler setzen, wenn nicht bei der Konstruktion? Und selbst wenn, was würde gegen Methoden dafür sprechen?

drakon schrieb:

Bei 0 im Nenner kann man sich natürlich streiten, aber imo hat selbst das nichts in einer Bruchklasse zu suchen.

Ja, ich persönlich habe es halt lieber, die Klassen sicherer zu machen. Also schauen, dass man eine 0 als Nenner gar nie zulässt.

unskilled

Nexus schrieb:

drakon schrieb:

Bei 0 im Nenner kann man sich natürlich streiten, aber imo hat selbst das nichts in einer Bruchklasse zu suchen.

Ja, ich persönlich habe es halt lieber, die Klassen sicherer zu machen. Also schauen, dass man eine 0 als Nenner gar nie zulässt.

wobei das auch erst zu nem fehler führen würde, wenn man sich den bruch als dezimalwert ausgeben lassen würde... und da kann man ja nen != 0 reinschreiben - sonst sollte man ja nie durch den nenner dividieren müssen!?

bb

Nexus

Nein, eigentlich nicht. Aber ich finde es besser, man behandelt den Fehler dort, wo er zu Stande kommt. Ansonsten kann es mühsam werden, ihn zu lokalisieren...

unskilled

Nexus schrieb:

Nein, eigentlich nicht. Aber ich finde es besser, man behandelt den Fehler dort, wo er zu Stande kommt. Ansonsten kann es mühsam werden, ihn zu lokalisieren...

Naja - da es aber nirgendwo passieren dürfte, würd ichs auch nirgendwo prüfen... Ist ja auch egal - ist sicherlich Geschmackssache, ob man nun Setter baut oder die Member öffentlich macht - oder man nur Getter hat (wie ich es ja machen würde)...

bb

Drehleiter

Bin grad dabei dies zu machen.
+=
*=
usw. mach ich dann auch noch

Hallo,
du solltest mal boost/operators.hpp anschauen. Der generiert dir automatisch aus z.B. aus dem +=operator den +operator durch ableiten.

Gruß