Dovolte abych Vám vyvrátil nesmysly, které jste napsal... I když uznávám, že vycházejí ze zavedené praxe.
Jenze v objektovych jazycich je jednak tezsi refaktorizace (jakmile se vam vsude vecpe jisty objektovy model, tezko se prechazi na jiny)
Právě že objektový model je jen jeden a to ten nejzákladnější. Kdyby každý tvůrce kdejaké knihovny dodržoval to nejzákladnější, totiž aby samy objekty (třídy) vystupovali jako samostatné entity, v podstatě vám eliminuje Vámi uváděné problémy. Tohle vyplývá z toho, že valná většina programátorů neumí objekty používat, natož vytvářet.
kdyz uz se rozhodnete pouzivat nejakou knihovnu, je temer nutnost prebrat i jeji model hlaseni chyb, alokace/dealokace objektu
Tohle není problém C++, ale obecně všeho v C. Podívejte se ale třeba na Javu, ta má modely alokace, a hlášení chyb jednotné a dané jazykovou normou. Ale i v C++ máme tuhle možnost. Na svůj blog třeba teď dlouhou dobu chystám článek o strukturovaném výjimkové systému, mnohem lépe navrženém, než je std::exception. Jak už jsem psal, problém je právě v těch knihovnách... nejsou... Kdyby byly, všichni by je používali a uvedené problémy by se redukovali.
Co se alokačního modelu týče, tak C++ striktně nařizuje používat new a delete. Navíc by každý objekt měl být alokovatelný i automaticky (staticky). Že si různí programátoři dobrovolně tuhle možnost omezují, to už je jiná věc. Pokud už technické, či jiné důvody toto znemožňují (továrny na objekty), přesto není problém zařídit, aby uživatel objektů nemusel přejímat alokační model. Objekty zaalokuje knihovna, o uvolnění se postará virtuální destruktor.
. Temer nejde "pouzit jen cast z knihovny". Toto vnimam jako podstatny rozdil proceduralniho programovani (klidne i s objektovymi rysy) a striktne objektove orientovaneho programovani.
Opět je to to co jsem kritizoval. V současné době BOOSTu, QT, MFC, ALT a jiných projektů opravdu nejde používat jen části knihoven, vina ale neleží na C++ ani na objektech, ale na tvůrcích. Z různých důvodů prostě tvůrci potřebují, aby jejich knihovna vystupovala jako černá skříňka. Může to být neschopnost, ale i marketingový tah. Tohle ale pokud vím je i problém C obecně, neomezuje se jen na C++. Já sám se snažím objekty navrhovat buď jako samostatně fungující objekty, nebo se stromovou závislostí.
Takze se dela to, ze si reknete "tak treba tohle bude trida/objekt, a radeji k nemu napiseme vsechny metody, ktere by nekdo mohl potrebovat. Nakonec to ale dopadne tak, ze z te tridy se ve velke vetsine pripadu pouzije akorat jeden konkretni konstruktor, jedna nebo dve metody volane presne tim stejnym zpusobem ze vsech mist kodu, a pak destruktor.
V tom bych ale neviděl problém, mnohem větším problémem je, že do tříd se časem dopisují metody, které tam nepatří. Programátoři si objekt pletou s knihovnou. Neumí si představit jednoduché relační vztahy. Napíšou objekt obsahující 10 kontejnerů a pro každý kontejner mají samostatnou sadu funkcí na rozhraníl. A neuvědomují si, že správnější přístup je mít metody spřístupňující kontejnery se stejným rozhraním. Objekty nejsou knihovny. objekty jsou malé částice programu, atomy. Mají základní rozhraní: vznikni, zanikni, udelej kopii, zjisti stav, nastav stav, případně něco spočítej. Cokoliv většiho už není objekt, ale bastl.
sou daleko mene portabilni.
Tohle považuji za JPP (Jedna paní povídala). Sám vyvíjím současně na dvou platformách ... Linux a Windows a s portabilitou nejsou problémy. Určité odchylky lze najít až na úrovni šablon, občas některý překladač něco pochopí jinak, ale garantuji vám, že se jedná o extrabuřty, špeky a vychytávky. Furt je situace lepší, než třeba na poli kompatibility mezi www prohlížeči. Pokud mluvíme o OS platformách, tak to je jiná záležitost, tady si musí udělat jasno linuxáři. Windows je na tom s kompatibilitou o 100% lépe.
ale podle me je toto temer nevyhnutelny dusledek toho, ze ten program je v C++.
Nesuďte podle linuxu, navíc zaměňujete jazyk a OS platformu. Navíc popisované problémy bývají hlavně na úrovni C. Samotné C++ vč. STL mi přijde celkem dobře kompatibilní. Programy napsané v GCC 3.3 jdou dobře přeložit i v poslední verzi GCC, pokud to jsou programy komplet v C++ a nepoužívají třeba unistd. a další hlavičkové soubory.
Názor k článku
Štěpán Škrob: Horkým kandidátem byl WebKit, ale vybrali jsme Gecko
