Überladen der Operatoren funzt nicht...

unskilled schrieb:

struct complex
{
  double real;
  double imag;
};

#include <iostream>

std::istream& operator>> (std::istream& s, complex& value)
{
  s >> real >> imag;
  return s;
}

int main()
{
  complex c;
  std::cin >> c;
}

Mir schaudert es vor dem Compiler der das fehlerfrei Compiliert (Edit: hm! dafür gibt's ja 'nen Smilie!)

std::istream& operator>> (std::istream& s, complex& value)//Wofür hab'n wir bloß diesen Parameter value?
{
  return s >> value.real >> value.imag;//So is' schöner
}

unskilled

Hacker schrieb:

unskilled schrieb:

...

huch sry, natürlich vergessen

edit: ob man das return auf ne extra zeile schreibt oder nicht, ist wohl geschmackssache. ich mags auf der gleichen zeile nicht so sehr.

unskilled schrieb:

ob man das return auf ne extra zeile schreibt oder nicht, ist wohl geschmackssache. ich mags auf der gleichen zeile nicht so sehr.

std::istream& operator>> (std::istream& s, complex& value)
{
  return 
         s >> value.real >> value.imag;
}

:xmas1:

Edit: Wenn man noch auf die schlaue idee der Datenkapselung kommt, ist

friend

dein Freund oder nicht. Lieber setter Methoden, nich'?

unskilled

so ists natürlich keine geschmackssache mehr... boar.

pumuckl

Hacker schrieb:

ist
friend
dein Freund oder nicht.

Oder nicht. friend ist niemandes Freund, sondern ein potentiell echt fieser Eindringling
Aber auch das ist wieder Geschmackssache...

Tachyon

pumuckl schrieb:

Hacker schrieb:
ist
friend
dein Freund oder nicht.
Oder nicht. friend ist niemandes Freund, sondern ein potentiell echt fieser Eindringling
Aber auch das ist wieder Geschmackssache...

Hier braucht es weder Setter noch friend. Hier reicht ein quasi funktionaler Ansatz:

class complex
{
public:
    complex(double re = 0.0, double im = 0.0);
    //...
};

std::istream& operator>> (std::istream& s, complex& value)
{
    double re = 0;
    double im = 0;
    s >> re >> im;
    value = complex(re, im);
    return s;
};

Tachyon schrieb:

pumuckl schrieb:
Hacker schrieb:
ist
friend
dein Freund oder nicht.
Oder nicht. friend ist niemandes Freund, sondern ein potentiell echt fieser Eindringling
Aber auch das ist wieder Geschmackssache...
Hier braucht es weder Setter noch friend. Hier reicht ein quasi funktionaler Ansatz:
class complex
{
public:
    complex(double re = 0.0, double im = 0.0);
    //...
};

std::istream& operator>> (std::istream& s, complex& value)
{
    double re = 0;
    double im = 0;
    s >> re >> im;
    value = complex(re, im);
    return s;
};

Das ist indirekt ein setter, aber ein Schlechter. Stell dir vor, du resettest ausversehen noch andere Variablen(hier nicht, bei größeren Klassen aber muss was anderes her).

Tachyon

Hacker schrieb:

...

Ich zitiere hier mal Penny von BBT...
WAS?

Tachyon schrieb:

Hacker schrieb:

...

Ich zitiere hier mal Penny von BBT...
WAS?

Guck mal, du erstellst ein Objekt und weißt dann dem anderem dieses zu. Solange der keinen zuweisungsoperator mit rvalue-ref. hat, kann das bei größeren Klassen unnötig werden, du könntest auch noch andere Variablen ausversehen zurücksetzen. Was spricht denn gegen einen setter?

314159265358979

Also ich verstehe Hackers Post auch nicht.

Tachyon

Hacker schrieb:

Tachyon schrieb:

Hacker schrieb:

...

Ich zitiere hier mal Penny von BBT...
WAS?

Guck mal, du erstellst ein Objekt und weißt dann dem anderem dieses zu. Solange der keinen zuweisungsoperator mit rvalue-ref. hat, kann das bei größeren Klassen unnötig werden. Was spricht denn gegen einen setter?

Unötiges aufblähen des Interfaces? Guck Dir mal std::complex an...