C++ proudy - proč?

[Jiri K.]

Čauec,

 mám takový dotaz. Před pár lety v prváku jsme se učili C++. Do té doby jsem znal jen Céčko ze střední. První věc, co mi přišla divná, byly datové proudy <<, které jsme používali pro výpisy do konzole. Byl jsem zvyklý na printf(). Nějak jsem tehda nechápal, k čemu to je dobré a proč to dělat jinak, než přes printf. Spolužák mi říka "to je úplně dobré ty datové proudy, že?". Nevěděl jsem, jestli jsem tady blbej já nebo on (popravdě myslel jsem si že on). No a roky plynuly, já viděl v ukázkových příkladech jednou použití proudu, jedou zas klasickou verzi, navíc jsem si všiml určitého chaosu který panuje třeba v OpenCV, až do dnešního dne:

VideoCapture cap(......);
Mat frame;

cap.Grab(frame); // lze použít toto
frame << cap; // nebo tohle; je to stejné

 
OH MY GOD why?

Abych to vysvětlil, tak nejde tady jen o datový proudy, ale ukazuju to jako principiální případ pro celé spektrum dalších věcí, které se netýkají jen C++. Prostě čím dál víc nabývam dojmu, že se jedná o pokusy věci nějak zjednodušit, ale přitom se akorát víc zkomplikovaly. Opravdu je tak nutné, když se nám něco jeví jako proud dat (což je stejně dost subjektivní), přiřazovat tomu vlastní reprezentaci v prog. jazyce?

Tak snad teď mi to někdo vysvětlí, děkují :-)

[Reklama]

[Jakub Galgonek]

Přetěžování operátorů vás učili?

[Sten]

Ten důvod je jednoduchý: design by contract používaný u šablon. Pokud mám šablonu, která může přijmou libovolný proud, pak musí mít nějaký contract, kterým ten proud používá. V C++ se používají operátory << a >>, protože pevně dané jméno funkce může být zavádějící: např. v Javě se používá metoda close i pro objekty, kde se uvolnění zdrojů nedělá jejich zavřením, ale třeba odemčením či dealokací.

Jinak nejde o žádnou speciální konstrukci toho jazyku, proudy mají jen přetížený operátor << nebo >>.

[zboj]

Do jisté míry to je syntaktický cukr. Netýká se to ani tak jazyka samotného, ale knihovny. C++ umožňuje přetěžování operátorů a STL toho bohatě využívá. Není v tom tedy žádná magie a není to ani lepší nebo horší než volání funkce. C jen prostě nemá na výběr.

[mr x]

Myslim ze michas dohromady 2 veci ktery spolu uplne nesouvisi.

Jedna vec je abstrakce datovych proudu, to znamena nejake jednotne rohrani pro cteni/zapis na ruzna mista - standardni vystup, soubor, socket, ...

Druha vec je pretizeni operatoru pro bitovy posun (<<, >>).

Podle me hlavni duvod pro pouziti tehle operatoru je ten, ze stare verze c++ neumoznovali vytvorit typovane variadicke funkce. Troufnu si tvrdit ze kdyby c++ streamy vznikali dnes, tak misto:

std::cout << a << b << c;

by se psalo:

std::cout.print(a, b, c);

pripadne neco jako:

std::cout.printf("a = %, b = %, c = %", a, b, c);

V novych verzich c++ by nebyl problem vytvorit takovehle rozhrani s tim ze by se u vseho kontrolovali typy. V dobe kdy vznikly streamy to mozne nebylo.

Mimochodem, printf() ma zasadni problemy, kvuli kterym je lepsi tuhle funkci nepouzivat:

- ve formatovacim retezci musis zadat spravny typ, jinak program muze snadno spadnout. Pravda, nektere kompilatory zobrazi warning.

- musis ZNAT spravny typ - to muze byt problem napr. u sablon, ale ne jenom tam. Nekere typy se muzou lisit system od systemu. Vytiskne se spravne napr. promenna typu size_t, kdyz pouziju "%d"?

- neni rozsiritelna. Operator << muzu snadno pretizit a tisknout instance vlastni tridy stejne jako vsechno ostatni. S printf() tohle udelat nemuzu.

[Reklama]

[radík]

Nevim, kde vás výstup pomocí proudů učili, ale podle mě je povinnost vysvětlit, proč je používat, jak fungujou, včem je to jiné(lepší) oproti printf.

[_pepak]

Abych to vysvětlil, tak nejde tady jen o datový proudy, ale ukazuju to jako principiální případ pro celé spektrum dalších věcí, které se netýkají jen C++. Prostě čím dál víc nabývam dojmu, že se jedná o pokusy věci nějak zjednodušit, ale přitom se akorát víc zkomplikovaly.

1) Hodně věcí se dělá prostě proto, že to je módní záležitost nebo to prostě hezky vypadá.
2) Hodně věcí se dělá jinak než dříve proto, že se změnila kritéria, podle kterých se určovalo, co je výhodnější (například za posledních 30 let podstatně vzrostl význam udržovatelnosti kódu, zatímco hledisko výkonnosti už zdaleka nehraje takovou roli - tudíž má smysl změnit přístup, pokud to povede k lepší udržovatelnosti, i když za to třeba zaplatíš výkonem).
3) U hodně věcí se může zdát, že jenom přinášejí komplikace, ale pokud jim rozumíš hlouběji, ukáže se, že jsou přínosem.

Opravdu je tak nutné, když se nám něco jeví jako proud dat (což je stejně dost subjektivní), přiřazovat tomu vlastní reprezentaci v prog. jazyce?

Není to nutné, ale na druhou stranu, pokud tvoji zákazníci (když děláš knihovnu, tak programátoři) jsou zvyklí pracovat určitým způsobem, může mít ekonomický smysl jim ten jejich způsob umožnit. Zvlášť pokud tě to skoro nic nestojí, tak je určitě lepší podchytit obě skupiny než kvůli zanedbatelné úspoře jednu předat konkurenci.