Přejít k navigační liště

Zdroják » Rozhovory » Štěpán Škrob: Horkým kandidátem byl WebKit, ale vybrali jsme Gecko

Štěpán Škrob: Horkým kandidátem byl WebKit, ale vybrali jsme Gecko

Články Rozhovory, Různé

Vyzpovídali jsme Štěpána Škroba ze společnosti Seznam.cz. Zeptali jsme se na několik novinek fulltextového vyhledávače Seznamu. Jak rychlá je nedávno spuštěná nová verze generátoru náhledů? Proč běží právě na Gecku a jak funguje? Proč začal Seznam podporovat mikroformát geo?

Seznam jako jediný český fulltextový vyhledávač obsahuje ve výpisu výsledků náhledy stránek. Kdy jste je nasadili a jak vás ta myšlenka napadla?

Náhledy stránek jsme nasadili poměrně dávno. Už když jsme začali pracovat na vlastní verzi vyhledávání, tak jsme s náhledy počítali. To bylo zhruba v roce 2005. V rané fázi Seznamu největší invenci do služeb vkládal Ivo Lukačovič a myslím, že s tímto nápadem přišel on.

Váš první generátor náhledů jste postavili na Internet Exploreru. Proč jste zvolili právě tohle řešení?

Udělali jsme si průzkum a Internet Explorer z něj vyšel jako nejovladatelnější. Pokud někdo programuje pro Internet Explorer, jistě to potvrdí. Na jádro IE lze navěsit callbacky na velkou množinu akcí, které IE dělá. Pomocí nich se dá jádro ovládat, aby dělalo to, co chceme, a také tím můžeme sledovat jeho činnost.

Zbylé varianty, které jsme zkoušeli, nebyly v dostatečně pokročilé fázi, aby nabídly totéž. Další výhodou IE bylo, že náhled, který z něj generujeme, obsahoval pluginy, např. Flash. Pokud bychom v té době zvolili jiné jádro, museli bychom takové věci doprogramovat, aby byl náhled plnohodnotný.

Štěpán Škrob

Štěpán Škrob (1974)

  • S Ivem Lukačovičem v letech 1996–97 vytvořil fulltextový vyhledávač Kompas.
  • Dnes je produktovým manažerem ve vyhledávacím týmu v Seznamu.
  • Rád létá s modely letadel.
  • Píše na Seznam Fulltext Blog pod přezdívkou Solamyl.

Vytvořili jste vlastní aplikaci, která embedovala komponentu IE?

Generátor běžel jako služba ve Windows, která využívala komponentu Internet Exploreru. Spustila si asi 20 instancí IE, které načítaly stránky a po jejich načtení snímaly obrázky. Ty byly následně zmenšeny.

Jaký byl výkon tohoto generátoru?

Ve špičce tak 2–3 snímky za vteřinu. Ale to byl celkový výkon několika strojů. Používali jsme tenkrát 2–3 počítače.

Můžete se ptát, proč 20 IE udělá tak málo screenshotů. Má to dva hlavní důvody – za prvé veškeré stahování z IE ve Windows jde (je to tedy jen domněnka, ale všechny indikace k tomu spějí) přes jediný download manager, který omezuje celkový průtok dat, takže přidávání dalších IE od určitého bodu nepomáhá. A ten druhý důvod je, že focení některých stránek prostě trvá dlouho. Pokud stránka obsahovala Flash, tak jsme od okamžiku oznámení načtení celé stránky ještě čekali asi 20 vteřin, aby náhled obsahoval nějakou pěknou část a nikoliv jen bílou stránku „Loading…“.

Štěpán Škrob

Dnes bez problému pořídíme asi 20 náhledů za vteřinu.

Takže jste se rozhodovali i podle vlastností dané stránky. Jaké informace vás při tom zajímaly?

Kromě toho, zda stránka obsahuje Flash a jiné dynamické prvky, jsme zjišťovali, jaké má rozměry. Detekce dynamických prvků je důležitá pro určení doby čekání pro vyfocení a rozměry pak pro nastavení šířky okna prohlížeče.

Některé stránky byly optimalizované pro šířku 1024 px, jiné měly centrovaný design a 600 px. Pokud bychom obě snímali na 1024 px, tak by stránka s 600 px byla příliš úzká. Proto jsme podle těchto údajů volili optimální rozlišení pro snímání náhledů.

Nedávno jste spustili novou verzi generátoru. Ta je postavena na jádru Gecko. Proč jste vůbec dělali změnu?

S tím prvním systémem byla řada provozních problémů. Máme u nás spoustu serverů a administrátoři, kteří je spravují, nemůžou tolik času věnovat pouze jedné aplikaci. A první systém byl náročný na údržbu. Po spuštění běžel průměrně asi měsíc, pak byla zapotřebí údržba. Na naše poměry to ale bylo příliš často.

To je jediná věc, ve které je nový generátor lepší?

Je jich víc, zkusím je shrnout:

  • větší rychlost
  • větší spolehlivost (původnímu generátoru se čas od času některé náhledy nepovedly)
  • menší náklady na údržbu

Hodně nám záleželo právě na rychlosti. Před časem jsme zlepšili robota fulltextového vyhledávání, takže dnes stahuje stovky stránek za vteřinu. Vedle toho generátor náhledů zvládal ony 2–3 stránky za vteřinu. Proto byly náhledy někdy zastaralé.

Štěpán Škrob

O kolik bude nový generátor výkonnější?

Výkon ještě ladíme, ale už dnes bez problému pořídíme asi 20 náhledů za vteřinu. Tam, kde jeden původní stroj zvládal 1 náhled za vteřinu, jich nový zvládá 10. A budeme ještě zrychlovat.

Je nový generátor architektonicky podobný původnímu systému?

Současná verze je řekněme o generaci dál. Celá aplikace je mnohem rozsáhlejší. Původní verze se starala jen o generování náhledů. Nová verze obstarává také jejich výdej. Jedná se o velké množství malých obrázků, které by nebylo efektivní nabízet jako statické soubory z webserveru, proto jsme tyhle dvě funkce zkombinovali dohromady.

Která jádra prohlížečů jste zvažovali?

Než jsme začali pracovat na nové verzi, udělali jsme si nový průzkum HTML enginů. Horkým kandidátem byl WebKit. To bylo ale již před časem a tehdy neběžel WebKit na Linuxu ještě tak optimálně, jak bychom chtěli. Dokázali jsme přes něj generovat náhledy, ale byl tam problém s Flashem a nedokázali jsme se dostat na DOM stránky. Právě tohle šlo totiž s IE jednoduše, u něj jsme před sejmutím náhledu ze stránky získali potřebné informace a podle nich jsme snímání náhledu uzpůsobili.

WebKit ale vypadá nadějně a pokud se bude někdy dělat třetí generace, tak bude určitě ve hře. My jsme vybrali projekt MozEmbed, což je embedovaná Mozilla. Jednoduše řečeno jádro prohlížeče (Gecko) zabalené do knihovny.

Ovšem co se týče ovladatelnosti, z enginů, které jsme zkoušeli, je na tom asi nejhůř. Má velmi slabé možnost ovládání. Můžeme nabídnout URL a sejmout náhled, ale kupříkladu zjistit rozměr stránky nebo přítomnost Flashe, JavaScriptu apod., to se z rozhraní dost dobře nedá.

Na druhou stranu Gecko řešilo naše problémy. Vytvářelo náhledy pěkné a spolehlivě i včetně Flashe. A to nakonec převážilo. Získání vlastností stránky jsme vyřešili jinak. Stránka se nyní zpracovává dvoufázově. Je tam předřazená aplikace, která stránku načte a zjistí z ní potřebné údaje.

Podle provozu, který nyní máme, bych řekl, že Mozilla funguje spolehlivě.

Náhledy tedy snímáte za stejných podmínek, jak stránky vidí uživatel, tedy včetně JavaScriptu a pluginů?

Ano, ten JavaScript je dobře poznat na mapách. Většina mapových aplikací, jako jsou Mapy.cz, to jsou jen holé stránky. Mapové dlaždice se již nahrávají JavaScriptem. Kdybychom používali jen čistý HTML engine, ve většině takových případů bychom viděli jen prázdnou stránku.

Štěpán Škrob a Martin Hassman

Určitě bychom chtěli generovat náhledy i pro URL, které vedou do světa.

Jak jste v tom případě připraveni na bezpečnostní problémy prohlížečů?

Vše běží na oddělených virtuálních serverech. Není tam přímý přístup k železu a síť je nastavená tak, aby se z nich dalo dostat jenom tam, kam se mají dostat. Takže to je určité bezpečnostní opatření pro tuhle aplikaci.

Ale i kdyby. Tím, že jsme použili Mozillu a máme řešení na Linuxu, to pro nás znamenalo extrémní zvýšení bezpečnosti proti Windows. Původní systém běžel na Windows Serveru. Když si člověk představí, že tam běžel puštěný Internet Explorer a za každý den navštívil necelých 100 tisíc náhodných stránek z internetu. Na těch strojích běžel antivirus, ale i přesto…

…se občas zavirovaly?

Antivirové programy umí spolehlivě odstranit pouze známé viry. U zcela nových virů používají heuristiky a snaží se rozpoznat podezřelé chování. I když je to velmi účinné, není to nikdy 100 %.

Ovšem, pokud bych měl první systém postavený na Internet Exploreru zhodnotit, tak abych pravdu řekl, ještě dnes jsem v šoku z toho, že dokázal běžet tak dlouhou dobu sám bez dozoru, aniž by se o něj někdo musel starat. Když tedy pominu onu údržbu přibližně jednou za měsíc.

Nedovedu si představit, že bych na svém notebooku denně otevřel desítky tisíc stránek a tak to dělal po celý měsíc bez restartu.

Setkali jste se už s tím, že by se někdo snažil „optimalizovat“ svůj web pro co nejlepší náhled v Seznamu? A třeba i podváděl, např. zobrazil generátoru náhledů místo webu obrovskou fotografii spoře oděné slečny a snažil se tak zvýšit proklikovost na svůj odkaz v Seznamu?

Ano přesně s tím jsme se setkali, ale bylo to v počátcích v roce 2005. Náhledy se objevily jako novinka a našli se i vtipálci.

Když na něco takového přijdete, co s takovým podvodníkem provedete? Vyřadíte ho z indexu?

Řešíme to individuálně, jelikož to není standardní případ. Rozhodně se smazal ten náhled.

Nedávno Seznam oznámil, že nahradí u vyhledávání ve světě Google za technologii Live Search od Microsoftu. Mezi důvody padla i možnost vkládání náhledů do výsledků od Live Search. Takže uvažujete o tom, že budete mít náhledy pro celý Web? Nebo jen nějaké vybrané stránky?

Existuje plugin do Firefoxu, který do vyhledávačů přidává náhledy. U všech odkazů zobrazuje náhled homepage. A to nám nepřipadá technologicky složité. Ve stejné kvalitě to zvládneme také. Takže určitě bychom chtěli generovat náhledy i pro URL, které vedou do světa a uvidíme, jak to půjde.

V původním generátoru byly náhledy identifikované skrze ID stránky, kterou máme v databázi. To prakticky znamenalo, že jsme nemohli mít náhled pro URL, kterou nemáme v databázi. S tím by nám screenshotování ve světě nešlo, protože to nejsou URL z naší databáze. V novém  systému je náhled identifikovaný přes URL, a proto jsme schopni vytvářet náhledy pro libovolné adresy. Není to již úzce svázané s fulltextovým vyhledávačem.

Štěpán Škrob

Zkoumali jsme situaci, která kolem mikroformátů panuje. Je to takový začarovaný kruh.

Navíc v původním systému se zasílal požadavek např. na náhled s id=3. Věděli jsme, zda jej máme nebo ne, ale nemohli jsme ovšem dělat nic dalšího. V novém systému dostaneme URL, a když náhled pro danou URL nemáme, snažíme se URL zkracovat, dokud nějaký náhled nenajdeme. V nejhorším případě to skončí u náhledu homepage toho webu. Tím bychom měli eliminovat chybějící náhledy ve vyhledávání. To se totiž ukázalo jako problém. Uživatelé na takové výsledky méně klikají.

Řekněme, že jsem redesignoval svůj web a Seznam stále zobrazuje moje původní náhledy. Jak dlouho mám čekat, nebo můžu celý proces nějak urychlit?

Záleží, o jak navštěvovaný web se jedná. U webů typu Root.cz se náhled hlavní stránky aktualizuje v řádu dvou týdnů. Pokud web není tolik navštěvovaný, je možné si jednoduše nechat nové náhledy vygenerovat. Pro všechny stránky, které vložíte do přidávacího formuláře – a je jedno, že ty stránky již vyhledávač zná – se vygenerují náhledy zhruba do čtvrt hodiny.

Vyhledávač Seznamu začal před několika týdny podporovat mikroformát geo. V čem  podpora spočívá?

Tak o mikroformátech obecně jsme již nějaký čas věděli a konkrétně mikroformát geo se nám líbil nejvíc. Pokud jej někdo použije na své stránce, objeví se u stránky ve výsledcích hledání navíc odkaz „Zobrazit na mapě“.

Zkoumali jsme situaci, která kolem mikroformátů panuje. Je to takový začarovaný kruh. Lidé ve stránkách mikroformáty moc nepoužívají, protože je vyhledávače nepodporují. A vyhledávače je nepodporují, protože mikroformáty nikdo moc nepoužívá.

Vy tedy ten kruh chcete v ČR prolomit?

Ano, aby se ten kruh dal prolomit, řekli jsme si, že uděláme podporu do našeho vyhledávače.

Uvažujete do budoucna o podpoře některých dalších mikroformátů?

Dívali jsme se i na další mikroformáty. Jsme schopni je rozpoznat na stránkách a přečíst z nich informace. Ale je otázka, jak je je jednoduše prezentovat, aby to ve výsledcích hledání bylo přínosné a nerušivé.

Plánujete používat mikroformáty i přímo na webech Seznamu? Čili sami psát HTML pomocí mikroformátů?

Zatím jsme do katalogu Firmy.cz všude doplnili mikroformát geo. Ale ty stránky obsahují i kontaktní informace, tam bychom mohli využít i mikroformát hCar­d.

Blíží se příchod IE8. Ten obsahuje vylepšené integrované vyhledávání s našeptávačem a podporou náhledů. Budete tuto novinku využívat? Uvidíme např. náhledy Seznamu přímo v našeptávači IE8?

Náhledy ve fulltextovém vyhledávání jsou poměrně velké a nejsem si jistý, zda by byl našeptávač IE8 stále tak ergonomický, kdybychom je do něj přidali. Naopak u Zboží.cz jsou fotky produktů o řád menší. Proto myslím, že na Zboží.cz toho můžeme využít.

Zabrousím trochu do historie. Vy jste současně také autorem původního fulltextu Kompas.

Ano, zrovna nedávno jsem doma náhodou našel jeho zdrojáky. (smích)

Štěpán Škrob

To byl pokud vím první český fulltextový vyhledávač.

Jsem si jistý, že přede mnou určitě v ČR fulltextové vyhledávání psala řada lidí, ale Kompas byl asi první vyhledávač na zdejším internetu, který fungoval jako websearch. Vytvářel jsem ho na vánoce 1996 a běžel od jara 1997.

V jakém jazyce byl naprogramován a jak dlouho jeho vývoj trval?

Byl napsán v céčku. Já jsem vytvářel čistě vyhledávač. A největší implementační část jsem měl hotovu během vánočních prázdnin. Robota potom vytvářel Ivo Lukačovič, a ten byl v Perlu.

Vyhledávač má vždy dvě části, které lze zcela nezávisle oddělit. Tou první je robot. Jeho funkce je dodávat stránky, které mají být zaindexované. Druhou částí je vlastní vyhledávač. Ten bere od robota HTML stránky – v té době byly předávané přes STDIN – a vytváří z nich index. Já vytvářel tu druhou část.

Vychází stávající vyhledávač Seznamu nějak z původního Kompasu nebo byl kompletně napsán znova na zelené louce?

Nemají spolu nic společného. Mezi Kompasem a současným vyhledávačem byla několik let propast, kdy Seznam používal Jyxo a další vyhledávače. Teprve po tom se začal vyvíjet nový vyhledávač.

Kompas jste vytvořil sám s Ivo Lukačovičem. Kolik lidí se podílí na vývoji fulltextu dnes?

Když spočítám celý fulltextový tým, což zahrnuje i správce databáze, administrátory a vývojáře, tak je to okolo 30 lidí dohromady.

Je dnešní vyhledávač taky napsán v céčku?

Je napsán v C++. Některé části jsou v Pythonu, ale ty hodně výkonné části jsou v C++.

Dnes je v „módě“ tzv. test driven development. Máte k vyhledávači napsány nějaké testy, abyste hlídali jeho kvalitu?

Tohle je těžká otázka. Máme automatické testy, které dokáží kontrolovat funkčnost komponent. Týká se to ale jen těch komponent, které ze vstupů generují jasné výstupy, tam to jde kontrolovat.

Jenže testovat tímhle způsobem, zda ve vyhledávání někde není chyba, by bylo myslím nedostatečné, protože výsledek vyhledávání je závislý na spoustě faktorů, které se mění – internet se pořád vyvíjí.

Máme aplikaci pro kontrolu kvality vyhledávání. To je ale jiný nástroj a nesouvisí s progresivními metodami programování. Jsou lidé, kteří hodnotí dotazy, a tato aplikace na základě ručního hodnocení měří kvalitu vyhledávání. Tím ji můžeme sledovat.

První byl Kompas, nyní máte nový vyhledávač. Plánujete někdy do budoucna vytvořit třetí generaci vyhledávače znova na zelené louce? Nebo vám v boji s konkurencí postačí zlepšovat a vyvíjet dále stávající vyhledávač?

Abychom začali psát celou aplikaci úplně znovu, k tomu by musela nastat nějaká velká pauza, podobná jako nastala mezi Kompasem a současným vyhledávačem, kdy nemělo smysl navazovat.

Budeme vyvíjet verzi, jakou máme. To ale neznamená, že neděláme i velké změny. Náš vyhledávač se skládá z řady komponent. Pokud je potřeba něco zgruntu předesignovat nebo posunout technologicky dál, tak se nějaká část vyhledávače kompletně přepíše.

Nikdy se nestává, že by bylo třeba přepsal všechny komponenty. Ale když něco dosluhuje, přepíše se např. jedna komponenta, ale vztahy na ostatní komponenty zůstanou zachované.  Jako když na autě měníte letní gumy za zimní. Nejsou třeba dvě auta, kde by jedno vždy půl roku stálo v garáži. Jde to realizovat na jednom autě.

Děkuji za rozhovor.

Otázky za Zdroják kladl Martin Hassman, fotografie pořídila Ivana Dvorská.

Rozšíří se používání mikroformátu geo v ČR?

Komentáře

Subscribe
Upozornit na
guest
127 Komentářů
Nejstarší
Nejnovější Most Voted
Inline Feedbacks
View all comments
eclipse_guru

Pekny clanek!

Anonymní

Zajimavy interview, jen bych strasne rad videl ty zdrojove kody spidera i indexera "Kompas" a dozvedel se proc se to z C cele prepsalo do C++. V nespoledni rade bych rad zjistil priblizny pocet radku stareho search enginu a noveho search enginu (kolik maji zdrojove kody radku?). Pravidelna mesicni udrzba win32 = format + kompletni reinstall, ze? :)

_xxx

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

Logik

????
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…

Yenya

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/

Messa

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 :-)

Sten

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.

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. 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

Sten

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ší.

Yenya

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

ondra.novacisko.cz

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.

finn

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…

Yenya

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

finn

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.

Yenya

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

Sten

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í?

ondra.novacisko.cz

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.

MD

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…

Yenya

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

Sten

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.

ondra.novacisko.cz

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++)

Yenya

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++.

ondra.novacisko.cz

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.

Sten

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.

Linus Torvalds

"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."

Sten

system-level

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

Sten

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ří.

Anonymní

Ja bych to zkratil. C99/GNU99 jsou nejlepsi a C++ je jejich rozsireni, ktere vetsina lidi uziva jinak, nez bylo zamysleno, tudiz produkuji mess a proto se vraceji zpet k C bez rozsireni. Otazkou je, jak bylo puvodne C++ zamysleno, protoze jsem v nem nikdy nevidel tak cisty program, jako v cistem C.

ondra.novacisko.cz

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.

Anonymní

jeste si prisadim: neobjektovy kod v C je v drtive vetsine pripadu lepsi, nez objektovy kod v C++ a kod v PHP4 je stejnym zpusobem temer vzdy lepsi, nez kod v PHP5. Objekty jsou potreba mozna jen pro ty, kteri nedokazi programovat bez nich a to tak, jako je X server s Desktop Environment a kedit potreba pro ty, co nejsou schopni uzivat SHELL / vim a umi pouze klikat mysi a volit z nabidek. :-D

Sten

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í :)

Anonymní

Ja jsem se naucil programovat objektove a venoval se tomu tolik let, az jsem dospel k tomu, ze uz ty objekty (= berlicky) vlastne ani nepotrebuji, protoze jsem zmenil svuj zpusob uvazovani nad zdrojovym kodem a teprve tim zacal psat bez objektu a lepe. Nejsem sam :)

"And limiting your project to C means that people
don't screw that up, and also means that you get a lot of programmers that
do actually understand low-level issues and don't screw things up with any
idiotic "object model" crap." Linus Torvalds

ondra.novacisko.cz

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.

Anonymní

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/

OOP nic noveho neni. Tak napr. 70. leta jazyk SmallTalk.

Namisto string::append uzivam str_append(), ktery pracuje se strukturou tak, jako to provadi STL. Obcas uziji treba i stringy z glib, protoze ta je pritomna na vetsine UNIX-like systemech. V C nejsou se stringy opravdu zadne problemy, jen zacatecnici si stezuji dokud je nenapadne zacit uzivat urcitou sadu funkci pro bezpecne programovani – vizte OpenBSD, aneb. nejbezpecnejsi system planety je cely napsan v C a ma 10 let pouze 2 zranitelnosti exploitovatelne pres remote. http://openbsd.org

Anonymní

… a ma *za* 10 let …

ondra.novacisko.cz

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).

Anonymní

Rozdil je v prehlednosti, vykonu a vrstvami pod tim. Ja pracuji s transparentni strukturou pomoci transparentnich funkci, nicmene v C++ malokdo vi, co STL vlastne provadi a je velmi slozite to vubec pochopit, protoze je to hack za hackem. K tomu pridejme pretizene operatory v kazde tride dle uvazeni konkretniho programatora rozsahleho skupinoveho projektu a jsme doma :) Sebelepsi dokumentace vysokou chybovost a spatnou portabilitu nesnizi :)

Append unicode znaku resim pres GString* g_string_append_unichar(GString *string, gunichar wc);

SmallTalk nema world-wide nasazeni? The language was first generally released as Smalltalk-80 and has been widely used since. ( http://en.wikipedia.org/wiki/Smalltalk http://www.smalltalk.org/main/ ) – napr. Xerox v nem tvoril jedno z prvnich GUI.

ORM pochazi z poloviny 70. let – http://en.wikipedia.org/wiki/Object_Role_Modeling a pak zde mame jeste podobne stare ER diagramy (prime predchudce UML).

Na zaklade uvedeneho jazyku Simula (resp. verze z 60. let) je objektum cca 50 let. 10-15 let zni spise jako reklama na Windows, kterym dle teto reklamy zacal cely pocitacovy svet, ale tim mne neoklamete :), zacatek meho sveta jsou prvni time-sharing operacni systemy, jako je UNIX.

Sten

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.

Sten

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.

Yenya

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

Sten

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ě.

Yenya

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

-Yenya

Sten

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.

Sten

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;
Anonymní

Proc pouzivas memcpy() pro praci se stringy? :) :) :)

K tomu je urcen strncpy(), nicmene po nacerpani zkusenosti programatori preferuji napr.:

#include <glib.h>
#include <stdbool.h>
#include <stdio.h>
#include <stdlib.h>

int main(void)
{
    GString *buf = g_string_new("aaaa");
    puts(buf->str);
    g_string_free(buf, true);
    return EXIT_SUCCESS;
}

v C++ to vypada pro zmenu:

#include <iostream>
#include <cstdlib>

using namespace std;

int main(void)
{
    string str("aaaa");
    cout << str << endl;
    return EXIT_SUCCESS;
}

Tyto priklady jsou prilis trivialni – nelze z nich posoudit nic. Co se treba podivat jake nechutne hacky jsou ve wrapperech C socketu pro C++? Nebo spinavosti v GTK2 -> Gtkmm ? Linus ma pravdu a vi o cem mluvi.

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.

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, 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.

Objekty usiluji o totez, je to myslenka vedouci M$ napr. k typedefum pro veskere standardni datove typy, kvuli kterym je programovani pro Windows hruza. Kdyz ji nekdo pretrpi, uz nechce zazit neco podobneho NIKDY vice a proto radeji zustava kvuli WinAPI u Windows.

A pak prisla jeste vetsi hruza – .NET :) Misto aby M$ C++ podporoval, chysta se od WinAPI *zcela* upustit a vsude mit jen .NET. Budoucnost C++ ve Windows neni svetla, budoucnost C v UNIX-like OS naopak je a vice zmrsene interfaces, nez v C++ vidime u M$ jen tak nenalezneme. Tam bych prave srovnaval kod, ne u trivialit pro praci se stringy, kde ji jeden jazyk ma built-in a druhy ji includuje z glib.

Sten

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.

Sten

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).

ondra.novacisko.cz

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.

Anonymní

***
C++ is a horrible language. It’s made more horrible by the fact that a lot
of substandard programmers use it, to the point where it’s much much
easier to generate total and utter crap with it. Quite frankly, even if
the choice of C were to do *nothing* but keep the C++ programmers out,
that in itself would be a huge reason to use C.

In other words: the choice of C is the only sane choice. I know Miles
Bader jokingly said „to piss you off“, but it’s actually true. I’ve come
to the conclusion that any programmer that would prefer the project to be
in C++ over C is likely a programmer that I really *would* prefer to piss
off, so that he doesn’t come and screw up any project I’m involved with.
————————————————————————-
Takove nesmysly jsem dlouho nevidel. Ovladam C i C++ – velke casti STL jsem narozdil od vas cetl a byl to jeden z duvodu, proc jsem zacal preferovat C. 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. Objekty zvladam jiz nejmene 10 let a narozdil od vas vim, co musi splnovat, aby se jim tak mohlo rikat. Funkce nejsou objekty. g_string_new() neni konstruktor ale funkce. g_string_free() neni destruktor, ale funkce. buf.str neni zadny proud (stream), ale struktura se clenem str, coz je pointer na znakove pole.

V C++ se pracuje se streamy, proto je MyGString pekne spinava pitomost, puts() je v C++ taktez prasarna, mel tam byt cout. Patlal co uzil chybne memcpy() samozrejme zapomnel v prvni rade, ze memcpy() slouzi k necemu jinemu, v druhe rade mel si vzpomenout na strncpy() – pokud by tomu rozumel – a terminovat retezec pres NUL char ‚‘. Chapu, ze tyto chyby se stavaji, nicmene pouze naprostym zacatecnikum. Pokrocily programator uziva kvalitni funkce pro praci se stringy… Dale uz na to nemam silu. Vyvraceni vasich nesmyslu z poslednich komentaru je z meho hlediska absurdni ztrata casu.

Jeste, ze s vami nemusim spolupracovat na tvorbe nejakeho projektu. Nebyl vyjmenovan jediny C++ projekt, ktery je tak cisty, jako C projekt a uz vubec nebyl jmenovan takovy C++ projekt, bez ktereho bych se neobesel. Dale jiz pochopitelne nehodlam reagovat dokud se nenaucite na stejne urovni oba jazyky, ne jen jeden.

27. 2. 2009 9:50 redakčně upravil Martin Hassman, důvod: Ovládejte se trochu.
ondra.novacisko.cz

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.

Sten

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í.

ondra.novacisko.cz

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.

Sten

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.

Sten

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í.

Anonymní

Uz jsem se neudrzel a musim reagovat alespon pro tentokrat.

Prave jste prokazali (Sten+Novacisko), ze nevite o programovani vubec nic. Evidentne se domnivate, ze cely svet je jako C++, coz je ciste blaznovstvi vasich zdegenrovanych mozku :) GString je struktura a hotovo. Pro vas, nedouky mam pripravenou presnou definici terminu "object", abyste vedeli co je a co neni objekt:
Object
——-
A pattern (exemplar) of a class. The class of Dog defines all possible dogs by listing the characteristics and behaviors they can have; the object Lassie is one particular dog, with particular versions of the characteristics. A Dog has fur; Lassie has brown-and-white fur.

Je politovanihodne, ze vubec nechapete OOP a cloveka, ktery jej perfektne ovlada z toho drze obvinujete. Take vidim, ze nejmene v pripade pana Novacisko jsem se vyborne trefil, skutecne je to widlickar, kteremu zacal svet se vznikem Windows pred 10-ti az 15-ti lety. A co se tyce tebe Sten, radeji se vrat kopat kanaly, spatneho kodu je jiz vice nez dostatek. :-p

ondra.novacisko.cz

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.

Anonymní

Struktura je pojmenovana sada promennych a ackoli s objektem muze mit leccos spolecneho, neni to objekt.

ondra.novacisko.cz

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.

Anonymní

Ja znam zakladni paradigma objektoveho programovani, a to rozhodne nekoreluje s vasim "objekty jsou cokoliv", proto durazne doporucuji zamest si pred vlastnim prahem. Napriklad trida presne splnuje definici objektu. Znate tuto definici? Umite si ji alespon priblizne odvodit? To bych chtel slyset. Ja ji tu mam stale pripravenou.

ondra.novacisko.cz

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

Anonymní

Nevite ktera bije :)
Objekt je instance datove struktury a chovani definovane tridou objektu.

Vy si pletete dynamickou alokaci pameti a dealokaci teto pameti v proceduralnim programovani s konstruktorem a destruktorem z objektove orientovaneho programovani a to mi jeste budete rikat, ze neumim pouzivat OOP? xD

ondra.novacisko.cz

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.

Sten

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.

Anonymní

Pro uplnost:
trida je prototyp pro objekt – analogie k odvozenemu typu v proceduralnim jazyce (ma vsuvka: odvozeny typ je treba struct GString). Za tridu muze byt take povazovana sada objektu, sdilicich urcitou strukturu a chovani (ma vsuvka: struct GString nema zadne chovani). Struktura tridy je odvozena z promennych tridy, reprezentujicich stav objektu tridy, pricemz chovani je urceno sadou metod, asociovanych s tridou.

Sten

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

Anonymní

Tvrdim snad nekde, ze trida je jedina moznost, jak objekt muze vzniknout? Netvrdim :)
Pouze uvadim, ze objekt je instance datove struktury a chovani definovane tridou objektu.

Sten

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

Anonymní

objekt je (instance datove struktury + chovani definovane tridou objektu). Uz chapes?

Sten

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

Anonymní

Objekt muze vzniknout take klonovanim existujiciho.

Sten

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.

Anonymní

Z Wikipedia jsi pouze vytrhl vety z kontextu a neuvedl ani link na uceleny clanek, navic jsem uvedl priklad jen jako napovedu, treba na tu definici prijdes diky nemu, ale spise to vypada, ze te to ani nenapadlo. xD

Sten

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

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

Anonymní

V tomto pripade je (bohuzel) konkretni zaznam na wikipedia znacne nepresny. Lepe je na tom tento http://simple.wikipedia.org/wiki/Object-oriented_programming ale i tak si musime pockat na zkvalitneni.

Uspokojive vysvetleni nabizi napr. konkurencni Britannica – http://www.britannica.com/EBchecked/topic/1383627/object-oriented-programming

JavaScript sice neni plne objektovy jazyk, ale chapu ze poukazujete na jeho pseudoobjekty. Porovnejte JS s plne objektovym Ruby:
http://libg.org/code.php?lang=js&url=http://libg.org/code/sample.js

vs

http://libg.org/code.php?lang=ruby&url=http://libg.org/code/sample.rb

Vsimnete si rozdilu (pseudoobjekty vs. skutecne objekty).

ondra.novacisko.cz

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?

Sten

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

Anonymní

Ja si nic nepletu, to vy 2 tvrdite, ze struct GString je objekt. :)

Sten

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.

Sten

Sakra, Adu vlastne vytvoril Jean Ichbiah

Anonymní

Ja uvadim definici objektu vychazejici z objektove orientovaneho paragidmatu programovani, zatimco ty, Ondra a ostatni jmenovani uvadeji tu obecnou a vseobjimajici, takze se pletes ty s Ondrou :)

Sten

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

Sten

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

Anonymní

Jenze GString je v C a tezko muzes aplikovat OOP paradigma na proceduralni jazyk.

ondra.novacisko.cz

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

Sten

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

Co třeba Google Search nebo Gmail?

Anonymní

To jsou hybridni projekty, jejichz casti jsou mj. psany i v Perl, Java, (X)HTML i JavaScript a zrovna C++ je v nich minoritni cast.

Sten

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

MD

…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

ondra.novacisko.cz

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ř :-)

Anonymní

Ono to v praxi funguje tak, že za černou krabičku často někdo nese zodpovědnost.
Whahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahaha!!!
.
.
.
Mimochodem Linux shell je objektový (protože) každá spuštěná aplikace má stdin a stdout a parametry na příkazové řádce.
Whahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahaha!!!

Co jsi, dement?

Sten

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

Anonymní

Za kod nenese nikdo odpovednost a dokonce nezaruci ani to, ze kod se k urcitemu ucelu hodi. Az ti prestane fungovat projekt kvuli novym bugum v QT, tezko to nekoho bude zajimat. Muzes provest bug-report ci zaslat patch a cekat na jeho schvaleni / neschvaleni rok, ale to je vse, co muzes.

ondra.novacisko.cz

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

Sten

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

Anonymní

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? To je ta odpovednost, kterou nikdo za svuj kod nenese. Kazdy software je bez zaruk a to vcetne Wind0z3. :-D

ondra.novacisko.cz

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

Sten

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.

ondra.novacisko.cz

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ě :-)

Anonymní

nest odpovednost znamena mj. i uhradit veskerou vzniklou skodu uzivanim tveho kodu / softwaru. Za to zadnou odpovednost neneses a pokud bys nesl, byla by to naprosta vyjimka, diky ktere bys treba jednou musel zaplatit vice, nez za cely zivot vydelas a to neni dospele, ale nedospele a stupidni.

Sten

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

Anonymní

Nest odpovednost nutne znamena nest plnou odpovednost za skodu zpusobenou svym pocinem a takove pojisteni bych chtel videt.

Sten

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áš?

ondra.novacisko.cz

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 :-)

Sten

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++.

Anonymní

Vy si oba vymyslite, jako male deti. Kdy uz dostanete rozum? :)

Nejsem pubertak ani ucitel z FI MU. Nemam k C++ averzi. Napsal jsem (i v C++) vice kodu, nez dostatek a stale aktivne vyvijim (i v teamu i samostatne). Uvedl jsem "nest plnou odpovednost za skodu zpusobenou SVYM POCINEM", ne "nest plnou odpovednost za skodu vzniklou i spolupracovniky" a co se tyce profesniho pojisteni, z nej lze odskodnit v prumeru jen do vyse 300.000Kc, jake pojisteni uhradi skodu zpusobenou vasim pocinem v plne vysi? Zadne. Navic treba u CSOB se toto nevztahuje na USA a Canada a kdyz se na to casem prijde, muze byt pozde. I proto je lepsi za skodu nerucit a nechat si zakaznika projekt nejprve otestovat a pote teprve na jeho odpovednost nasadit do produkcniho prostredi.

Sten

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.

Anonymní

Spotrebitelsky zakon se vztahuje na autorske dilo? Autorske dilo se prodava? Neni to pouze licence k uzivani?

Vubec se nedivim, ze Yenya ma podobny nazor na C++ versus C. Muze mit totiz pravdu a vice zkusenosti, nez mu prisuzujete. Mozna by i souhlasil, ze nejschopnejsi programatori preferuji C protoze kombinovat existujici objekty v ultra-high-level jazyku jako je JAVA dnes umi i podprumerny script kittie v prvnim rocniku stredni skoly, nicmene naprogramovat uzitecnou a portabilni a vykonnou knihovnu v C pro reseni novych problemu (napr. implementace nektere z casti IPv6) umi malokdo.

To je pomyslna uroven 4 az 5, ve ktere objektove orientovane programovani prestava prinaset libovolne vyraznejsi intelektualni uspokojeni a to je potreba resit. Bud prestat programovat uplne, nebo si znovu dopravat kazdodenni davku radosti prostrednictvim novych a slozitejsich, mene stereotypnich vyzev smerem blize k zelezu.

Kolik let modelujete 8 hodin denne objekty, ze vas to stale jeste bavi?

ondra.novacisko.cz

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ě.

Yenya

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

ondra.novacisko.cz

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.

Yenya

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

ondra.novacisko.cz

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í.

Sten

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é.

ondra.novacisko.cz

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?

Sten

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.

tcefUgVdQKBhKAUP

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

tcefUgVdQKBhKAUP

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

tcefUgVdQKBhKAUP

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

h

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

Solamyl

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í :-)

Anonymní

Dekuji

Adam

Mikroformát geo mě zaujal, rád bych to vyzkoušel. Koukal jsem na microformats.org, jak se má správně implementovat, ale dočetl jsem se, že více méně není žádný jednotný standard.

Rád bych tedy poprosil o radu, jak správně mf geo na stránce použít, aby jej Seznam rozpoznal. Nevíte někdo? Předem díky.

Solamyl

Zjednodušený návod jak na mikroformát geo je zde: http://fulltext.sblog.cz/2009/01/28/26

mirecekp

Spíše by mě zajímalo po jaké době to seznam začne brát v potaz? Na web obce ktery spravuji jsem to přidal ten tyden co vyšel článek na sblogu, od te doby tam byl robot několikrát ale ve výsledku odkaz na mapy nikde…

Solamyl

Jake je to url?
Stranka se musi preindexovat aby se to vzalo v potaz. Jestli tam ale robot uz byl, tak je to divne…
— stepan

janbrasna

Díky Martine a Štěpáne, dobré čtení a zajímavé informace.

Enum a statická analýza kódu

Mám jednu univerzální radu pro začínající programátorty. V učení sice neexistují rychlé zkratky, ovšem tuhle radu můžete snadno začít používat a zrychlit tak tempo učení. Tou tajemnou ingrediencí je statická analýza kódu. Ukážeme si to na příkladu enum.