ostream & print()

Mógłby mi ktoś zaprezentować przykładową implementację takiej funkcji: ostream & print();
Zwracana jest referencja do strumienia na ekran, jak to zaimplementować ?, co wpisać obok return ?

A to nie miała czasem być funkcja

ostream& print(ostream& strumien)
{
strumien<< this->jakieśtamskładowe;
return strumien;
}

Albo w ogóle co ładniej wygląda, bo wystarczy ci pisać np.
Klasa obiekt;
cout<< obiekt;

friend ostream& operator<<(ostream & strumien, Klasa& zmienna)
{
strumien<<zmienna.skladowe;
return strumien;
}

Shalom, to się robi zwykle w ten sposób:

struct foo
{
  ostream& print(ostream& os) const
  {
    os << cośtam;
    return os;
  }
  //bla bla bla
};
ostream& operator<<(ostream& os, const foo& obj)
{
  return obj.print(os);
}

manfred, chyba jednak łatwiej i krócej jest:

struct foo {
 //...

 friend ostream& operator << ( ostream&, const foo& );
}

ostream& operator<<(ostream& os, const foo& obj)
{
  os << obj.elem_skladowy;
 //...
 return os;
}

I brzydziej, należy unikać friendów tam, gdzie się da.

a to niby czemu?? mamy sobie utrudniać bez powodu życie??

I brzydziej, należy unikać friendów tam, gdzie się da.

E, no właśnie, dlaczego? Zwłaszcza czy przeładowywaniu operatorów to bez sensu! W ogólnym przypadku musiałbyś udostępniać publiczną metodę pośrednią:

class A {
   /*...*/
   public:
   void print_me(ostream& out);
};
void operator<<(ostream& out, A&& value) { return value.print_me(out); }

bezsensowne :|

Ja tam nie wiem, sugeruję się Herbem Sutterem... http://www.gotw.ca/gotw/004.htm ma krótko napisane, że operator<< nie powinien być friendem... Hm, można wiedzieć, cóż to za radosny język ma referencje do referencji (rval-ref z C++0x nie liczę. ten język póki co nie istnieje)?

http://en.wikipedia.org/wiki/C%2B%2B0x#Rvalue_reference_and_move_semantics

Ranides napisał(a)

I brzydziej, należy unikać friendów tam, gdzie się da.

E, no właśnie, dlaczego? Zwłaszcza czy przeładowywaniu operatorów to bez sensu! W ogólnym przypadku musiałbyś udostępniać publiczną metodę pośrednią:

class A {
   /*...*/
   public:
   void print_me(ostream& out);
};
void operator<<(ostream& out, A&& value) { return value.print_me(out); }

bezsensowne :|

niby tak, ale nie jednak nie..
generalnie, rowniez moim zdaniem, tak wlasnie powinno byc! przeciazanie operatorow jako jedynie smaczek syntaktyczny, wszystkie operacje powinny byc dostepne takze w normalny sposob, pozostawiajac wybor pomiedzy pisaniem uber-zwięzłym a rozwleklym dla mniej-oblatanych

zreszta, czemu operator wsuwu do strumienia mialby korzystac z wewnetrznych bebechow klasy? w czym ma on wiecej praw od zwyklego klienta klasy, ktory np. chcialby ja recznie zserializowac do pliku tekstowego? IMHO, operator<< jest tylko klientem..

jak zwykle w takich przypadkach lubię patrzeć na bibliotekę std. Nigdzie nie znalazłem metod publicznych:

string::put_to_stream(ostream&)
string::get_from_stream(istream&)

a operatory << oraz >> i owszem, są. I to friendowe.

Zależy od punktu widzenia. Dla mnie operator xxx, to metoda obiektu, tylko woła się ją inaczej. Operatory w ogóle powinny być składowymi, ale z powodów tylko składniowych << >> być nie mogą (ostream,istream po lewej stronie mile widziany).

Oczywiście, to takie jakieś se dyskusje w stylu bożego narodzenia.

Ale po prostu nie lubię, kiedy się odradza jakąś technikę tylko dlatego, że jest z jakimś tam paradygmatem, albo widzi-mi-się autora niezgodna. Zwłaszcza, gdy odrzucenie techniki powoduje rozrost kodu źródłowego, narzut run-time (kolejny call), a w zamian nie daje żadnego wzrostu wydajności, bezpieczeństwa czy czegokolwiek innego oprócz tego, że teraz jest zgodna z czyjąś wizją ideologiczną.

true, true..