Administrace komentářů

formát: nu, já třeba v matematických aplikacích to řeším - často pro různé kontroly chci zběžně zkouknout hodně čísel na pár desetinných míst.

reprezentace: pokud mám výstup z objektu řešený pomocí metody toString(), není problém tuto metodu rozšířit o další parametr s implicitní hodnotou popisující styl výstupu. Rozdíl oproti přepnutí formátu výstupu je ten, že přepnutí formátu je globální změna, ovlivňující další chování programu, což je věc veskrze zavrženíhodná. Takové věci pak aby prase ladilo.

řízení z vnějšku: Např. objekt má svůj krátký a dlouhý název. Který z názvů chci vysypat pak samozřejmě neví ten objekt, ale jeho klient (např. u seznamu objektů stejného typu ho chci bez typu, u různých objektů s typem apod. Ve výsledku to vede k tomu, že rezignuji na operátor << objektu a do coutu stejně posílám jen stringy.

printf: ano, s tím souhlasím, očíslování argumentů schází. Pořád to je ale věc, kterou lze v procedurálním stylu dopsat. V streamovém stylu to prostě nenapíšu, nejsou na to vhodný výrazový prostředky. Ve výsledku to povede k tomu, že jeden objekt bude mít jak metodu toString (abych ho moh implementovat do šablon) tak i operátor <<, což je zjevná duplicita.

nelineárně: no do coutu těžko pošleš nejdřív konec výstupu a pak začátek, stejně tak do stringstreamu. U skládání stringů snadno string předřadíš před zbytek (a máš-li inteligentní řetězce, tak i levně). Takže opět člověk skončí u toho, že si nejprve poskládá celej výstup (řádku) a tu pak vyplivne najednou.

Operátor << se IMHO hodí na rychlé vypsání věcí, u kterých tak nezáleží na kvalitě prezentace: prostě chci něco vysypat, napsat to co nejrychlejc, a nezáleží mi na tom, jak to bude vypadat. Pokud ale chci složitější věci, tak je najednou spousta věcí přes ruku....