czy można podaną funkcje przerobić aby nie było friend
friend ostream & operator << (ostream & s, const zesp & c)
{
s << "(" << c.real << "," << c.imag << ")";
return s;
}
C++ 
- Rejestracja:ponad 19 lat
- Ostatnio:2 miesiące
3
struct zesp { double real,imag; };
i już wystarczy nie musi być friend;
Lub:
class zesp
{
private:
double real,imag; // właściwie to dziwne dla tej klasy, te składowe nie trzeba hermetyzować.
...
ostream &out(ostream &s)const { return s<<'('<<real<<','<<imag<<')'; }
};
inline ostream &operator<<(ostream &s,const zesp &z) { return z.out(s); }
edytowany 2x, ostatnio: _13th_Dragon
- Rejestracja:ponad 21 lat
- Ostatnio:około 4 godziny
0
to jest całkowicie uzasadnione użycie friend, dlaczego chcesz kod komplikować dla głupiej zasady?
Nie jest uzasadnione użycie friend, ponieważ nie jest uzasadnione użycie private dla składowych.
też prawda.
- Rejestracja:prawie 15 lat
- Ostatnio:około 7 lat
0
friend ostream & operator << (ostream & s,const zesp & c)
{
s << "(" << c.real << "," << c.imag << ")";//odpowiada za wyswietlanie wynikow
return s;
}
W tym jest taki myk że :
s << "(" << c.real << "," << c.imag << ")";
jest odpowiedzialne za wyświetlanie wyników w main
i na struct nie działało :(
- Rejestracja:około 22 lata
- Ostatnio:ponad rok
0
Jeżeli nie masz getterów/setterów to powinieneś użyć friend. Jeżeli je masz to ich użyj.
Niektórzy będą się upierać, że nie ma po co robić tych getterów (tylko wsadzić to w public), niektórzy będą się upierać, że należy zawsze. A moim zdaniem to kwestia stylu, bo niczego innego to nie zmienia dla tak prostych przypadków. Zasadniczo największy sens one mają, kiedy należy w jakiś sposób kontrolować zapis czy odczyt. Ale można po prostu robić to zawsze dla zachowania spójności - taka funkcja inline i tak będzie działać tak, jakby jej nie było (w absolutnie każdym normalnym kompilatorze, poza kompilatorem @_13th_Dragon, ale on używa do tego celu worka ziemniaków i nie należy się jego opiniami przejmować ;-), tylko więcej pisania troszkę ale i teoretycznie więcej miejsca na błędy.
edytowany 6x, ostatnio: Endrju
"... taka funkcja inline i tak będzie działać tak, jakby jej nie było ..." - no jasne, tylko że kompilator może sobie to inline wsadzić ... i nie masz na to wpływu.
- Rejestracja:prawie 15 lat
- Ostatnio:około 7 lat
0
A czy można było by
friend ostream & operator << (ostream & s,const zesp & c)
{
s << "(" << c.real << "," << c.imag << ")";//odpowiada za wyswietlanie wynikow
return s;
}
przerobić na Void ?? albo jakoś inaczej , tak aby nie było Friend :)- zaprzyjaźniania klas :(
nie ma problemu możesz przerobić na void, ale
zest z; cout<<z; - zadziała, zaś zest z; cout<<z<<endl; - już nie.
- Rejestracja:około 17 lat
- Ostatnio:3 minuty
0
IMO operatory nigdy nie powinny skomplikowanego kodu, ale zawsze powinny mieć jedną klinikę z wywołaniem normalnej funkcji, która robi to co oczekujemy od operatora. W podanym przypadku powinno być tak:
class zesp {
...
ostream & wypiszDoStrumienia(ostream & s) {
s << "(" << real << "," << imag << ")";
return s;
}
};
ostream & operator << (ostream & s, const zesp & c) {
return c.wypiszDoStrumienia(s);
}
Zalet jest wiele. Nie trzeba bawić się w przyjaźnie, łatwiej utrzymywać kod z takim operatorem, a w przypadku bibliotek łatwiej poprawić te operatory nie psując binary/code compatibility.
edytowany 1x, ostatnio: MarekR22
Dokładnie to samo podałem w pierwszej odpowiedzi, 24 godziny temu ;> Z tym że u mnie bez błędu w postaci braku const.
W jaki sposób to ma pomóc w kompatybilności binarnej czy kodu? Dlaczego miałoby to być łatwiej utrzymać? Proszę, uzasadnij. Dla mnie to tak samo kwestia stylu jak gettery/settery - głównie więcej pisania - z tym, że jednej z tej funkcji prawdopodobnie nikt nie będzie używać.
przykład BigInt, najpierw definiujesz operator mnożenia/potęgowania naiwnie, ale potem dochodzisz do wniosku, że lepiej by operator zwracał obiekt proxy, który pozwoli na zastosowanie odpowiedniego algorytmu, gdy zostanie połączmy z operacją modulo. Jeśli operator zawierałby kod i nie byłby inline (operator byłby eksportowany przez bibliotekę) to nie masz pola manewru i możesz zapomnieć o obiekcie proxy.
Skoro zmieni się prototyp metody, która wykonuje to mnożenie (bo teraz zwraca proxy a nie BigInt) to zmieni się też prototyp operatora - gdzie tu kompatybilność binarna?
bo operator będzie dołączony do programu inline i będzie odnosił się do eksportowanej nazwanej funkcji, której nie dotknę. A jak zmienię operator to ta zmiana nie dotknie już zbudowanych programów, a nowo skompilowane będą automatem używać zoptymalizowanej wersji operatora. Proxy można napisać tak, że podmiana operatora będzie niewidoczna dla użytkownika biblioteki.
Natomiast, gdy operator jest elementem eksportowanym biblioteki, to pola manewru nie masz.
No jeżeli można tak napisać - to w porządku. Tu co podałeś to super-specyficzny przypadek, więc jeżeli taki masz - to ok. W całej reszcie takie podejście nic nie wnosi. Moim zdaniem należy tego używać (jak wszystkiego! ;-), kiedy jest uzasadniona potrzeba - właśnie taka, jaką opisałeś. Ale to tylko jeden na tysiąc przypadków.
std::ostream& zesp::out(std::ostream&) const’ is private