Vlákno názorů k článku
Štěpán Škrob: Horkým kandidátem byl WebKit, ale vybrali jsme Gecko

c++ kod je viac maintainable a je aj o nejake percento rychlejsi ak vies c++.

????
Možná, ka nevies C. Ale vzhledem k tomu, že v C lze napsat totéž co v C++ (až na to,že někdy napíšeš víc řádků kódu) - první kompilátory C++ fungovaly jako překladač z C++ do C - tak neni důvod, proč by kód v C měl bejt pomalejší.
Pravda je jen to maintable - v c++ se prostě líp píše, líp se hledaj chyby atd...

K teto diskusi jsem si vzpomnel na zajimavy clanek, kde je presne opacny nazor, fakt stoji za to ho precist:

http://lwn.net/Articles/249460/

Ja bych taky C++ zahodil a psal v C. Podle me se naopak v C++ pise daleko hur a hur se hledaji chyby, protoze C++ nuti cloveka delat taaaakhle tluste mezivrstvy, a kdyz si spatne rozvrhnete tridy, tak jste pozdeji ztraceni. V C je daleko jednodussi refaktorizace, a kdyz neignorujete warningy, tak uroven odhaleni chyb uz v compile-time je docela dobra.


-Yenya, http://www.fi.muni.cz/~kas/blog/

C++ může za špatné počasí a napůl nefunkční KDE :-) Jaké tlusté mezivrstvy máte na mysli? Třeba tlustá vrsta výjimek nebo špatně rozvrhnout třídy může být v C dost problém :-), ale vážně - jaké mezivrstvy je nutné vytvářet a v čem je v C snadnější refaktorizovat? Záleží na stylu než na použitém jazyce.

Na druhou stranu, C++ knihovna bez správných úprav asi moc přenositelná nebude - např. na jinou verzi překladače, STL... Ale zatracovat kvůli tomu C++ úplně a za všech situací...

K tomu co napsal Linus (pro mnohé ekvivalent toho, jako by to napsal sám Bůh, ale věřím, že to nebude případ zdejších čtenářů) - v podstatě to, že když někdo moc chce, aby byl projekt v C++ místo v C, asi by ten někdo neměl být k projektu vůbec pouštěn. Hm, Linus si tohle myslí o C++, já si tohle myslím o PHP :-) Možná že já neprogramuji kernel a Linus neprogramuje webové aplikace. K té části o gitu - existují i VCS implementované v Pythonu. Jazyk C++ nevylučuje páchání chyb, asi jako žádný jiný.

Mimochodem, k rychlosti C++ - C++ asi bude o něco pomalejší, než C, ale ne výrazně. Záleží na tom, jakým stylem je projekt naprogramován - pokud se přeužívá STL, pak na vyšší rychlost mají šanci i interpretované jazyky :-)

Záleží na stylu než na použitém jazyce

Přesně. C++ je hlavně objektový a generický jazyk, C je imperativní a markoidní. Pokud chcete v C++ programovat imperativně a makroidně (jako by to dělal Linus), tak jste se spletl s výběrem jazyka.

na druhou stranu, c++ knihovna bez správných úprav asi moc přenositelná nebude - např. na jinou verzi překladače, stl... ale zatracovat kvůli tomu úplně a za všech situací...

Přenositelná je celkem v pohodě, dneska už všechny hlavní překladače standard dodržují. Problém může nastat, pokud se používají různá nestandardní rozšíření, ale jinak se dá přecházet tak stejně jako v C.

C++ asi bude o něco pomalejší, než C, ale ne výrazně

Dobře napsané C++ je stejně rychlé jako dobře napsané C :)

pokud se přeužívá STL, pak na vyšší rychlost mají šanci i interpretované jazyky

Zrovna STL je extrémně rychlé, právě protože to jsou všechno šablony, které se inlineují a výborně optimalizují při překladu. Samozřejmě ale jen v případě, že zapnete optimalizace.

Tluste mezivrstvy: je toho vic, ale napriklad: pokud neco delate objektove, pak k vetsine "verejnych" atributu objektu pisete accessor a mutator funkci, ruzne konstruktory, operatory pretypovani a prirazeni a podobne, aby to "vypadalo kompletne", a v tom vsem kodu je jen hodne malo radku toho, co skutecne dela neco netrivialniho. Java je na tom jeste hur, tam se ktem vsem generovanym acessorum a mutatorum pridavaji ty javadoc komentare, takze zdrojak pak nejen ze nejde v normalnim textovem editoru napsat, ale on nejde ani normalnim lidskym okem precist, protoze tech mist kde se "skutecne neco deje" je fakt malo. Tohle je proste fakt, ze objektove jazyky v podstate nuti cloveka psat tak, ze se vsechno obaluje do mezivrstev.

Jinak Linus tam uvadel i racionalni duvody proc ne C++ (treba tu refaktorizaci).

-Yenya

Tluste mezivrstvy: je toho vic, ale napriklad: pokud neco delate objektove, pak k vetsine "verejnych" atributu objektu pisete accessor a mutator funkci, ruzne konstruktory, operatory pretypovani a prirazeni a podobne, aby to "vypadalo kompletne", a v tom vsem kodu je jen hodne malo radku toho, co skutecne dela neco netrivialniho.

Ale tohle je základ C++. Mimochodem Linus je jeden z těch, kteří prosazují, že jedna procedura (metoda) smí být dlouhá maximálně 25 řádků, takže většinou nemůže dělat něco hodně netriviálního (teda pokud se nevyužije macro hell).

A taky bych dodal, že pokud nepatláte objekty stylem Copy&Paste, jako dělá většina začínajících programátorů C++ (jo, dělal jsem to taky), ale member objekty obalíte do vhodných šablon, případně z nich uděláte objekty, které se starají o svůj obsah nebo je rovnou uvedete jako public, tak žádné accessory a mutátory psát nemusíte a kód je tak daleko přehlednější.

25 radku kodu ktery neco dela je ovsem neco jineho nez accessor/mutator, ktery vypada nejak takhle:

/**
* get_atribut(void)
*
* ziska hodnotu atributu
*/
int get_atribut(void)
{
return this->atribut;
}

Coz je 9 radku kodu ktery nedela vubec nic. Navic kdyz si prectete linux/Documentation/CodingStyle, tak tam neni striktni omezeni na 25 radku, ale spis neco o tom, ze cim hloubeji zanorene struktury ta funkce ma, tim by mela byt kratsi. A ze neni nic spatne na funkci obsahujici jediny prikaz switch, ktery se kvuli mnozstvi variant tahne pres nekolik obrazovek.

-Yenya

Takle píšu accessor já.

///Retrieve attribute size
int getSize() const {return size;}
///Retrieve attribute height
int getHeight() const {return height;}
///Retrieve attribute name
std::string getName() const {return name;}

Není to sice podle všech doporučení, ale vypadá to celkem přehledně, člověk hned vidí o co jde. (doxygen to sežere) Navíc, když to člověk v deklaraci hodí někam k sobě (accessory a mutatory zvlášť), pak i zdroják vypádá přehledně... Výhoda accessorů je v tom, že pokud se práce s atributem v budoucnu změní, není třeba měnit rozhraní.

Už jsem se takovým případem setkal. Několikrát by změna rozhraní znamenala obrovské náklady a čas.

psát dokumentaci je špatné, áno?

...tak nějak jste to s tou javou myslel? ;)

naopak tohle by se dalo chápat jako výhoda javy, že standardizuje dokumentovaní přímo v kódu, což je potom ve spolupráci s patřičným ide příjemné, pokud na projektu pracuje víc jak jeden člověk (a mnohdy je za předchozí dokumentaci rád i když píše něco sám).

btw, z čeho vycházíte, že se nedá javovský kód psát v obyčejném textovém editoru? já to už párkrát dělal a musím říct, že mi to docela šlo (i když je to pruda).

co se týče čitelnosti, to je asi věc zvyku, protože pro mě je javovský kód čitelný nádherně, za to špagety ála php nebo asp mi dělají problémy a nad nějakým masitějším kódem v perlu či dokonce lispu musím sedět trošku dýl abych vůbec tušil odkud vítr vane...

Kdyz to reknu velmi volne, tak ano, psat dokumentaci je _casto_ spatne. Zvlast _povinna_ dokumentace a zvlast k trivialitam. Treba v jiz zminenem linux/Documentation/CodingStyle se pise:

Comments are good, but there is also a danger of over-commenting. NEVER try to explain HOW your code works in a comment: it's much better to write the code so that the _working_ is obvious, and it's a waste of time to explain badly written code.

Generally, you want your comments to tell WHAT your code does, not HOW.

[vyraz "neda se psat v obycejnem textovem editoru" u me znamena presne to vase "je to pruda"; PostScriptovy soubor lze taky napsat v obycejnem textovem editoru, ale temer nikdy to nema vyznam]

-Yenya

přiznám se, že s odkazovaného textu jsem nepochopil, proč by mělo být psaní dokumentace "_často_ špatné". to že někdo píše dokumentaci špatně je chyba dotyčného programátora-prasete, za což by měl dostat přes prsty a ne chyba dokumentace jako takové.

pořádná dokumentace (alespoň veřejného api) prostě musí být a musí obsahovat popis toho, co daná metoda (funce, procedura, whatever) bere, co a za jakých podmínek vrací, jaké výjimky a za jakých podmínek můžou nastat atp. myšlenka, že nejlpší dokumentací je přehledně napsaný kód a jako takový nepotřebuje dokumentovat, protože "to je z něj jasné" je naprostý nesmysl. a to i v případě "trivialit" (teď ovšem nemyslím nějaké gettery-settery). jako vývojář chci nějaké api používat a pokud možno okamžitě vědět co dělá. ne se vrtat v cizím kódu a zjišťovat k čemu to vlastně je.

ad textové editory - ano v obyčejném textovém editoru to je nepohodlné, ale jde to. ale takhle je to s většinou jazyků. když se objevilo barvení syntaxe, tak se nikomu nechtělo psát "černobíle", když si někdo zvykne na automatické doplňování/šablony/generování kódu/kontrolu syntaxe/automatizovaný refactoring/hypertextové procházení kódu atd atd tak je samozřejmě psaní v obyčejném textovém editoru otrava. ale stejně jako když přesednete z bmw do trabantu, na dané místo taky nejspíš dojedete, ale o potěšení nebo pohodlí řeč být moc nemůže.

pořádná dokumentace (alespoň veřejného api) prostě musí být

Jenze v C++ je problem, ze tou objektovosti je toho verejneho API (funkci/metod/cehokoli co je verejne pristupne k volani odjinud) je nekolikanasobne vic. A je ho vic o triviality, ne o realnou funkcnost. Podle me z nazvu funkce by uz melo byt jasne co funkce dela. Dokumentace "API" je potreba jen v pripade, ze _nad to_ ta funkce ma nejake speciality (mozna ty vyjimky, ja bych treba rekl pozadavky na externi zamykani, atd.).

K velikosti "API" v C++ jeste prispiva to, ze pokud chcete mit neco naprogramovane "ciste" (pekne), tak je neco jineho aby "objekt mel ciste (zejmena ortogonalne) navrzene rozhrani" a je neco jineho, co realne potrebuje uzivatel toho objektu. Coz je to co jsem psal driv - ze proste v C++ k te tride dopisete "kompletni" rozhrani (pekne ciste navrzene, o tom zadna), akorat je ho mnohokrat vic a casto ne presne takove, jako potrebuji uzivatele toho objektu.

-Yenya

K velikosti "API" v C++ jeste prispiva to, ze pokud chcete mit neco naprogramovane "ciste" (pekne), tak je neco jineho aby "objekt mel ciste (zejmena ortogonalne) navrzene rozhrani" a je neco jineho, co realne potrebuje uzivatel toho objektu. Coz je to co jsem psal driv - ze proste v C++ k te tride dopisete "kompletni" rozhrani (pekne ciste navrzene, o tom zadna), akorat je ho mnohokrat vic a casto ne presne takove, jako potrebuji uzivatele toho objektu.

A teď mi řekněte, jaký je rozdíl v tom, že v C i C++ napíšete objektu do knihovny jen základní funkčnost a zbytek necháte implementovat programátora v C novými funkcemi, v C++ dědičností?

V zásadě komentuji algoritmy, pokud vlastní zdrojový kód je těžší analyzovat. Osvědčilo se mi prokládané komentování, tedy jeden komentář, a jeden řádek kódu

   //tak nyni si vyzvedni iterator vsech vertexu
VertexSet::iterator iter = vxset->getIterator();
   //zpracuj vsechny vertexy
while (iter.hasItems()) {
      //vyzvedni vertex
   PVertex vx = iter.getNext();
       //a neco s nim udelej
   foo(vx);
}

Ukázka je samozřejmě primitivní. Používám spíš u náročnějších úkolů, třeba různé ne zrovna na první pohled viditelné optimalizace. Další důvod pro komentáře u vícevláknových algoritmech, kde komentář zpravidla obsahuje očekávaný stav dalších vláken v tom daném míste (případně upozornění na problémové místo, možný race condition a podobně) Komentování algoritmu zjednodušuje pochopení principu fungovaní později a hlavně odhalování chyb. Komentáře jsou často v implementační části, takže (aspoň v C++) skryté běžnému uživateli.

Java je na tom jeste hur, tam se ktem vsem generovanym acessorum a mutatorum pridavaji ty javadoc komentare, takze zdrojak pak nejen ze nejde v normalnim textovem editoru napsat, ale on nejde ani normalnim lidskym okem precist, protoze tech mist kde se "skutecne neco deje" je fakt malo.

Tak tohle jsem nepochopil. Tam ty javadoc komentare snad psat nemusite, ne? A kdyz mate IDE, tak jsou dost uzitecne, ne? Takze nechapu...

Nemusite, ale vsichni to pisou. Cili kod v Jave je bez IDE necitelny, protoze tezko hledate, kde v tom vsem je skryta ta cast, ktera opravdu neco dela.

-Yenya

No vidíte a mě Javadoc (resp. Doxygen) u prototypu funkce v hlavičkovém souboru vyhovuje daleko víc, než procházet tisíce řádků zdrojového kódu (který v mnoha případech ani nechci stahovat - proč taky, když to kompilátor slinkuje s hotovým sočkem?) a hledat, co ta která funkce vlastně dělá. A to píšu v Kate a žádné IDE nepoužívám.

Kdo dnes tvrdí, že v C++ se píše mnohem hůř než v C, ať zůstává u C, C++ prostě zatím nepochopil. A nebo ať se C++ začne pořádně věnovat, něco si o tom přečte a zkusí programovat podle všech doporučení C++ programátora. Třeba chytí slinu.

Já bych třeba v C dneska neprogramoval. Přitom jsem v C napsal celou hru (kdysi legendární český dungeon "Brány Skeldalu"). Ale když se dnes kouknu na zdrojáky a vidím tam ty křeče snažící se nahradit v C neexistující objektu, musím se smát. Dnes programuju v C++. Kód, který píšu je výhradně objektový. Mnohem víc používám generika a snažím se do kódu dodad mnoho abstrakce. Člověk se musí naučit myslet komponentně. Stejně tak jako velké systémy se skládají z mnoha komponent, i na úrovni zdrojáků máme komponenty, komponetíky a mikrokomponenty. Vše jsou to objekty, které spolu spolupracují, navzájem se oslovují, komunikují, posílají si zprávy (opět objekty) a starají se o svůj životní prostor. Vznikaji a zanikají, transformují se, žijí a dýchají. Každý má přitom své hřiště, sám si definuje protokol, jak komunikuje s ostatními. Všechno tohle funguje, aniž by řešilo chyby a výjimečné situace. Od toho jsou výjimky. Pokud komponenta (objekt) selže, vyhodí výjimku a o řešení chyby se postará nadřízený. Máte to jako v dobře fungující firmě, kde se problém, který nelze řešit na úrovni podřízených vyhazuje do vyšších pater. Občas se stává, že výjimka byla záměrná, jako když vám nadřízený dá úkol něco provést, vy mu ohlásíte, že jste selhal a on vám za to zvedne prémie (protože nadřízený potřeboval zjistit, že to nejde).

Tyhle všechny možnosti a výhody jsou podmíněny dobrým knihovním zázemím. Právě v tom je C++ nejslabší. STL bohužel (přes svojí rychlost) zdaleka nenabízí to co by člověk potřeboval. Naproti tomu Boost například je obrovský moloch, stejně tak jako QT a jiné systémy, snažící se tohle řešit. Java je v tomhle 100x lepší, stejně jako C# (zazlívám microsoftu, že místo aby podporoval C++, vymýšlí kraviny v podobě .NET frameworku a pak nám to cpe přes svůj marketing a kdejakého začátečníka tím zblbne).

V tomhle směru se i já snažím situaci zlepšit aspoň tím, že kolektuji po různu sesbírané objekty z různých projektů do knihovny "LightSpeed". Ani já však nemám patent na rozum. Vice na mém webu

http://bredy.novacisko.cz
http://bredy.novacisko.cz/?g=main&kat=17 (sekce C++)

Zkusim odpovedet na trochu vyssi urovni abstrakce:

Podle me slabost C++ v oblasti knihoven (kterou sam pripoustite) neni pricina toho, ze se v C++ mnohdy spatne pise, naopak je to dusledkem toho, ze C++ je striktne objektovy jazyk[*]. Vec se ma tak: navrhnout knihovnu (zejmena jeji rozhrani) je tezke (ve vsech jazycich). Jenze v objektovych jazycich je jednak tezsi refaktorizace (jakmile se vam vsude vecpe jisty objektovy model, tezko se prechazi na jiny), a jednak jeste navic je zde vetsi pervasivnost (jak se to rekne cesky - vlezlost?) knihoven - kdyz uz se rozhodnete pouzivat nejakou knihovnu, je temer nutnost prebrat i jeji model hlaseni chyb, alokace/dealokace objektu, atd. Coz obvykle znamena, ze na knihovne (i spatne navrzene, coz se holt stava ve vsech jazycich) je vas projekt daleko vice zavisly. Temer nejde "pouzit jen cast z knihovny". Toto vnimam jako podstatny rozdil proceduralniho programovani (klidne i s objektovymi rysy) a striktne objektove orientovaneho programovani.

Dale: zapouzdrenim do objektu v podstate delate i lokalni "knihovny" uvnitr sveho projektu. Opet - navrhnout spravne rozhrani je tezke, ne-li dopredu nemozne. 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 proceduralnim jazyce (nejlepe s nejakou agilni metodou programovani), byste tento kod psal az tehdy, az ho skutecne nejaka dalsi vrstva bude potrebovat.

Dalsi vec je (coz ale souvisi s fungovanim knihoven v OO jazycich), ze OO jazyky (a C++ zvlast) jsou daleko mene portabilni. Treba tady http://www.fi.muni.cz/~kas/blog/index.cgi/computers/cplusplus-woes.html pisu o tom, jak je tezke vzit i jen par mesicu stary program v C++ a zkompilovat ho ani ne na jine platforme, ale na novejsim systemu s novejsi verzi libstdc++ a hlavickovych souboru. Muzete namitnout "zbastleny program", ale podle me je toto temer nevyhnutelny dusledek toho, ze ten program je v C++.

-Yenya

[*] Coz je do jiste miry eufemismus - striktne objektovy jazyk je treba ObjectiveC, ne C++.

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.

V současné době BOOSTu, QT, MFC, ALT a jiných projektů opravdu nejde používat jen části knihoven,

U Boost i Qt lze používat jen část knihovny. Boost je na tom dokonce založen (je to kolekce knihoven, ne jedna knihovna) a Qt s tím dělením přišel poté, co přestal být jen GUI framework.

"In other words, the only way to do good, efficient, and system-level and
portable C++ ends up to limit yourself to all the things that are
basically available in C."

system-level

Důležité slovíčko, které jste zřejmě přehlédl :)

Podle me slabost C++ v oblasti knihoven (kterou sam pripoustite) neni pricina toho, ze se v C++ mnohdy spatne pise, naopak je to dusledkem toho, ze C++ je striktne objektovy jazyk[*].

C++ není striktně obejktový jazyk a ani nechce být. C++ je multiparadigmický jazyk, převážně objektový a generický. Striktně objektový z něj dělají neznalí programátoři. Mimochodem generický (šablonový) program se daleko daleko jednodušeji refaktoruje než procedurální, daleko snáz se tam dělají unit testy (test driven development) a daleko méně duplicitního kódu je třeba napsat. To, že většina programátorů v C++ zná šablony jen jako STL, není chyba jazyka, ale příslušných programátorů.

V proceduralnim jazyce (nejlepe s nejakou agilni metodou programovani), byste tento kod psal az tehdy, az ho skutecne nejaka dalsi vrstva bude potrebovat.

Tohle zní skoro jako kdyby v objektovém jazyce nešlo programovat agilně a metody nešly přidělávat do objektů teprve ve chvíli, kdy je někdo opravdu potřebuje. To doufám nemyslíte vážně.

Treba tady http://www.fi.muni.cz/~kas/blog/index.cgi/computers/cplusplus-woes.html pisu o tom, jak je tezke vzit i jen par mesicu stary program

Ten program nebyl C++, ale bastl. memcpy není C++ konstrukce, C++ má std::copy, případně kopírovací konstruktor std::string. INT_MAX není C++ makro, C++ má std::numeric_limits<int>::max. A ano, ten program byl neuvěřitelně zbastlený, když předpokládal, že jeden hlavičkový soubor includuje jiné, což nezaručuje ani vámi vychvalované C (mimochodem všechny funkce, které vám nefungovaly, byly Céčkové, nic o problémech s STL tam není). Takže pokud chcete něco kritizovat, tak toho, kdo v C++ používá takové funkce a makra, která do C++ neptaří.

proto se vraceji zpet k C bez rozsireni To je nějaký výzkum? Otazkou je, jak bylo puvodne C++ zamysleno, protoze jsem v nem nikdy nevidel tak cisty program, jako v cistem C. Myslím, že po tomhle prohlášení není třeba v diskuzi pokračovat.

Jestli jste se nikdy nenaučil programovat objektově, tak zkuste hledat vinu jinde než v objektových jazycích. Mimochodem opravdoví programátoři písou programy v catu a Céčkařům se smějí :)

Linus není žádný bůh. Nezapomeň, že to je systémář a pohybuje se někde na úrovni assembleru. Jeho postoj chápu. Člověk, který napsal operační systém zřejmě bude nějak profesně deformovaný. Zároveň si ale nemyslím, že by jeho názor musel být rozhodujícím. Už kvůli tomu, že trend spíš jde ve směru objektového programování. Musíme si uvědomit, že OOP je relativně nová věc, praktické nasazení OOP je záležitost posledních 10 let, tedy lidi, co programovali před rokem 2000 výborně v C už nikdy pravděpodobně nepříjdou na chuť objektům.

Jinak OS se dá napsat i v objektovém programovacím jazyce... Už kvůli tomu, že ty výkonné systémové části se dají skrýt do objektů, postup při analýze je stejný, jako při návrhu objektů v jiných oborech (ať již jde o databáze, nebo řízení zalejvání kytiček).

C++ není nic jiného, než vylepšený C, kde spoustu věci za tebe udělá překladač sám, právě takové ty věci, které v C úděsně zdržují, komplikovaně řeší, nebo způsobují problémy s údržbou a chybovosti. Například díky používání std::string namísto const char * se Seznamu víceméně vyhnul problem s Buffer Overrun. Ten prostě v C++ nastat nemůže.

str_append(), ktery pracuje se strukturou tak, jako to provadi STL

Tak mi řekněte, jaký je rozdíl mezi vaší strukturou a objektem. Kromě jiného zápisu (a.append(...) vs str_append(a,...)) fakt, že se musíte postarat o inicializaci a deinicializaci struktury. C++ zařídí samo. Jak budete řešit wstring::append() a obecne basic_string<T>::append()?

Tak napr. 70. leta jazyk SmallTalk.

Bylo mi jasné, že mě budete chytat za slovo. Proto jsem mluvil o praktickém nasazení. Experimentování s objekty je prováděno už od Simuly, ale praktický význam... word wide nasazení, (k modelování objektů být zaveden mimo jiné jazyk UML... rok cca 1995..., tedy já jej používám jen okrajově), má teprve v posledních několika málo let (10-15).

nicmene v C++ malokdo vi, co STL vlastne provadi a je velmi slozite to vubec pochopit, protoze je to hack za hackem.

Je to asi tak složité na pochopení jako strcat nebo printf. Žádné hacky tam nejsou (až na COW v std::string v GNU stdc++). Pokud šablony nechápete, obraťte se na dokumentaci od SGI, je tam detailně popsáno, co se tam děje.

K tomu pridejme pretizene operatory v kazde tride dle uvazeni konkretniho programatora rozsahleho skupinoveho projektu a jsme doma :)

To je potom prase ten programátor, že jeho třídy dělají neočekávané. Asi jako kdyby funkce strdup příslušný string dumpla do souboru na disk a v kopii toho stringu náhodně prohodila dva znaky.

Linus se rozhodne nepohybuje na urovni assembleru. Jeho nazor na C++ je skutecne vysledkem letitych zkusenosti a neni sam. Obdobny postoj ma vetsina prispevatelu projektu GNU ci Linux Kernel. Nicmene onu citaci jsem vytahl z emailu o git - http://lwn.net/Articles/249460/

A teď se schválně zkuste zeptat lidí, co programují KDE, ať máte pohled i ze strany lidí, co si C++ vybrali.

Nekorektni argumentace. Lidi od KDE si vybrali Qt, volba C++ pak uz byla logickym dusledkem - a kdyz se podivate jak se v Qt programuje (MOC a podobne), tak je jasne, ze volba nebyla kvuli objektovemu modelu C++, ale kvuli tomu, ze Qt z C++ diky MOC a souvisejicimu "macro hell" (abych pouzil neci termin z teto diskuse) dela docela pouzitelne programovaci prostredi.

-Yenya

V Qt je nějaké macro hell? Máš na mysli to jedno makro QT_CLASS, které slouží pro MOC? Mimochodem MOC vzniklo proto, že v době vzniku Qt nebyl žádný překladač, který by pořádně implementoval šablony. A do dneška se MOC drží už vlastně jen ze zvyku. V naprosté většině případů MOC vůbec není potřeba používat, je zahrabané někde dole a kdyby se všechna signálová volání přepsala do Boost Signals (a qt_cast na dynamic_cast apod.), fungovalo by to úplně stejně dobře a psalo by se v tom úplně stejně.

Cili jinymi slovy - mam pravdu v tom, ze Vase argumentace tim co a proc si vybrali vyvojari KDE je v tomto pripade irelevantni.

-Yenya

No není. Už v té době existovalo Motif, CDE a další a klidně si mohli vybrat to a vyhnout se C++. Což oni neudělali, zatímco vývojáři GNOME ano (a raději si vyvinuli vlastní toolkit). C++ skutečně byl jeden z důležitých důvodů, proč si vybrali Qt (viz zakládací zpráva):

The stuff is called "Qt" and is really a revolution in programming X. It's an almost complete, fully C++ Widget-library that implementes a slightly improved Motif look and feel, or, switchable during startup, Window95.

But the greatest pro for Qt is the way how it is programmed. It's really a very easy-to-use powerfull C++-library.

And limiting your project to C means that people don't screw that up

A já si myslím, že je to přesně naopak, v C se toho dá pokazit daleko víc a hrozně blbě se takové chyby hledají:

char buf[4];
memcpy(buf, sizeof(buf), "aaaa");
printf("%s", buf);

std::string s;
s = "aaaa";
std::cout << s;

GString *buf = g_string_new("aaaa"); puts(buf->str); g_string_free(buf, true);

A co je tohle? Vždyť to jsou objekty (akorát tomu říkáte jinak). Konstruktor, nějaký výpis do proudu a destruktor. Navíc ten destruktor musíte volat explicitně (a myslet na to), což asi bude důvod, proč X.org Server neustále leakuje :)

Co se treba podivat jake nechutne hacky jsou ve wrapperech C socketu pro C++? Nebo spinavosti v GTK2 -> Gtkmm ?

Jakých wrapperech C soketů? Já několik wrapperů znám a ani jeden nemá žádné hacky, je to skutečně jen velmi tenký obal kolem POSIX socketů (konstruktor = open, read, write, select, destruktor = close) a není nejmenší problém takový program portovat třeba na Windows, protože stačí jen přepsat ten obal úplně vespod.

GTK je špinavé samo o sobě, je to objektově orientované programování v procedurálním jazyce a příšené macro hell (Qt ale neustálou alokací na haldě a úplně debilním garbage collectorem není o moc lepší).

V rozsahlem projektu jsou objekty pritezi a proto treba takovy Mozilla Firefox / Mozilla XUL / GIMP / OpenGL / Xorg X11 Server / Gnome / Linux jsou vsechny v C.

A co třeba KDE, Sauerbraten (Cube), Skype nebo Google Earth, všechno v C++?

Jinak co se týče té vychvalované refaktorizace: chtěl jsem upravil aptitude, aby uměl pracovat s více než 65 535 balíčky, tak jsem změnil jeden typedef, který definoval typ pro ID balíčku. Víte, co se potom stalo? Vše se krásně zkompilovalo a aptitude po spuštění umřel na SIGSEGV. Prostě někde někdo nepočítal s tím, že by ten typedef mohl definovat něco jiného než 16-bitové číslo. Jó, to je ta perfektní refaktorizace. Zlaté objekty.

Jinak tím memcpy jsem chtěl ukázat krásný problém Céčka. Schválně jestli sis všiml, který to je (a který se v C++ - opravdovém C++, ne C++ s Céčkovým kódem - nevyskytuje).

To co jste teď ukázal, to jsou objekty. Opravdu, beze srandy. Objekty implementované technicky jinak, než v C++. Vy jste totiž do dnes nepochopil, co je to programování objektově. To není technická záležitost typu konstruktor a destruktor, nebo způsob syntaxtického zápisu. To je o myšlení. Uvádíte, jak jsou si příklady podobné. Asi vás možná překvapí, že výsledný překlad bude v obou případech velice podobný. Ano, i tady máte konstruktor "g_string_new", volani metody "puts a str" a destruktor "g_string_free". Rozdil je v tom, ze zatimco, vy si musite hlidat zanik objektů ručně, C++ to udělá za vás samo. Dokonce bych si dokázal představit obalení GString jako C++ objekt.

class MyGString {
   GString *s;
public:
   MyGString(const char *text):s(g_string_new(text)) {}
   const char *c_str() const {return s->str;}
   ~MyGString() {g_string_free(s);}
};

int main(void)
{
    MyGString  str = "Hello World";
    puts(str.c_str());
    return EXIT_SUCCESS;
}

No a teď mi napište, co shledáváte na tomhle objektu špatného, třeba oproti klasickému C. Kde je ta berlička, to co dělá nepřehledné. Naopak zde vidíte, že jako uživatel takového objektu nemusíte řešit jak spravovat paměť objektu. Vše je v režii objektu, ten si hlídá alokace a dealokace sám.

A to neuvažujeme třeba jako výhodu má nyní dědičnost, právě v možnosti přidat další funkcionalitu bez zásahu do originálního objektu. Neuvažuji už ani polymofizmus, který budete v C dělat velice obtížně.Ale jde to OOP pouze v C jsem viděl. C++ pouze usnadňuje psaní objektově. Řešení zániku objektu je pouze jedna z jeho automatických činností. Překladač za vás vyřeší často mnohem obtížnější věci, třeba inicializaci objektů při vícenásobné, nebo virtuální dědičnosti, volání virtuální funkcí přes ukazatel na funkci, virtuální destruktoru. Tyhle všechny automatické činnosti jsou už optimalizované s ohledem na cílovou platformu. Garantuji Vám, že ruční správa těchto činností v C v nejlepším případě vygeneruje stejně optimalizovaný výsledek (výjma nějakých extrabuřtů, težící z toho, že programátor má víc informací, než překladač)

Implicitne predpokladam, ze C++ je oblibenejsi mezi uzivateli Windows, Objekty jsou skutecne jen ty berlicky, ktere maji pomoci programovat i lidem, nemajicim na to bunky, asi jako M$ chce,...

Co takhle mi poslat kontakt na toho dealera, který vám prodal to pěkné zboží. Bejt takhle zhulenej se mi snad ještě nepovedlo.

Můj závěr je ten, že jste objektové programování nepochopil. Možná jste se naučil syntaxi, tu možná zvládáte dobře, ale nepochopil jste smysl celého toho počinu. Neoplýváte totiž patřičným myšlením, vidíte jen technickou stránku, nevidíte analytickou stránku. Jste prostě jen kodér, ona cvičená opice, co se jí řekne, naprogramuj to, a on to naprogramuje. Něco jako analýza problému, začínající modelováním reality (za pomocí objektů) a konče u konkrétní implementace Vám pravděpodobně nic neříká. Jinak byste se se mnou nehádal o tom, co je funkce, co je objekt. Technická realizace OOP je marginální záležitost. Jestli Vám tedy vadí C++ po syntaxtické stránce, tak v tom se nebudu hádat. Klidně navrhujte objekty v C. Budete s tím mít víc práce, ale budete mít pocit, že nad tím máte maximální kontrolu. Každou chvíli musím pracovat s knihovnami, jejichž autoři si myslí totéž. Naštěstí se dají leckteré zaobalit do objektu podobně jako MyGStream. (sice s tím mám práci, ale dá se).

V C++ se pracuje se streamy, proto je MyGString pekne spinava pitomost, puts() je v C++ taktez prasarna, mel tam byt cout Odvádíte téma. O tom to přece nebylo. Kdybych měl použít cout, musím ještě definovat operátor <<, aby pro streamy bylo zřejmé, jak se objekt ukládá do streamu. v rámci jednoduchosti příkladu, který ukazuje něco jiného jsem to neudělal. používáte falešné argumenty proto, abyste zamaskoval, že žádné nemáte... přistupujete k tématu čistě emocionálne.

Jeste, ze s vami nemusim spolupracovat na tvorbe nejakeho projektu

Tento názor, akorát na Vás mám ja.

Dale jiz pochopitelne nehodlam reagovat dokud se nenaucite na stejne urovni oba jazyky, ne jen jeden.

dtto.

Nebyl vyjmenovan jediny C++ projekt, ktery je tak cisty

Žádný projekt není křišťálově čistý. Programátoři rádi využijí i memcpy, zvlášť tam, kde se pracuje s nějakými lowlevel věcmi. O tom to fakt není. Ale pokud mluvíme o projektech, tak třeba Nová Seznam Lištička je komplet v objektech (i tam najdeš memcpy, strcpy, ale často proto, že WINAPI objektové není). Samozřejmě celý Seznamácký fulltext je v C++ a použití klasických C funkcí se omezuje jen na místa, kde se musí spolupracovat s operačním systémem. Budete tvrdit, že jsem neukázal žádný projekt? Podívejte se třeba na FastRpc (od Seznamu) je veřejné na SourceForge.

Zadny tenky kontejner v STL neni, je to hack za hackem a je to dobre videt i pri zkompmilovani STL s debug info a debuggingu vlastnich programu

Kromě toho COW v std::string v GNU libc++ jsem žádný hack v STL neviděl a i tenhle hack nová norma zakáže. Jinak můžeš příklad takového hacku jmenovat? A viděl jsi někdy, jaké hacky jsou třeba v implementaci printf?

Pokrocily programator uziva kvalitni funkce pro praci se stringy...

Ok, pokročilý programátor použije strncpy - a zmizí mu jeden znak. A jinak chyby off-by-one jsou jedny z nejběžnějších v Céčku, zatímco v C+ se (kupodivu) nestávají.

Teď mi není jasný jako hack s COW je myšlen a proč je to hack a proč by měl být zakázán. Obecně v mé implementaci stringů COW běžně používám. String totiž často vystupují jako hodnoty, a né jako stavové objekty. Jinými slovy, jsou R/O, dokud nepovolíme přímý zápis na znak. Veškeré operace jsou koncipovány jako binární operace, do kterých vstupuje řetězec a případně další řetězec nebo parametr(y) a výsledkem operace je nový řetězec, starý zůstává.

Pokud se tím hackem nemyslí nějaká platformově závislá akce, třeba COW na paměťové stránce. COW jinak patří k běžným objektovým technikám jak optimalizovat zejména předávání řetězců a vracení z funkcí ale možnost ušetřit si paměť na duplicitních textech.

Jedna z možností (ta čistá) je COW pomocí const std::string & a následně přiřazením do std::string, pokud je nutné s tím dále pracovat. COW v GNU libc++ je hack, protože dělá u std::string něco, co pořádně nefunguje v multithreadovém prostředí, případně se to musí pořád zamykat. Hack to není proto, že by to bylo nějak špatně napsané, ale proto, že to dělá za programátora něco, co by měl dělat programátor.

Objekty zvladam jiz nejmene 10 let a narozdil od vas vim, co musi splnovat, aby se jim tak mohlo rikat.

Wikipedia: „All programming languages present objects. … How an object is created varies among language.“ GString je samozřejmě objekt a místo metod voláte funkce s prvním parametrem tím objektem = to samé, jak jsou metody implementovány. Akorát místo třešní tomu říkáte višně a tváříte se, že je to něco úplně jiného.

proto je MyGString pekne spinava pitomost

Ano, ten příklad byla špinavá pitomost, sloužilo to jen k demonstraci, že děláte úplně to samé, co by dělal takový C++ objekt s metodami - a bez nutnosti si pamatovat, že je nutné zavolat destruktor, pardon, funkci g_string_free.

Dale jiz pochopitelne nehodlam reagovat dokud se nenaucite na stejne urovni oba jazyky, ne jen jeden.

Mě čím dál víc připadá, že o C++ vlastně nevíte skoro nic, kromě toho, že je tam STL a nějaké objekty s dědičností.

Ona mezi náma, struktura je speciální druh objektu. Takže asi tak :-)

Jinak samozřejmě k tomu nemám co říct, jen LOL.

Pro vaši informaci. V C++ nejsou objekty v pravém slova smyslu... to se jen všichni OOP programátoři dopouští zkratky. Správně by se mělo říkat "instance třídy". V C++ zdrojáku nemáme objekty, ale třídy. "class". Objektem se rozumí obecně cokoliv. Objektem totiž i třída, struktura, proměnná, objektem jsi ty, já, objektem je tahle diskuze. Pokud mluvíme o objektech, myslí se tím, že něco jako objekt vystupuje, nějak se chová, nějak s ním komunikujeme. Příklad s GStringem je přesně příklad objektu, protože to jako objekt vystupuje, chová se a dokonce hodně připomíná instanci třídy v C++. Prostě je to objekt. Objekt je prostě to nejobecnější co v programu vystupuje.

Ale nenechte se zmást, program C++ nemá objekty. Program má třídy a ve spuštěném programu napsaným v C++ také defacto nejsou objekty, tam jsou registry, paměť, proměnné, kód, instrukce... žádné objekty. Objekty tomu říkáme my, je to flujdum, virtuální záležitost, věc dohody mezi programátory.

Takže neplést. Žádné objekty, C++ má třídy a instance třídy. Jsou to speciální objekty vzniklé instanciováním třídy. Mimochodem, na obecnější úrovni stejně tak fungují objekty jako instance šablon, to jsou třídy. Instance šablon vedoucí na strukturu jsou taky objekty. V generice totiž velice často pracujete s objekty jako s instancemi šablon. Chová se to jako objekt, má to své rozhraní, má to svůj vyhrazení prostor, způsob vzniku a zániku. Dokonce i instanciací šablony může vzniknou šablona... a to je taky objekt

instance struktury GString je objekt... Máte pravdu, není to instance třídy ... ale je to stále objekt.

To jen proto, aby jsme si srovnali terminologii. Nicméně to co se Sten a Já snažíme vám vysvětli tak je to, že C++ se člověk nenaučí tím, že si našprtá syntaxi.

Možná znáte, ale evidentně ho neumíte používat.

Dle vašeho tvrdošíjného trvání na definicích stále dokazujete, že sice máte C++ našprtané, ale absolutně jste nepochopil, o čem OOP je. Objekty například vůbec nemusí být definované třídou, což lze ukázat třeba v javascriptu. Ony opravdové OOP jazyky ani třídy nemají. A pokud mluvíme OOP v souvislosti s C++. Použiju příměr uvedeny zde v diskuzi... Ano: Třídy jsou takové berličky, které zjednoduššují v jazyce C programovat objektově. C++ nabízí spoustu takových berliček, pomocných syntaxtických konstrukcí, a jiných záležitostí. Ale právě proto, že to jsou jen berličky, není C++ čistý plnohodnotný objektový jazyk. Bohužel situace je taková, že v poměru cena/výkon je to nejlepší, co znám.

PS: Co byste řekly na instanci šablony? Ačkoliv to dle Vaší definice není objekt, tak budete se divit, ale objektem je. Analogii tu najdete.

dynamickou alokaci pameti a dealokaci teto pameti v proceduralnim programovani s konstruktorem a destruktorem z objektove orientovaneho programovani

Můžu se dozvědět, jaký je v tom rozdíl, kromě toho, že tomu jinak říkáte? A zrovna u toho GStringu nešlo jen o alokaci, ale také o instancování té struktury daty, které mají smysl, a při dealokaci k odstranění všech vnějších odkazů (třeba alokovaného bufferu znaků) podle jejího obsahu.

Implikace není ekvivalence. Třída je sice prototyp pro objekt, ale není to jediná možnost, jak objekt může vzniknout.

Tvrdim snad nekde, ze trida je jedina moznost, jak objekt muze vzniknout? Netvrdim :)

objekt je ... chovani definovane tridou objektu.

Trochu nechapu, jak se tohle nevyvraci

Potom nechápu, jak je možné, že třída není jediná možnost vzniku objektu.

Hmm, aha, a Wikipedia (odkud jsem citoval) a všechny reference, na které se odkazuje, je taky blbě a jedině dobře to chápeš ty, že? Nic proti, ale přeci jen věřím Wikipedii než nějakému anonymovi, který se bojí svůj komentář i podepsat :)

Jinak příklad není definice, ale to bys snad měl vědět.

http://en.wikipedia.org/wiki/Object_%28programming%29

Doporučuju přečíst. Obzvlášť předluvu a tu první (teoretickou) část.

Můžete mi laskavě anonymní uživateli vysvětlit co se snažíte dokázat? Tvráním na přesných definicích se ostatní snažíte ukázat, že neumíme objektově programovat, a na základě toho dokázat že C++ je k ničemu, což deklarujete na příkladě v jazyce C, který sice není objektový, ale ve kterém používate velice podobné techniky, které C++ používá k implementaci OOP. Tak k čemu taková diskuze je?

Pletete OOP a objekty. Objekty nejsou jenom v OOP stejně jako funkce nejsou jenom ve funkcionálních jazycích.

Hmm, zajimave, pletu se ja, Ondra, Wikipedie, Princeton Dictionary ("Object (computing) a discrete item that provides a description of virtually anything known to a computer;" http://wordnetweb.princeton.edu/perl/webwn?s=object), profesor John English, autor jazyka Ada z Prentice Hall ("A constant or variable of a specified type." http://www.cmis.brighton.ac.uk/~je/adacraft/glossary.htm), vyvojari linuxoveho kernelu ("Object: A passive entity that contains or receives information. Access to an object potentially implies access to the information it contains." http://www.kernel.org/pub/linux/libs/security/Orange-Linux/refs/Orange/Orange0-5.html), TechRepublic ("object: any thing, idea, or concept is an object." http://articles.techrepublic.com.com/5100-22_11-5076597.html) a spoustu dalsich, jen ty jsi jediny, kdo to vi spravne.

Sakra, Adu vlastne vytvoril Jean Ichbiah

Těžko můžeš aplikovat definici z OOP na ne-OOP jazyk. Krom toho i v C++ by GString byl objekt.

Zpět. V C++ by GString byla struktura (třída) a její instance objekt. Tak je to správně.

Pane profesore, já myslím, že tady dochází značnému zmatení všech, nejen nás a Vás. Já bych řekl, že jsme stále nesestoupili na stejnou frekvenci myšlení. Stejně jako vy jsem začínal na C (ještě předtím v Pascalu) a postupně jsem přešel na C++, mezitim jsem si pohrál s Javou a něco drobného ve smalltalku (i když to je šilenej jazky). Můj náhled na OOP by se dal rozdělit do několika urovni, tak jak jsem sve dovednosti casem procvicoval.

1. Objekt je striktne definovaný (lapidárně) jako "utvar v programu, ktery obsahuje data a metody s daty pracujici na jednom miste". Čili ve smyslu definice, kterou jste tu víceméně připoměl
2. Objekt je cosi, co lze považovat za minimální entitu v programu žijící vlastním životem a komunikující s jinými objekty, má přesně definovaný svůj vznik a zánik a rozhraní, se kterým komunikuje s okolím
3. Objekt je model reálného objektu našeho reálnho světa

Nejprve jsem byl na úrovni 1) a hádal se s každým okolo, kteří mě přesvědčovali, že existuje i úroveň 2) a 3). Jako Vy. Teprve pochopením úrovně 2) a úrovně 3) pro mne začalo OOP mít smysl. Prvně tedy jako nástroj, jak vytvořit v programu řád mezi jeho části, kdy jasne definovat zodpovědnost objektů za jednotlivé dílčí úkoly daného programu. Proto jsem schopen ve vašem GString vidět objekt, byť na úrovni 1) bych tuto myšlenku zavrhl. Jenže toto je možné na úrovni 2) protože GString lze považovat za minimální entitu v programu žijící vlastním životem a komunikujcící s jinými objekty. Má přesně definovaný vznik a zánik a rozhraní, se kterým komunikuje s okolím. I když toto rozhraní je definované procedurálním jazykem, pokud virtuálně spojíme tyto funkce s daty uloženými ve struktuře, získáme objekt, který může (po tomto virtuálním spojení) vyhovovat i definici 1). Pokud pochopíme i úroveň 3) stane se pro nás OOP prostředkem jak jednoduše, ale zato velice efektivně modelovat objekty z reálného prostředí v programu. V této fázi Vám garantuju, že Vám C++ přestane vadit a naopak budete oceňovat jeho pomoc při modelévání takovýchto objektů.

Tím chci říct, že po pochopení úrovně 2 a 3 budete schopen používat a modelovat objekty i v jazycích, které nejsou pro OOP určeny. Budete tvořit objekty v Prologu i v Lispu, víceméně v každém jazyce, který zvládne aspoň dekompozici. Ale samozřejmě, bude to považovat za utrpení a ztrátu času a raději sáhnete po nějakém OOP jazyce. Nicméně pak možná pochopíte, proč i v linux shellu jsem schopen vidět objektové prvky, byť to je jazyk, který podle definice 1) objektový neni a ani být nemůže.

Proto stále trvá můj názor, že jste se dobře naučil syntaxi, ale zatím jste nepřešel vrchol OOP a tak návrat C je pro vás cesta dolu, čili snadnější. Až se vám podaří ten vrchol překonat, návrat k procedurálnímu programování bude pro vás chůze do kopce a tato cesta se stane pro Vás nepohodlná.

Jinak doporučuju doporučuju pana Tomáše Kozla z FIM UHK, ten OOP vysvětluje na Javě a celkem pěkně. Dále tam mají předmět Objektové modelování, na tom lze OOP velice pěkně pochopit

uz vubec nebyl jmenovan takovy C++ projekt, bez ktereho bych se neobesel

Co třeba Google Search nebo Gmail?

C++ tam není minoritní částí, veškerý backend běží na C++. <irony>Ale hlavně že tam je C, že.</irony>

...asi jako M$ chce, aby si uzivatel predstavil "Muj pocitac" misto hard disku, dvd-vypalovacky, usb disku, etc. protoze by tomu nerozumel. Pokud se k tomu dostane uzivatel, ktery ale znalosti ma, pouze bude zmaten a iritovan kvuli nadmerne abstrakci.

V tomhle prirovnani mate podle me trochu pravdu. Ale ten kdo programuje objektove, musi prave prestat chtit vedet, co je uvnitr "krabicky". To je ta zmena mysleni. "Tento pocitac" je prilis slozity objekt, nema jasne definovane vstupy a vystupy a proto musite znat vnitrek, abyste ho byl schopen ovladat. U spravnych objektu to ale neplati, tam se o vnitrek nestarate vstupy a vystupy jsou jasne popsane (mely by byt) a nic vic nepotrebujete. Chovate se k objektu jen jako uzivatel

Ono to v praxi funguje tak, že za černou krabičku často někdo nese zodpovědnost. Pak když černá krabička nefunguje, honíme k zodpovědnosti autora. To je prostě stejné, jako v reálném světě. V programování často větší logické celky končí tam, kam dosáhne časový a paměťový akční rádius daného programátora. (co stihne ještě držet v paměti a časově zvládat udržovat a vyvíjet). Jenže tito programátoři jsou jako bohové. Mají své dílo, tomu rozumí, nikdo jiný mu nerozumí, jsou nenahraditelní. Pokud program převedeme na malé jednotky v OOP, kde jedna krabička by se s náročností na pochopení dala přirovnat k jedné hodině studia zdrojáků, pak nenahraditelnost těchto programátorů povážlivě trpí. V týmu se to dělá tak, že všechny objekty se hodí na hromadu, rozdělí se mezi programátory, každý má na starost nějakou oblast. Přestane-li to zvládat, část objektu se převede na jiného programátora. Větší programové celky pak řeší senior programátoři, kteří ale stejně tak vidí jen černé krabičky, a nezajímá je vnitřek. Pochopení fungování těchto celků na základě krabiček (objektů) má pak podobnou časovou náročnost.

Podle mne je báječné na OOP, že program se skládá z atomů, minimálních objektů. Mám objekty, které jsou na dva řádky. Jsou to pořád objekty. Pořád se s nimi pracuje stejně (snadno). Pokud by daný problém nebyl řešen objektově, mnohem hůř by se pak s problémem pracovalo.

(-: Mimochodem Linux shell je objektový. Každá spuštěná aplikace má stdin a stdout a parametry na příkazové řádce. Kolikrát člověk vidí, jak nějaká linuxová aplikace je jen spolupráce několika různých malých prográmků. Ty jsou taky černé krabičky a autoři těchto aplikací nevědí, a ani často nechtějí vědět, co se skrývá unvnitř :-)

No jestli programuješ tak, že za svůj kód neneseš zodpovědnost, pak se vůbec nedivím, že píšeš v C :)

Aha. další člověk zblbej GNU GPL... já pořád říkám, že za soft by se mělo platit... :-)

Tebe musí být radost zaměstnat, když vlastně za svůj výtvor neneseš zodpovědnost :)

Že by vlastní zkušenost? :-D

Az tvuj blok kodu v knihovne vyvijene teamem tedy nekomu zpusobi v produkcnim nasazeni memory leak na vsech updatovanych strojich (cca 80) a firemni sluzba bude kvuli tve chybe nedostupna napr. cely den, budes nest odpovednost a usly zisk sve obeti zaplatis v plne vysi ze sve kapsy. Prijde ti to normalni?

Ano, nesu za to odpovědnost a přijde mi to normální. Dospělí lidé mají nést zodpovědnost za své činy, to je mimochodem definice právně dospělého člověka. Sice nebudu platit celý ušlý zisk, ale na snížení platu se to projeví.

Měl jsi někdy koupenou nějakou komerční licenci pro firmy? Třeba od Oracle, kde je uvedeno, že v případě problému budou jejich technici na problému pracovat tak dlouho, dokud ho nevyřeší.

Nedovedu si představit, jak by ses tvářil, kdyby někdo z tvých příbuzných letěl letadlem se software, kde autor udělal chybu a omlouval se: „Letadlo spadlo vinou mého software a zemřelo 150 lidí, ale já za nic nenesu zodpovědnost, to se prostě stává.“ Krásný příklad by mohla být chyba v Theracu-25, která způsobila smrt nejméně pěti lidí a AECL (výrobce Theracu-25) následně měl velké problémy s úřady a vyrovnání s pozůstalými ho stálo hodně peněz.

Mimochodem i u těch Windows pro domácnosti máš jako součást licence bezplatné aktualizace, což je ta zodpovědnost. Bez zodpovědnosti = uživateli, je tam chyba, ale máš smůlu, mě se to řešit nechce.

Nebo zabezpečovačka v Moravanech, která díky chybě mimojiné v SW nepovažovala za divní, že jí z kolejiště zmizel vlak. Postoj autorů byl podobný jako v tomto případě :-)

Nést odpovědnost nemusí nutně znamenat nést plnou odpovědnost. A mimochodem od toho existuje pojištění, ne?

Nést odpovědnost neznamená nutně nést plnou odpovědnost. V pracovní smlouvě mám uvedeno, do jaké výše škody nesu odpovědnost. Krom toho při spoluautorství určitě nemůžeš chtít po všech autorech, aby nesli plnou odpovědnost a nechat si zaplatit škodu víckrát.

Pojištění profesní odpovědnosti. Neznáš?

Diskutovat s puberťákem prostě cenu nemá. Ten člověk nic nenapsal, nikdy nepracoval v týmu, pouze plácá a hraje si na velkého :-)

Nejhorší na tomhle je, že nejde o puberťáka, ale učitele z FI MU (ale je to systémák, tak trochu chápu jeho averzi vůči C++). Docela by mě zajímalo, jaký má na něj názor pan učitel Ing. Kučera, který učí C i C++.

Aha. No ono když někdo není schopen své příspěvky nějak podepsat, tak to potom vyvolává zdání, že je to stejný pisálek jako ten, kdo své příspěvky podepisuje a má stejný (či podobný) názor, což zde byl Yenya. V tom případě se omlouvám, že jsem vás dva spojil do jedné osoby.

Samozřejmě je lepší (a snažší) přenést veškerou odpovědnost na zákazníka, proto také spotřebitelský zákon ukládá povinnou odpovědnost prodejců (prostě aby tohle prodejci nemohli udělat). Nicméně nikdo vás nenutí nést plnou odpovědnost, i ve smlouvě se zákazníkem lze specifikovat maximální výši ručení (klidně nulovou, ale ne vždy to jde, někteří zákazníci chtějí alespoň nějakou) nebo založit s.r.o.čko, které má omezení odpovědnosti přímo ve své definici. Stejně tak lze omezit, na co vše se odpovědnost vztahuje.

Bude možná lepší, když nám nebudete vnucovat to co baví jen Vás. Mne tedy nic užitečného na výkonné knihovně IPv6 v C nic nepřijde. Ale to je věc názoru. Objekty modeluju cca 10 let. A pořád mě to baví. A delám to v C++. A namodelovat dobře fungující objekt nezvládné podprůměrny script kittie ani v Javě. To vám garantuju! Právě že to co padá z těchto průměrných script kitties (což je většina programátorů) pak vede ostatní k závěru, že objekty jsou na nic. IMHO. Kdyby nebyly objekty, výsledek dopadne pro procedurální programování naprosto stejně.

Mimochodem generický (šablonový) program se daleko daleko jednodušeji refaktoruje než procedurální,

Mozna kazdy rozumime pod "refaktorizaci" neco jineho. Jiste - u zapouzdreneho objektu snaze zmenite datovy typ interniho atributu (jak si nekdo stezuje v diskusi ze v C mu neslo jednim typedefem). O teto refaktorizaci nemluvim - u ciste navrzenych programu je stejne snadna v C jako v C++. Mluvim o tom, ze se najednou rozhodnete zmenit objektovy model (mapovani veci z realneho sveta na jednotlive objekty/tridy). Tohle proste rozumne nejde, nebo to stoji strasne moc usili, protoze toto uz neni uvnitr zapouzdreneho objektu, ale je to zmena rozhrani, na ktere jsou uz vsichni ostatni prizpusobeni. V C je toto jednodussi, protoze tady obvykle nemusite predelat cely objektovy system, ale proste vyrobite funkci, ktera misto treba dvou drive volanych funkci dela totez.

daleko snáz se tam dělají unit testy (test driven development)

tohle je pravda,

a daleko méně duplicitního kódu je třeba napsat. To, že většina programátorů v C++ zná šablony jen jako STL, není chyba jazyka, ale příslušných programátorů.

a tohle je nesmysl. Predpokladam ze se mi vysmejete, kdyz Vam reknu "To ze mnoho programu v Perlu vypada jako porucha na lince neni chyba jazyka, ale prislusnych programatoru.".

Ad duplicitni kod: urcite kdyz si predstavite nejakou krasnou objektovou dedicnou anebo sablonovou hierarchii, je treba psat daleko mene kodu k jeji implementaci. Ale kde v realnem svete (snad krome grafickeho rozhrani, jehoz vznik primo souvisi se vznikem OO programovani) nejakou dedicnost realne vyuzijete, aby vam usetrila ten duplicitni kod?

-Yenya

Mluvim o tom, ze se najednou rozhodnete zmenit objektovy model (mapovani veci z realneho sveta na jednotlive objekty/tridy). Tohle proste rozumne nejde, nebo to stoji strasne moc usili, protoze toto uz neni uvnitr zapouzdreneho objektu, ale je to zmena rozhrani, na ktere jsou uz vsichni ostatni prizpusobeni.

Nemáte pravdu. Zaprvé, pokud je potřeba změnit model, pak je jasné, že někdo špatně udělal analýzu, špatně věc vymodeloval. Ano stává se to, většinou lidi příjdou o prémie. Práce s tím je jak v C, tak v C++. V C++ se to většinou řeší wrapováním objektu. Původní třída zůstane, ale emuluje staré rozhraní na nové třídě. Takhle třeba funguje kompatibilita v DirectX. DirectX10 poskytuje objekty DirectX9, které jsou pouze emulují rozhraní a samy volají DirectX10. Podobně DirectX8 emuluje rozhraní přes DirectX9. Atd. Pokud byste dneska psal program v DirectX3, tak je (teoreticky možné), že požadavky zaslané na DirectX3 jsou poslány na objekty 4, ty je posílají na objekty 5... až to končí u 10, která to provede. Prakticky to není tak horrible, bude tam spoustu zkratek. Kompatibilita je zaručena, nové programy stejně vznikají na nové rozhraní.

Nic předělávat nemusíte, pouze vytvoříte znova a starou funkcionalitu emulujete. Právě že díky tomu, že objekt je černá krabička se vůbec nemusíte starat o to, jestli ta černá krabička poskytuje funkcionalitu přímo, nebo je pouhou emulací nové verze.

Ale kde v realnem svete (snad krome grafickeho rozhrani, jehoz vznik primo souvisi se vznikem OO programovani) nejakou dedicnost realne vyuzijete, aby vam usetrila ten duplicitni kod?

Každých deset minut.

To neni "nekdo spatne udelal analyzu". Proste se jen mohl zmenit vnejsi svet. Jak jsem psal, navrhovat rozhrani je tezke. Coz znamena, ze i odbornik se v tom muze splest nebo nemit dostatek informaci. Proto se dnes nepouziva vodopadovy model navrhu, ale treba ty agilni metody. Je treba proste pocitat s tim, ze se svet bude menit, a ze budete potrebovat refaktorizaci (coz je ale v pripade objektoveho modelu tezke).

Emulace objektu ovsem pak znamena, ze mate neoptimalni a spatne udrzovatelny kod. Z duvodu zpetne kompatibility verejneho API operacniho systemu (to DirectX) bych to pochopil, ale ne v samostatnem projektu.

"Kazdych deset minut" neni odpoved na otazku kde :-). A nemluvte o dedicnosti systemovych trid, ale o neceho, co jste sam navrhl a v nejakem velkem projektu pouzivate.

-Yenya

To neni "nekdo spatne udelal analyzu". Proste se jen mohl zmenit vnejsi svet

Jednak, vnější svět se nemění tak často, jednak změna vnějšího světa se nemusí nikdy projevit tak hluboko do programu. Objekty používáme zejména na modelování vnějšího světa a přizpůsobení interním pochodů v programu. Pokud modeluji televizi, určitě ji umím zapnout, vypnout, změnit program. Bez ohledu jaká je to televize, jaký má rozhraní, můj způsob ovládání se nezmění, pořád ji budu chtít zapnout, vypnout, změnit program. Až se začnou televize ovládat jinak, mohu můj objekt na ovládání televizí přepsat tak, že sám se bude vydávat za starou televizi. Za ním bude sedet emulátor, který bude emulovat činnost staré televize a požadavky transformovat. Musím si rozhodnout, zda mi za to stojí psát emulátor, nebo přepisovat půlku kodu. Spočítat, náklady. Nemohu svalovat vinu změny světa na objekty. Ty za to nemůžou. Taky si nedokážu představit, jak agilními metodami vyřešíte změnu světa. Třeba v okamžiku, kdy místo klasické televize vám předhodím internetovou televizi. Pořád ji umíme zapnout vypnout, ale program už třeba není číslo, ale URL adresa. Stále mohu ale napsat objekt, který bude umět naladit program podle čísla. Jak byste to řešil bez objektů čistě s ohledem na zbytek kódu.

Tím odpovídám i na dědičnost. Právě případ té televize. Naše internetová televize může dědit klasickou televizi. Obě se umí zapnout, vypnout, ale každá ladí programy jinak. Jedna používá číslo programu, druhá url. I tak je internetová televize také televizí, takže může ji dědit a funkcionalitu přepnutí programu emulovat (třeba tabulkou programů ve formě tabulky URLs) I nadále jste schopen televizi používat jak tam, kde se už očekává internetová televize, tak tam, kde se předpokládá klasická televize. A v dědění mohu pokračovat. Třeba přijde na svět interaktivní televize. Pořád je to ale televizí, pravděpodobně bude i internetovou televízí. Podědíme tedy internetovou televizi a rozšíříme ji o interaktivní funkce. A vida, stále jsme schopni novou televizi používat v programu, tam kde se předpokládá klasická TV. Můžeme přepínání programů považovat za určitou interaktivní akci, takže přepnutí programu opět emulujeme. Můžeme používat tuto televizi i jako klasickou internetovou televizi s tím, že neumí interaktivitu. To nevadí, programy, které interaktivitu neumí, ji prostě použijí klasicky. A ještě jednu věci. V programu mohu naráz pracovat se všemi typy televizemi. Zejména ty části programu, které umí pracovat jen s klasickou televízí si budou rozumět i s interaktivní televizí. I kdyby na světě zmizeli klasické televize a svět se změnil, nové televize budou mít naprosto jiné rozhraní, můj podprogram předpokládající klasickou TV, co se umí zapnout, vypnout a přepnout program, stále bude bez problému fungovat.

class GenTV {
public:
  virtual void turnOn();
  virtual void turnOff();
};
class ClassicTV: public GenTV {

public:
  virtual void switchProgram(int number);
};

class InternetTV: public ClassicTV {
public:
  virtual void switchProgram(const char *url);
};

class InteraciveInternetTV: public InternetTV {
public:
  virtual void useInteractiveAction(Action a);
};

A to jsem použil jen objekty. Šablony nabízí daleko víc možností.

Emulace objektu ovsem pak znamena, ze mate neoptimalni a spatne udrzovatelny kod.

Asi tak stejně neoptimální, jako když dvě funkce v C obalíte a spojíte do jedné.

a tohle je nesmysl. Predpokladam ze se mi vysmejete, kdyz Vam reknu "To ze mnoho programu v Perlu vypada jako porucha na lince neni chyba jazyka, ale prislusnych programatoru

Jak souvisí šablony v C++ s Perlem?

V C je toto jednodussi, protoze tady obvykle nemusite predelat cely objektovy system, ale proste vyrobite funkci, ktera misto treba dvou drive volanych funkci dela totez.

Začínám mít dojem, že nechápete/nevíte, co jsou šablony. Šablony NEJSOU objektový systém. Proto se snadno refaktorují a proto je celé STL napsané v šablonách.

Predpokladam ze se mi vysmejete, kdyz Vam reknu "To ze mnoho programu v Perlu vypada jako porucha na lince neni chyba jazyka, ale prislusnych programatoru.".

Ano, vysměji, správné přirovnání by bylo: „To, že někteří programátoři nechápou program napsaný v Perlu, není chyba jazyka, ale příslušných programátorů.“ Což také je.

nejakou dedicnost realne vyuzijete, aby vam usetrila ten duplicitni kod

Opět, šablony nejsou žádná objektová hierarchie. Třeba std::copy mi přijde daleko daleko lepší než memcpy. Dělá to to samé, akorát na rozdíl od memcpy se optimalizuje na objekty, které tak kopírujete, a je to tedy buď stejně rychlé nebo rychlejší a je to daleko přehlednější než žonglování s pointery na void.

Ale kde v realnem svete nejakou dedicnost realne vyuzijete, aby vam usetrila ten duplicitni kod?

No třeba takový hezký příklad je s loděmi: všechny lodě plují a mají nostnost (tedy mohou nést náklad: metody „nalož“ a „vylož“), ale třeba plachetnice mají jiný druh pohonu než kolesový parník (= různé implementace virtuální metody „pluj“), tudíž u plachetnice asi nemá smysl „pluj“ implementovat tak, že se přiloží do kotle.

A jestli máš na mysli programování, tak zrovna na jednom takovém programu dělám: mám tam hodně front, většina se chová stejně a některé mají různé způsoby uklízení (data vyhodí nebo je přesunou jinam ap.) nebo ověřování vkládaných dat (některé ověřují, jiné ne, některé třeba na základě vkládaných dat vyhodí jiná data ap.). A je k tomu jednotné rozhraní, přes které se na fronty odkazuje jen pomocí jejich jmen (to jméno přijde zvenčí, takže se musím odkazovat pomocí jmen). Nedovedu si představit, jak bych něco takového napsal v Céčku, aniž bych nějak emuloval ty virtuální metody, tedy dělal dědičnost.

Y3stXP vrekazvfhvka, [url=http://lps­snuwiniwi.com/]lpssnu­winiwi[/url], [link=http://qen­xsisnzsxa.com/]qen­xsisnzsxa[/lin­k], http://vreepioprvpr.com/

Y3stXP vrekazvfhvka, [url=http://lps­snuwiniwi.com/]lpssnu­winiwi[/url], [link=http://qen­xsisnzsxa.com/]qen­xsisnzsxa[/lin­k], http://vreepioprvpr.com/

Y3stXP vrekazvfhvka, [url=http://lps­snuwiniwi.com/]lpssnu­winiwi[/url], [link=http://qen­xsisnzsxa.com/]qen­xsisnzsxa[/lin­k], http://vreepioprvpr.com/

Kolik radku ma stary "Kompas" a novy fulltext? Tezko rict :) Ale vysel bych z toho co jsou schopni vyprodukovat 2 lidi behem vanocnich prazdnin v porovnani s 10-20 lidmi za 2-3 roky. :-D

Vyhledavac se neprepisoval z C do C++, nova verze je prostě úpně jiné řešení. a C++... dneska asi už neni důvod psát něco v čistém C, maximálně pro nějaká embed zařízení, ale i tam je to sporné :-)

Stary kompas (část vyhledávač) měl asi 17000 řádek, část crawler se nedochovala.
Nový je skoro o dva řády dál (nepovedlo se mi spočítat přesně).

Ad údržba windows - ke konci jsme začali používat virtual servery, značně to usnadňuje práci; reinstall se pak degraduje na zastavení, zkopírování jednoho adresáře a spuštění :-)