@zkubinski:
mam jedno pytanie - wyjaśnij mi proszę, bo nie rozumiem - klasa QString
ma przeładowany operator <<
i wygląda on tak QDataStream &operator<<(QDataStream &stream, const QString &string)
- dlaczego jak ten operator zwraca QDataStream
- to widzę normalny tekst ? Dodam, że klasa QDataStream
nie zwraca QStringa
Już Ci kq pisał — to działa tak, jak std::cout
i podobne. Czyli to nie QString
ma przeładowany ten operator, tylko QDataStream
ma przeładowany ten operator, wykonanie tej funkcji-operatora powoduje wypisanie na konsolę, a zwracany jest QDataStream
, żeby móc chainować — qInfo() << byte_array << data << byte_array_again << string_again;
. Po kolei wykonuje się to tak: najpierw qInfo() << byte_array
wypisuje byte_array
, po czym zwraca referencję do wyjściowego qInfo
(co jest w praktyce nierozróżnialne od jawnego wzięcia iInfo
od nowa), to nowe-stare qInfo
wywołuje <<
z data
, co wypisuje data
i zwraca kolejną referencję, ta znowu wykonuje swóją <<
z byte_array_again
, co zwraca czwartą referencję do pierwotnego qInfo
, i na końcu ta czwarta referencja do qInfo
działa z string_again
. Efektem jest jeszcze jedna referencja do qInfo
, ale to już nic nie robi, bo nikt od niej nic nie chce.
EDYCJA:
Poprawiłem terminologię zgodnie z uwagami _13th_Dragona.
EDYCJA 2:
A wyobraź sobie teraz, dla odmiany, co by było, gdybyś miał API, które by nie działało tak, jak to, tylko miałbyś funkcję drukującą, która nie zwraca referencji do obiektu drukującego, a właśnie stringa. To wywołujesz to raz… i masz stringa. Co z nim chcesz zrobić? Po co Ci dalej ten string? Nie możesz chainować, tylko musisz się za każdym razem odwoływać do „drukarki”, i ogólnie całość się szybko robi niewygodna.