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

  1. Anonym

    Zajimave, ale informace chude
    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? :)

      1. Logik

        Re: Zajimave, ale informace chude
        ????
        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…

        1. Yenya

          C++ versus C
          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/

          1. Messa

            Re: C++ versus C
            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 :-)

            1. Sten

              Re: C++ versus C

              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.

            2. Yenya

              Re: C++ versus C
              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

              1. Sten

                Re: C++ versus C

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

                1. Yenya

                  Re: C++ versus C
                  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

                  1. ondra.novacisko.cz

                    Re: C++ versus C
                    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.

              2. finn

                Re: C++ versus C
                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…

                1. Yenya

                  Re: C++ versus C

                  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

                  1. finn

                    Re: C++ versus C
                    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.

                    1. Yenya

                      Re: C++ versus C

                      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

                      1. Sten

                        Re: C++ versus C

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

                  2. ondra.novacisko.cz

                    Re: C++ versus C
                    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.

              3. MD

                Re: C++ versus C
                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…

                1. Yenya

                  Re: C++ versus C
                  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

                  1. Sten

                    Re: C++ versus C
                    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.

          2. ondra.novacisko.cz

            Re: C++ versus C
            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++)

            1. Yenya

              Re: C++ versus C

              Zkusim odpovedet na trochu vyssi urovni abstrakce:

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

              Dale: zapouzdrenim do objektu v podstate delate i lokalni „knihovny“ uvnitr sveho projektu. Opet – navrhnout spravne rozhrani je tezke, ne-li dopredu nemozne. Takze se dela to, ze si reknete „tak treba tohle bude trida/objekt, a radeji k nemu napiseme vsechny metody, ktere by nekdo mohl potrebovat. Nakonec to ale dopadne tak, ze z te tridy se ve velke vetsine pripadu pouzije akorat jeden konkretni konstruktor, jedna nebo dve metody volane presne tim stejnym zpusobem ze vsech mist kodu, a pak destruktor. V proceduralnim jazyce (nejlepe s nejakou agilni metodou programovani), byste tento kod psal az tehdy, az ho skutecne nejaka dalsi vrstva bude potrebovat.

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

              -Yenya

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

              1. ondra.novacisko.cz

                Re: C++ versus C
                Dovolte abych Vám vyvrátil nesmysly, které jste napsal… I když uznávám, že vycházejí ze zavedené praxe.

                Jenze v objektovych jazycich je jednak tezsi refaktorizace (jakmile se vam vsude vecpe jisty objektovy model, tezko se prechazi na jiny)

                Právě že objektový model je jen jeden a to ten nejzákladnější. Kdyby každý tvůrce kdejaké knihovny dodržoval to nejzákladnější, totiž aby samy objekty (třídy) vystupovali jako samostatné entity, v podstatě vám eliminuje Vámi uváděné problémy. Tohle vyplývá z toho, že valná většina programátorů neumí objekty používat, natož vytvářet.

                kdyz uz se rozhodnete pouzivat nejakou knihovnu, je temer nutnost prebrat i jeji model hlaseni chyb, alokace/dealokace objektu

                Tohle není problém C++, ale obecně všeho v C. Podívejte se ale třeba na Javu, ta má modely alokace, a hlášení chyb jednotné a dané jazykovou normou. Ale i v C++ máme tuhle možnost. Na svůj blog třeba teď dlouhou dobu chystám článek o strukturovaném výjimkové systému, mnohem lépe navrženém, než je std::exception. Jak už jsem psal, problém je právě v těch knihovnách… nejsou… Kdyby byly, všichni by je používali a uvedené problémy by se redukovali.

                Co se alokačního modelu týče, tak C++ striktně nařizuje používat new a delete. Navíc by každý objekt měl být alokovatelný i automaticky (staticky). Že si různí programátoři dobrovolně tuhle možnost omezují, to už je jiná věc. Pokud už technické, či jiné důvody toto znemožňují (továrny na objekty), přesto není problém zařídit, aby uživatel objektů nemusel přejímat alokační model. Objekty zaalokuje knihovna, o uvolnění se postará virtuální destruktor.

                . Temer nejde „pouzit jen cast z knihovny“. Toto vnimam jako podstatny rozdil proceduralniho programovani (klidne i s objektovymi rysy) a striktne objektove orientovaneho programovani.

                Opět je to to co jsem kritizoval. V současné době BOOSTu, QT, MFC, ALT a jiných projektů opravdu nejde používat jen části knihoven, vina ale neleží na C++ ani na objektech, ale na tvůrcích. Z různých důvodů prostě tvůrci potřebují, aby jejich knihovna vystupovala jako černá skříňka. Může to být neschopnost, ale i marketingový tah. Tohle ale pokud vím je i problém C obecně, neomezuje se jen na C++. Já sám se snažím objekty navrhovat buď jako samostatně fungující objekty, nebo se stromovou závislostí.

                Takze se dela to, ze si reknete „tak treba tohle bude trida/objekt, a radeji k nemu napiseme vsechny metody, ktere by nekdo mohl potrebovat. Nakonec to ale dopadne tak, ze z te tridy se ve velke vetsine pripadu pouzije akorat jeden konkretni konstruktor, jedna nebo dve metody volane presne tim stejnym zpusobem ze vsech mist kodu, a pak destruktor.

                V tom bych ale neviděl problém, mnohem větším problémem je, že do tříd se časem dopisují metody, které tam nepatří. Programátoři si objekt pletou s knihovnou. Neumí si představit jednoduché relační vztahy. Napíšou objekt obsahující 10 kontejnerů a pro každý kontejner mají samostatnou sadu funkcí na rozhraníl. A neuvědomují si, že správnější přístup je mít metody spřístupňující kontejnery se stejným rozhraním. Objekty nejsou knihovny. objekty jsou malé částice programu, atomy. Mají základní rozhraní: vznikni, zanikni, udelej kopii, zjisti stav, nastav stav, případně něco spočítej. Cokoliv většiho už není objekt, ale bastl.

                sou daleko mene portabilni.

                Tohle považuji za JPP (Jedna paní povídala). Sám vyvíjím současně na dvou platformách … Linux a Windows a s portabilitou nejsou problémy. Určité odchylky lze najít až na úrovni šablon, občas některý překladač něco pochopí jinak, ale garantuji vám, že se jedná o extrabuřty, špeky a vychytávky. Furt je situace lepší, než třeba na poli kompatibility mezi www prohlížeči. Pokud mluvíme o OS platformách, tak to je jiná záležitost, tady si musí udělat jasno linuxáři. Windows je na tom s kompatibilitou o 100% lépe.

                ale podle me je toto temer nevyhnutelny dusledek toho, ze ten program je v C++.

                Nesuďte podle linuxu, navíc zaměňujete jazyk a OS platformu. Navíc popisované problémy bývají hlavně na úrovni C. Samotné C++ vč. STL mi přijde celkem dobře kompatibilní. Programy napsané v GCC 3.3 jdou dobře přeložit i v poslední verzi GCC, pokud to jsou programy komplet v C++ a nepoužívají třeba unistd. a další hlavičkové soubory.

                1. Sten

                  Re: C++ versus C

                  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.

                2. Linus Torvalds

                  Re: C++ versus C
                  "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."

              2. Sten

                Re: C++ versus C

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

                1. Anonym

                  Re: C++ versus C
                  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.

                  1. ondra.novacisko.cz

                    Re: C++ versus C
                    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.

                  2. Anonym

                    Re: C++ versus C
                    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

                    1. Sten

                      Re: C++ versus C
                      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í :)

                      1. Anonym

                        Re: C++ versus C
                        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

                        1. ondra.novacisko.cz

                          Re: C++ versus C
                          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.

                          1. Anonym

                            Berlicky zpusobujici vice problemu, nez uzitku
                            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

                            1. ondra.novacisko.cz

                              Re: Berlicky zpusobujici vice problemu, nez uzitku
                              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).

                              1. Anonym

                                Re: Berlicky zpusobujici vice problemu, nez uzitku
                                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.

                                1. Sten

                                  Re: Berlicky zpusobujici vice problemu, nez uzitku

                                  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.

                            2. Sten

                              Re: Berlicky zpusobujici vice problemu, nez uzitku

                              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.

                              1. Yenya

                                Re: Berlicky zpusobujici vice problemu, nez uzitku
                                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

                                1. Sten

                                  Re: Berlicky zpusobujici vice problemu, nez uzitku
                                  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ě.

                                  1. Yenya

                                    Re: Berlicky zpusobujici vice problemu, nez uzitku
                                    Cili jinymi slovy – mam pravdu v tom, ze Vase argumentace tim co a proc si vybrali vyvojari KDE je v tomto pripade irelevantni.

                                    -Yenya

                                    1. Sten

                                      Re: Berlicky zpusobujici vice problemu, nez uzitku

                                      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.

                        2. Sten

                          Re: C++ versus C

                          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;
                          1. Anonym

                            Re: C++ versus C
                            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.

                            1. Sten

                              Re: C++ versus C

                              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.

                            2. Sten

                              Re: C++ versus C
                              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).

                            3. ondra.novacisko.cz

                              Re: C++ versus C
                              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.

                              1. Anonym

                                Re: C++ versus C
                                ***
                                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.
                                1. ondra.novacisko.cz

                                  Re: C++ versus C
                                  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.

                                2. Sten

                                  Re: C++ versus 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

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

                                  1. ondra.novacisko.cz

                                    Re: C++ versus C
                                    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.

                                    1. Sten

                                      Re: C++ versus C
                                      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.

                                3. Sten

                                  Re: C++ versus C

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

                                  1. Anonym

                                    Re: C++ versus C
                                    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

                                    1. ondra.novacisko.cz

                                      Re: C++ versus C
                                      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.

                                      1. Anonym

                                        Re: C++ versus C
                                        Struktura je pojmenovana sada promennych a ackoli s objektem muze mit leccos spolecneho, neni to objekt.

                                        1. ondra.novacisko.cz

                                          Re: C++ versus C
                                          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.

                                        2. Anonym

                                          Re: C++ versus C
                                          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.

                                        3. ondra.novacisko.cz

                                          Re: C++ versus C
                                          Možná znáte, ale evidentně ho neumíte používat.

                                        4. Anonym

                                          Re: C++ versus C
                                          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

                                        5. ondra.novacisko.cz

                                          Re: C++ versus C
                                          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.

                                        6. Sten

                                          Re: C++ versus C

                                          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.

                                        7. Anonym

                                          Re: C++ versus C
                                          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.

                                        8. Sten

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

                                        9. Anonym

                                          Re: C++ versus C
                                          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.

                                        10. Sten

                                          Re: C++ versus C

                                          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

                                        11. Anonym

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

                                        12. Sten

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

                                        13. Anonym

                                          Re: C++ versus C
                                          Objekt muze vzniknout take klonovanim existujiciho.

                                    2. Sten

                                      Re: C++ versus C

                                      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.

                                      1. Anonym

                                        Re: C++ versus C
                                        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

                                        1. Anonym

                                          Re: C++ versus C
                                          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).

                                        2. ondra.novacisko.cz

                                          Re: C++ versus C
                                          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?

                                        3. Sten

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

                                        4. Anonym

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

                                        5. Sten

                                          Re: C++ versus C
                                          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.

                                        6. Anonym

                                          Re: C++ versus C
                                          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 :)

                                        7. Sten

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

                                        8. Sten

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

                                        9. Anonym

                                          Re: C++ versus C
                                          Jenze GString je v C a tezko muzes aplikovat OOP paradigma na proceduralni jazyk.

                                        10. ondra.novacisko.cz

                                          Re: C++ versus C
                                          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

                                4. Sten

                                  Re: C++ versus C

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

                                  Co třeba Google Search nebo Gmail?

                                  1. Anonym

                                    Re: C++ versus C
                                    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.

                                    1. Sten

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

                            4. MD

                              Re: C++ versus C
                              …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

                              1. ondra.novacisko.cz

                                Re: C++ versus C
                                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ř :-)

                                1. Anonym

                                  Re: C++ versus C
                                  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?

                                  1. Sten

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

                                    1. Anonym

                                      Re: C++ versus C
                                      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.

                                      1. ondra.novacisko.cz

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

                                        1. Anonym

                                          Re: C++ versus C
                                          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

                                        2. Sten

                                          Re: C++ versus C

                                          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.

                                        3. ondra.novacisko.cz

                                          Re: C++ versus C
                                          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ě :-)

                                        4. Anonym

                                          Re: C++ versus C
                                          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.

                                        5. Sten

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

                                        6. Anonym

                                          Re: C++ versus C
                                          Nest odpovednost nutne znamena nest plnou odpovednost za skodu zpusobenou svym pocinem a takove pojisteni bych chtel videt.

                                        7. Sten

                                          Re: C++ versus C
                                          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áš?

                                        8. ondra.novacisko.cz

                                          Re: C++ versus C
                                          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 :-)

                                        9. Sten

                                          Re: C++ versus C
                                          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++.

                                        10. Anonym

                                          Re: C++ versus C
                                          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.

                                        11. Sten

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

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

                                        12. Anonym

                                          Re: C++ versus C
                                          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?

                                        13. ondra.novacisko.cz

                                          Re: C++ versus C
                                          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ě.

                2. Yenya

                  Re: C++ versus C

                  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

                  1. ondra.novacisko.cz

                    Re: C++ versus 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.

                    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.

                    1. Yenya

                      Re: C++ versus C

                      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

                      1. ondra.novacisko.cz

                        Re: C++ versus C
                        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í.

                      2. Sten

                        Re: C++ versus C

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

                  2. ondra.novacisko.cz

                    Re: C++ versus C
                    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?

                  3. Sten

                    Re: C++ versus C

                    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.

    1. h

      Re: Zajimave, ale informace chude
      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

    2. Solamyl

      Re: Zajimave, ale informace chude
      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í :-)

  2. Adam

    Implementace mf geo
    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.

    1. Martin HassmanAutor příspěvku

      Re: Implementace mf geo
      Standard existuje (minimálně v rozpracované fázi), jen nabízí několik variant zápisu.

      1. mirecekp

        Re: Implementace mf geo
        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…

        1. Solamyl

          Re: Implementace mf geo
          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

Napsat komentář

Tato diskuse je již příliš stará, pravděpodobně již vám nikdo neodpoví. Pokud se chcete na něco zeptat, použijte diskusní server Devel.cz

Zdroj: https://www.zdrojak.cz/?p=2950