Compiz 0.9.0 (diskuse)

[David Watzke]

Pokud se někdo bude hrnout do testování, doporučuju přečíst si v mailingu (viz link) o "known issues".

[kralyk z abclinuxu]

No tak to sem rovnou hodim, když to není dlouhý:

known issues are:
 * Miscompilation with GCC 4.5 resulting in the occasional crash on window
   closes or plugin unloads. Please compile with GCC 4.4, or see bug 1308[1]:
   for a workaround to compile with GCC 4.5
 * Some SDL applications like frozen-bubble and qemu will not display correctly.
   Please launch these applications in a window manager like metacity or kwin
   first and then switch back to compiz.

[Miloslav Ponkrác]

A postupně zastánci, že C je praktičtější a lepší, než C++ dostávají z praxe ránu za ranou. Protože C je opravdu jazyk, ve kterém dnes není důvod dělat – nenabízí žádnou výhodu.

[kralyk z abclinuxu]

...pyroman

[OndraVoves]

Duvod?

[zulu]

Čekáš snad od tak zkušeného programátora a hvězdopravce něco jako rozumný důvod?

[Miloslav Ponkrác]

Důvod je jednoduchý. Psaní projektu v C++ je několikanásobně efektivnější, tedy stojí zlomek času, tedy i peněz a nákladů.

Zároveň je projekt v C++ udržovatelnější, a lépe řiditelný. To vše zároveň obvykle dává i vyšší spolehlivost výsledného programu.

C++ také vygeneruje stejně efektivní strojový kód jako C, tudíž výsledek C++ projektu je stejný, nebo lepší jako v C.

Nenajdete jedinou objektivní výhodu, kterou by C nabídlo oproti C++, prostě neexistuje. Porovnáte-li pro a proti C a C++, na straně C jsou jen proti. Jen velmi vyjímečně v sw najdete tak jasné porovnání.

Máte-li na výběr C a C++, a můžete-li si zvolit, pak není jediný důvod pro C.

Čím větší projekt, tím nápadněji výhody C++ pro vývoj projektu vystupují do popředí. Jak se zvětšuje projekt, začíná být C větší a větší brzdou, až to obvykle někdo s nervama nevydrží a řekne: „Jdeme do C++“. Už to řeklo gcc, firebird byl přepsán do C++ zcela, stejně jako mnoho dalších projektů.

Pokud pominu malé projekty, máte většinou na výběr: dělat to v C a potřebovat 5 x tolik lidí a člověkoroků na stejné věci a 2× složitější řízení projektu, nebo v C++ s efektivnějším vývojem. Zároveň C nemá co nabídnout jako protiváhu za svou neefektivitu vývoje. Z C nevyleze rychlejší program oproti C++, ani nic co by se C dalo připsat jako klad vůči C++.

Většina středních a větších projektů si musí na vlastní kůži projít peklem C vývoje, protože z nějakého pro mně neznámého důvodu na začátku považují C za dobrou volbu. A jak se škvaří a škvaří ve vlastním sádle, po čase většinou přejdou na C++.

[OndraVoves]

Podle mne zalezi vzdy spise na programatorovi nez na jazyku... To co dokaze C++ dokaze pri trose umu i C... takze proc ho vlastne zavrhovat?

[vlastikroot]

Co dokáže C dokáže při troše umu i assembler, tak proč ho vlastně zavrhovat?

[OndraVoves]

Jenom kdyz se bojime se naucit assembler pro ruzne architektury....

[Miloslav Ponkrác]

On i assembler je obezlička nad čistým strojovým kódem.

Psát programy pro 16 architektur pak s asm nic moc.

Další věc je, že u velkých programů už assemblerista dostane pěkně na zadek. U velkého projektu musí i assemblerista formalizovat, tedy rozdělovat kód na mélé nezávislé celky, vytvořit si nějakou dohodu o předávání parametrů, calling convention a dalších. A obecně nemůže optimalizovat příliš dobře.

Mozek má omezenou kapacitu a dokáže podržet v paměti najednou jen omezené množství vazeb.

Pokud je postavne proti dobrému optimalizátoru vyššího jazyka, který je schopen optimalizovat nad velkým projektem a jeho matematické algoritmy bez problémů podrží a optimalizují nad počtem vazeb o mnoho řádů přsahující možnosti člověka, je to zcela jinde.

Mimochodem, kolik najdete lidí umějící dobře asm pro x86? Kolik asm je schopno napsat podprogram po kterém požadujete max. rychlost (což je asi jediný skutečně rozumný důvod použití asm)? Odpovím vám, byli bychom rádi, kdyby z profesionálních assembleristů, kteří se tím živí mnoho let to dokázalo řekněme 5% z nich. A to ještě by museli přepisovat kód podle použitého procesoru, na každém je to rychlostně maličko jinak.

Asm je velmi low level, zde už je neefektivita programátora tak jasná, že to pro masové programy nikdo neobhájí. C je také značně low level, a tak jako došlo k diskreditaci asm vlivem velmi dobře optimalizujících kompilátorů vyšších jazyků, se právě C historicky znemožňuje.

Mohou za to i open source projekty, které forkují ad absurdum. Počet open source projektů roste, počet kvalitních vývojářů na zeměkouli ovšem nikoli. Je čím dál méně udržitelné obhájit C – často je to otázkou života a smrti mnoha projektů. Dokud bylo lidí ochotných dělat open source zadarmo nadbytek, efektivita nehrála roli. Maximálně se pár linuxáků rozvedlo, když díky C nestíhali rodinný život, ale who cares? Dnes už ale není tolik vývojářů a projekty se musejí začít starat o svou efektivitu. A C to plně a právem schytává. Je to značně low level a značně neefektivní jazyk pro vývoj, aniž by to mělo řím obhájit.

C prostě střet s realitou nemůže bez značné porážky přežít. Mnoho lidí ho má rádo, ale když dojde na lámání chleba – buď to zabalíme, nebo změníme jazyk. Vývojáři nazbyt co by svým časem dotovali neefetivitu C jsou čím dál nedostatkovějším zbožím.

A to je celé. Proto v minulosti, nyní, i v budoucnosti budete svědky masových přechodů z C jinam. Zaplaťpámbů.

[Miloslav Ponkrác]

To co dokaze C++ dokaze pri trose umu i C... takze proc ho vlastne zavrhovat?

Samozřejmě, že dokáže, ale za jakou cenu?

Podle mne zalezi vzdy spise na programatorovi nez na jazyku...

Dejte nejlepšímu dřevorubci totálně tupou sekyrku s tím, že záleží spíš na dřevorubci, než na sekeře.

Nebo dejte dobrému dřevorubci na světě tupou sekyrku a běžnému kutilovi motorovou pilu. Uvidíme, zda dřevorubec obstojí a uhájí svou tezi, že profesionalita je vždy víc, než nástroj.

[OndraVoves]

Tak si tu sekeru pred zahajenim prace musi holt naostrit. Kdyz mame dobry navrh tak pak uz je vlastne jedno v cem piseme... zajiste je pravda ze v nejakem jazyku to trva dele. ale zase muzeme jazyky kombinovat a tim dosahnout jeste vetsi efektivity a pruznosti...

[Miloslav Ponkrác]

Přesto si ale troufám tvrdit, že sebešikovnější dřevorubec i s ostrou sekerou to prohraje vůči průměrného kutilovi s motorovkou. I ten řez motorovkou bude čistší, než osekané plochy.

Tudíž programovací jazyk velmi určuje práci, i když je programátor profesionál.

Totéž kdysi říkali hudebníci, že dobrý kytarista zahraje na sebehorší kytaru. Po mnoha trapasech se to jaksi už málokdo odvažuje tvrdit.

Kombinace jazyků naráží na cenu za interface. Může to být i hodně velká cena. Proto ten další jazyk musí efektivitu zvednout opravdu o hodně, aby se to vyplatilo. Ale často se to i vyplatí.

[Voty]

Jsem rád, že jsem díky tobě konečně prozřel, že psát programy pro jednočipy v C nemá smysl a mám honem přejít na C++. Proč jen si mi tuto _pravdu_ nezjevil dříve!

[vlastikroot]

Ale ona je to pravda. Sice je o pár instrukcí složitější zaváděcí kód, jinak se ale vyplatí psát v C++ (třeba pro ARM jednočipy určitě).

[Voty]

Bohužel u C++ je mnohem složitější i memory management, právě díky objektům a to u situací, kde paměti (zejména na zásobníku) není mnoho je dost problém.

[vlastikroot]

Ani bych neřekl, runtime podporu si člověk stejně vypne a v základu je C++ objekt skoro jak C struktura. Nedávno jsem dělal cosi s AT91SAM7 a C++ je furt něco jinýho, než na tom rozjíždět třeba luu (paměť atd). Stroják je až na detaily stejný s C, to je právě ta největší výhoda.

[Miloslav Ponkrác]

V C++ to funguje přesně tak jak to napíšete.

Objekty nejsou nic jiného z hleidka paměti, než struktury. Pokud nezbrojíte v C kvůli strukturám, pak nemůžete mít v C++ nic kvůli objektům.

Jednočipy jsou o tom, že nesnesou tolik prasáren co třeba PC. Čím slabší jednočip, tím víc to musíte mít pod kontrolou a tím více musíte na to dbát při návrhu.

Jazyk je jedno – NASA programuje jednočipy v Adě, protože C je příliš nebezpečný a benevolentní jazyk. C++ odstřelil největší benevolence C (například nedochází k automatickému přetypování void* na jiný typ pointeru), ale asi by NASA také neohromil.

Datové struktury programy (jedno jestli v asm, C, C++, Adě, Module, či jinde – ve všem tomto lze jednočip bez problémů programovat) se prostě musejí navrhnout z hlediska možností paměti.

V C++ lze new předefinovat, objekty lze alokovat staticky, dynamicky, či na zásobníku či kdekoli jinde dle programátorova přání.

[pozortucnak]

Zkoučel jse Forth?

[Miloslav Ponkrác]

Kdysi dávno. Považuji ho za základ dnešních mezijazyků, i když to asi není od sebe přímo odvozeno.

V době, kdy výkony hw byly opravdu mizerné to byl docela geniální počin.

Nehledě na to, že Forth byl vybrán jakohlavní jazyk pro země RVHP za komunistů.

Kde se to projevilo nevím, ale bylo o něm docela dost učebnic.

Ale Forth rozhodně špatný nápad není, a v kontextu použití byl geniální.

[tsLnox]

Přesto si ale troufám tvrdit, že sebešikovnější dřevorubec i s ostrou sekerou to prohraje vůči průměrného kutilovi s motorovkou. I ten řez motorovkou bude čistší, než osekané plochy.

Akorát, že průměrný kutil na sebe první uříznutý strom shodí

[Miloslav Ponkrác]

Ano, to je také pravda. Takže bude upozorněn, že se nesmí nechat zabít stromem a kam uhnout. Následně se postaví s motorvkou vedle profesionála se sekyrkou a profesionál je nezaměstnaný, bere housle po dědečkovi a jde hrát na nádraží aby měl aspoň na rohlík.

A to jen proto, že amatér měl lepší nástroj, než profesionál. A protože mu někdo nakukal, že když je profík, na nástroji, který používá nezáleží.

[pavlix]

Dejte nejlepšímu dřevorubci totálně tupou sekyrku s tím, že záleží spíš na dřevorubci, než na sekeře.

Ještě tu o autech :).

[Kerala]

Při psaní OS Windows Vista bylo použito C++.

[kralyk z abclinuxu]

Sorry, ale technet.idnes.cz opravdu není zdroj spolehlivých informací. Krom toho, ten člověk nejspíš nemluvil o jádru systému jako takovém... Pochybuju, že v jádru windows je použito hodně C++...

[JoHnY2]

Jadro je snad i v 7kach skoro cisty Ccko, ale mnozstvi C++ ve vyssich vrstvach urcite pribylo. Rek bych, ze valna cast kodu, kterej se zjevil ve Vistach a 7kach vazne bude C++ko.

[Miloslav Ponkrác]

Jádro Windows ve smyslu rosahu linuxového jádra obsahuje mnoho C++.

Windows kernel je poměrně dost rozvrstvený s tím, že ústřední část kernelu se neustále zmenšuje a vytlačuje víc a víc kódu mimo něj.

Ústřední část kernelu, která je stále menší a menší je čisté C. Všude jinde se nasazuje C++ co to jde.

Jinak zdrojáky Windows jádra jsem měl v ruce. Stejně tak jako řady standardních programů co jsou součástí Windows. C téměř nebylo vidět už v době Windows 2000.

On ten Microsoft vývoj Windows musí platit, takže efektivita vývoje je pro ně zajímavé číslo.

[kralyk z abclinuxu]

Jinak zdrojáky Windows jádra jsem měl v ruce. Stejně tak jako řady standardních programů co jsou součástí Windows. C téměř nebylo vidět už v době Windows 2000.

Neboj, vím o uniklém fragmentu zdrojáků Windows 2000

[rastos]

C je opravdu jazyk, ve kterém dnes není důvod dělat

Odporučil by si C++ aj pre písanie knižnice, ktorá má byť použiteľná z Delphi, C, javy a perlu?

[Miloslav Ponkrác]

Ano a nejednou jsem tak již udělal.

Ostatně taková knihovna se dá napsat nejenom v C a C++, ale v mnoha dalších jazycích.

Je to jen otázka toho, že když chci udělat C interface, nepotřebuji to napsat celé v C. Je možné použít mnho daleko efektivnějších jazyků. C interface přitom může zůstat zcela nezávisle na vnitřní implemetaci.

Ostatně proto se také obecné knihovny dělají ne? Oddělení interface od vnitřní implementace. Není sebemenší důvod, proč by interface nutně musel determinovat i jazyk implementace.

[R]

A prepisom do C++ sa Compiz zlepsil o 57,38%...

[pozortucnak]

Spousta jazyků se kompiluje do jazyka C, například Vala nebo Eiffel...

Jazyk C++ je pro knihovny nevhodný, vezměte si například knihovnu Qt. Jak obtížné je vytvořit binding pro Ruby, Perl, Python Mono...

[Miloslav Ponkrác]

Qt není C++ knihovna. Qt dokazuje jen to, že autoři Qt milovali ObjectiveC, které ovšem šlo do háje (oproti dnešku), ale chtěli se tím živit, takže použili C++.

Rozhodli se, že nebudou pokud možno používat nic, co není v ObjectiveC. Navíc udělali moc, aby se tomu přiblížili.

Na Qt není záměrně použito 90% C++.

To se jako pokus moc nepovedlo.

[Radek Miček]

Kompilátory C jsou jednodušší, tudíž je velká šance, že nebudou obsahovat tolik chyb jako kompilátory C++. Díky své jednoduchosti se C snáze rozšiřuje.

[Miloslav Ponkrác]

Nejsložitější je u všech kompilátorů optimalizační jednotka, čím je kompilátor lepší, tím vyšší část zabírá. Odhadem je to tak 99,9% složitosti kompilátoru a to ještě ubírám.

Optimalizační jednotka je jazykově nezávislá.

Zbytek je sranda a velmi jednoduché.

C jde do háje a také půjde. Nějak ta Vaše jednoduchost se nepotvrzuje, právě jste pod článkem, který ukazuje projekt (kolikátý už v řadě?), který v rámci zjednodušení opustil C.

[Radek Miček]

Nějak ta Vaše jednoduchost se nepotvrzuje

Stačí se podívat na drafty standardů obou jazyků.

Pro C existuje projekt CompCert, který se snaží vytvořit formálně ověřený kompilátor. U C++ by byla obdobná snaha mnohem obtížnější, protože jazyk je složitější.

[Miloslav Ponkrác]

Takový Brainfuck má daleko jednodušší popis. Určitě to bude jazyk Vašich snů.

Jinak já osobně nijak nestojím o primitivní věci typu Brainfuck a C. Ony ty primitivní věci si to vyberou právě při efektivitě vývoje.

[pavlix]

Takový Brainfuck má daleko jednodušší popis. Určitě to bude jazyk Vašich snů.

Ty lítáš vždycky z extrému do extrému, že.

Určitě to bude jazyk Vašich snů.

Cizí sny se taky dají vyčíst z hvězd?

Jinak já osobně nijak nestojím o primitivní věci typu Brainfuck a C. Ony ty primitivní věci si to vyberou právě při efektivitě vývoje.

Očividně existovaly doteď nezávisle na tvé vůli, ač jsou mezi sebou nesrovnatelné.

[pavlix]

C jde do háje a také půjde.

Tvoje víra je moc moc zajímavá, ale rozhodně ji nesdílím.

[Miloslav Ponkrác]

Nejde o to, jestli si to myslím já, nebo Vy. To je zcela irelevantní. Pravdu má vždy realita a praxe. Počkejte si.

[pavlix]

Nejde o to, jestli si to myslím já, nebo Vy. To je zcela irelevantní. Pravdu má vždy realita a praxe. Počkejte si.

Nejde o to, jestli si to myslím já, nebo Vy. To je zcela irelevantní. Pravdu má vždy realita a praxe. Počkejte si.

[Viliam Púčik]

Protože C je opravdu jazyk, ve kterém dnes není důvod dělat...

Linux kernel (najvacsi Open Source projekt) je napisany C. Qt/KDE zasa v C++. Obaja jazyky maju svoje miesto pod programatorskym slnkom.

[Miloslav Ponkrác]

Všechny jazyky mají svoje místo.

Nicméně kernel už taky začíná mít problém. Linus bohužel konzervativně převzal do kernelu všechny principy starých unix jader, které byly ušity na situace, kdy jádro mělo desítky tisíc řádků zdrojového kódu.

Hochštaplersky se vysmál mikrokernelu i C++. Dnes řeší, že by se rozvoj jádra měl zabrzdit, protože je už příliš velké.

Navíc efektivita vývoje kernelu je odstrašující. Číslo počet_člověkoroků_práce / výsledek je hodně mizerné číslo.

Linux kernel je zatím pro mnoho lidí věcí cti, ale časem se pravda ukáže. Počet vývojářů kolem Linuxu spíše klesá. Jednak kvalita vývojářů klesá obecně, jednak nadšenecké doby Linuxu mizí, a tudíž menší procento světových vývojářů se u něho drží. Navíc LInuxem se uživí jen minimum lidí, takže není důvod, proč by Linux měl alokovat většinu světových programátorů.

Časem na kernel také dojde. Jednak na C, jednak na monolit. Jen to bude ještě pár roků trvat.

Monolit kernelu nedokáže zajistit snadno spolehlivost jádra, pokud má desítky miliónu zdrojových řádek – protože na tyto situace monolit dělán není a nebyl. Nejde okecat fyzikální zákony. Dnes se to drží jen díky přetlaku vývojářů na kernelu. Ale za čas bude sranda.

[thingie]

Dnes řeší, že by se rozvoj jádra měl zabrzdit, protože je už příliš velké.

Necitováno, dezinterpretace výroků vytržených z kontextu.

Navíc efektivita vývoje kernelu je odstrašující. Číslo počet_člověkoroků_práce / výsledek je hodně mizerné číslo.

Nijak nepodloženo, nijak nedefinován výsledek. Bez srovnání s podobnými projekty bezpředmětné. Čirá spekulace.

Počet vývojářů kolem Linuxu spíše klesá.

Nijak nepodloženo.

Jednak kvalita vývojářů klesá obecně, jednak nadšenecké doby Linuxu mizí, a tudíž menší procento světových vývojářů se u něho drží.

Tohle se v podstatě ani doložit nedá.

Navíc LInuxem se uživí jen minimum lidí

Nijak nepodloženo. Není nijak určeno minimum, ani vzhledem k potřebě vývojářů ku velikosti jádra, čirá spekulace.

Časem na kernel také dojde. Jednak na C, jednak na monolit. Jen to bude ještě pár roků trvat.

Nekonkrétní předpověď, nenaznačuje charakter změny, její rozsah, ani skutečný důvod proč by k ní nakonec mělo dojít. Přijde mi naprosto dokonale nereálné, že by se v kernelu příštích pár let nestalo něco, co by se nedalo interpretovat jako určitý odklon od C či monolitického kernelu. Čili Ponkrác určitě bude mít pravdu. Akorát nic moc z toho.

Monolit kernelu nedokáže zajistit snadno spolehlivost jádra, pokud má desítky miliónu zdrojových řádek

Nic nedokáže snadno zajistit spolehlivost něčeho o desítkách miliónů řádek kódu. Takže taky žádné dechberoucí tvrzení. Mimochodem, všimněte si, že je to první případ, kdy Ponkrác ukázal nějaká fakta, a uvedl je přinejmenším trochu divně. Kernel nemá desítky miliónů řádek, ale spíš tak deset miliónů. Není to sice vysloveně nepravda, nicméně určitý volný přístup ke skutečným faktům z toho vidět je.

(Já jen tak ze srandy.)

[Miloslav Ponkrác]

Takže ani jeden argument od Vás, abych to shrnul jednoduše a stručně.

Navíc prokázána extrémní neschopnost chápat souvislosti a smysl v textu. Například pokud mluvím o tom, že na kernel jednou dojde – jedná se o BUDOUCÍ čas. Pokud následně někdo argumentuje přítomností – tedy kernel nemá DNES tolik řádek, evidentně se mu ztratil pojen času.

Doporučuji konzultaci s libovolnou učitelkou základní školy pro první stupeň. Libovolně hloupou, pojem času, přítomnosti a budoucnosti vysvětlí naprosto každý.

(Já jen tak ze srandy, nicméně pravdivě.)

[mirec]

Až tak budúci to zase nebude, kernel má problémy už dnes. Kľudne by som obetoval pár % výkonu za istotu, že blbo napísaný ovládač sieťovky nemôže len tak zhodiť jadro. Žiaľ Linux je monolit a s tým sa asi nič nenarobí. No a kernel v C++ ... nepochybne celkom zaujímavý nápad, aspoň by som možno chápal niečomu z tej hŕby kódu. Keď som v súčasnej verzii hľadal príčinu problému s mojou sieťovkou dosť som sa divil, že toto všetko ešte vôbec drží pohromade.

[kralyk z abclinuxu]

Hm, takže to co jsi řekl o dnešním jádru linuxu (ne budoucím) můžeš nějak podložit?

[thingie]

Nojo. To je populární trik. Pokud svá tvrzení umístíte do shora nijak neohraničené budoucnosti, tak v podstatě může platit cokoliv a v každém případě se to dá jenom špatně vyvrátit. Akorát to nemá žádnou hodnotu.

Každopádně si nemyslím, že by se kernel v dohledné době („pár let“) dostal na víc jak 20 miliónů, což už sice desítky miliónů jsou, ale mohli bychom se bavit v trochu konkrétnějších rozměrech, a ne ve věšteckých termínech pro „budoucnost“. I tak to předpokládá slušnou explozi velikosti kernelu (rychlejší nárůst počtu řádků než kdy jindy), což třeba vedle tvrzení o klesajícím počtu vývojářů zní divně, že. (Ano, věřím, že dokážete najít nějaký konstrukt kterým tenhle rozpor obhájíte. Je to vaše práce, no.)

A jinak k tomu, že nic co jste řekl nebylo nijak podloženo, nemáte nic? No, ani se nedivím.

[Miloslav Ponkrác]

Ale já jsem v minulosti mluvil o Linuxu naprosto konkrétně.

Rok 2015 bude zenit Linuxu. Od té doby už Linux své pozice neudrží. Podrobněji jsem to tu psal na abclinuxu.cz

V Linuxu je hodně skrytých čertů a problémů, kteří o nakonec rozežerou. Poukázat na ně rovná se, že thingie ze sebe dělá blbce. Nejdříve zkouší, jestli si všichnu jeho triku s posunem času. Záměrně se vyhýbám rozboru komentáře na který reaguji. Pak dělá blbého, že ničemu nerozumí a nic nebylo řečeno.

Konkrétně:

1) Neefektivní, tedy velmi drahý vývoj.

2) Velmi málo je standardizováno a sjednoceno.

3) Monolit linux kernelu – podrobněji jsem psal výše.

4) GPL licence – která odradí i toho, kdo později bude chtít kernel financovat, i když bude v problémech, ale zjistí, že by dostal právně omezenou věc.

Když někdo (Linus) převezme konzervativně do puntíku starý koncept, který byl vymyšlen na ještě starší podmínky, o to dříve ten koncept bude mít problémy a o to dříve se objeví jeho nepřizpůsobení potřebným podmínkám.

Zvláštní, že třeba v knize o unixu od jednoho z jeho původních tvůrců jsem se dočetl o problémech i časovaných bombách v unixu, které si plně uvědomuje.

Pokud Vám toto nepřipadá dostatečně konrétní spolu s tím co jsem detailizoval dříve, tak dále k tomu nemám co říci.

[pavlix]

Doporučuji konzultaci s libovolnou učitelkou základní školy pro první stupeň. Libovolně hloupou, pojem času, přítomnosti a budoucnosti vysvětlí naprosto každý.

Někdo ti rýpnul do tvých neargumentů a ty se můžeš vzteknout :), tak kolem sebe kopeš, doporučuju navštívit nejbližšího psychologa.

(Já jen tak ze srandy, nicméně ještě pravdivěji :))

[Miloslav Ponkrác]

Já se nevztekám. Ale pokud někdo někoho upozorňuje na volné zacházení s fakty a sám volně není schopen pochopit ani koncept přítomnosti a budoucnosti, který chápe i můj pes – tak je třeba si štournout.

[kralyk z abclinuxu]

Ale pokud někdo někoho upozorňuje na volné zacházení s fakty a sám volně není schopen pochopit ani koncept přítomnosti a budoucnosti

Ale prosimtě. Vždyť budoucnosti se celkově týkaly jen poslední 2 body ze 7 v tom tvém přinejmenším kontrovezním komentáři výše.

[pavlix]

Já se nevztekám.

Ale neříkej.

který chápe i můj pes

Tímhle přirovnáním se tu už někdo předváděl a udělal ze sebe akorát blbce, bacha, abys nedopadl stejně (btw, nebyl jsi to ty, že ne).

[Lord Vetinari]

Nemozem si pomoct tato reakcia sa mi naozaj velmi paci. :)

[Mrkva]

Ten, jehož jméno se nevyslovuje by řekl, že největší a nejznámější OS projekt je Firefox.

[kralyk z abclinuxu]

Pan Ponkrác je jako Klaus: Jeho názory jsou nepodložené, nepopulární, kontroverzní a ventiluje je ne zrovna nekonfliktní formou. Nakonec se ale ukáže, že měl pravdu

Imho naprosto zásadní událostí bude až uvedení C++0x, respektive C++1x, obecně celkově způsob, jakým půjde C++ dopředu, protože již dnes je jasné, že C++03 má dost limitací a nevýhod.

[Miloslav Ponkrác]

Moje názory jsou podložené a dokonale konkrétně vyargumentované. Viz tato diskuse.

Záměrně chodím s kůží na trh – a to je důvod, proč se trefuji i v tom, že často mám pravdu. Je v tom jednoduchý trik. Nic neskrývám, vyložím karty na stůl, všechny argumenty, vysvětlím do detailu proč si co myslím.

Pokud si myslím blbost, vždycky se najde někdo, kdo mně na ní upozorní. Protože jsem konkrétní, a protože mluvím jasně a přímo. A také proto, že je tu řada lidí, kteří touží mně „dostat“.

Jiní jsou nekonkrétní, nedokáží vysvětlit, proč mají názor ten a ten, či nechtějí schytat ránu, když se budou mýlit.

Já se nebojím, pár blbostí jsem v minulosti na abclinuxu.cz už napsal a zaslouženě za ně schytal. Tím se ale také učím a nemám problém si opravovat své názory.

Takže vlastně za mně pracuje mnoho mozků i na abclinuxu. Tím, že své názory zjevuji otevřeně a bez nějakého schovávání mi vyslovené blbosti neprojdou.

Třeba v této diskusi jsem si evidentně všimnul a záměrně jsem přímo a na rovinu napsal, že C nemá jedinou objektivní výhodu proti C++. Což si skutečně myslím. Řada lidí, včetně komentáře, na který reaguji mně zpochybňuje, ale argumenty nula. Prázdné nic. Nikdo neuvedl jediný argument, kterým by vyvrátit, či dodat jediný klad C oproti C++, který by vydržel. I to leccos vypovídá.

Nějaké zesměšňování mé osoby, to si klidně dělejte. Pokud budete chtít, klidně Vám dodám i argumenty, kterými do mně můžete šít. Například jsem se tu kdysi mýslil ohledně SIMD instrukcí. Můžete to použít a roztrhat mně tím, pokud Vám to udělá radost.

[okbob]

Argumenty proti C++:

• je to moloch,
• psát efektivní kód s STL je umění, kterému se člověk musí relativně dlouho učit,
• díky tomu, že je C++ moloch, tak lze napsat podstatně větší hrůzy než v klasickém C,
• Objektový model v C++ je zbytečně komplikovaný - vícenásobná dědičnost se v praxi nepoužívá, chybí koncept interface - Vámi zmiňovaná win používají OOP z C++ minimálně - když se podíváte na zdrojáky MFC nebo ATL, tak se jedná o silnou magii v makrech nebo šablonách.
• Pro návrh a design GUI aplikací je Objective C vhodnější

Když použiji Vaši analogii s motorovou pilou v ruce amatéra - a sekerou v ruce profesionála. Je docela možné, že amatér s motorovou pilou porazí strom rychleji - je ale velice pravděpodobné, že to udělá blbě, a že si přitom uřízne prsty a ještě někomu v okolí uřízne nohu. C++ je velice silný jazyk - ale jeho efektivní používání vyžaduje schopného programátora a řadu let praxe.

[kralyk z abclinuxu]

chybí koncept interface

No tak to je jedině dobře.

[Miloslav Ponkrác]

ad 1) Jediný, kdo to musí řešit jsou tvůrci kompilátoru. Nijak jsem si nevšiml, že vývojář musí používat 100% všeho co je v C++.

C++ je moloch proto, že je optimalizován na rychlost. Pokud by na rychlost rezignoval, mohl by být výrazně jednodušší. Žádný jednodušší jazyk, než je C++ na stejně vysoké úrovni takto efektivně rychlý není a těžko může být jednodušší.

ad 2) STL je shit a já ho téměř nepoužívám. S STL musím jedině souhlasit. Na druhé straně STL neobsahuje nic světoborného.

ad 3) OOP model je ideální. Nemastí to toho žádné interface, což je naprosto skvělé. Vícenásobná dědičnost je velmi konzistentní a homogenní princip – není třeba zavádět berličky typu inteface, nebo mixins.

Nevšiml jsem si, že bych kdekoli zmínil MFC, nebo ATL.

ad 4) ObjectiveC je na hovno, protože se nezmohl jako jazyk ani na standard. Nehledě na to, že Apple neuvolnil ani licenci základní knihovny.

Jazyk, který nemá standard, a který má právní problémy – není nic, co by bylo dobré.

ObjectiveC je jeden velký nalepovák na Céčko. Díky tomu, že volání metod rovná se nejdřív najití názvy metody v hašovací tabulce, převedení na pointer a pak zavolání, tak je to i brutálně pomalý jazyk. Ne nadarmo má Apple vzadu C a C++, jinak by to přes ObjectiveC rychlostně neutáhl.

[pozortucnak]

Pokud je Objective-C dostatečně rychlé, pro psaní GUI (Cocoa), tak to s tou rychlosti nebude až tak zlé...

Navíc Objective-C je rozhodně více objektové než C++.

Možná že C ustupuje do pozadí, ale nemyslím si, že C++ je výhra. Vetšinou když už se použije C++ tak se rozhodne nevyužívá plný potenciál tohoto jazyka, vezměte si například Mozillu...

Jen taková rejpavá otázka... slyšel jste o jazyce Smalltalk?

Mě jako výhra přijde Objective-C++ kde se dají bez problému používat C++ knihovny... programátor si může vybrat jakým stylem bude programovat - C, C++ Objective-C

[pozortucnak]

Jinak Gtk prasí C (Gobject), Qt prasí C++ (Qobject, MOC)...

Přitom tu je osvědčené objektové GUI - NeXTSTEP/OpenStep...

[kralyk z abclinuxu]

vícenásobná dědičnost se v praxi nepoužívá, chybí koncept interface

Nechci oživovat flejm, jen bych se chtěl ještě k tomuhle vyjádřit víc než původně...
Vzhledem k tomu, že koncept interface je de-facto podmnožinou vícenásobné dědičnosti a virtuálních členů, tak ten citovaný výrok si vlastně přotiřečí - jestliže se nepoužívá vícenásobná dědičnost, nepoužívá se ani interface. Imho se ale v praxi používá oboje.

Krom toho, vytvořit interface v C++ jde (akorát to tam není explicitně pojmenované) - prostě vytvoříš třídu, která má samé pure virtual členy.
Přístup v C++ je ve stylu "udělej si sám". V jazycích jako Java nebo C# máš prostě natvrdo koncept interface a není jiná volba - vícenásobná dědičnost jinak než přes interface není možná. V C++ se můžeš rozhodnout - můžeš jednak zvolit koncept interface, jakož i jiný přístup, případně je libovolně kombinovat.

[kralyk z abclinuxu]

Moje názory jsou podložené

Hmm, neviděl jsem v této diskusi od tebe jedinný odkaz na nějaký zdroj.

[Miloslav Ponkrác]

Pokud je pro Vás důkazem zdroj, pak jste neuvěřitelně snadno manipulavatelný člověk.

[kralyk z abclinuxu]

Nic takového jsem neřekl.
Kdybych ale měl brát vážně výroky typu:
"C++ je tohle a tohle, C je tohle a tohle, jádro linuxu je tohle a tohle, windows jsou tohle a tohle, v roce 2015 to bude tak a tak..."
Bez jakéhokoli podložení, tak bych byl ještě mnohem manipulovatelnější.

[pavlix]

Pokud je pro Vás důkazem zdroj, pak jste neuvěřitelně snadno manipulavatelný člověk.

Pokud by za důkaz (nebo aspoň argument) přijal plané kecy, to by byl teprv snadno manipulovatelný. Takže já naopak oceňuji, že tak manipulovatelný není.

[pavlix]

Moje názory jsou podložené a dokonale konkrétně vyargumentované.

A tvoje ego napuchlé jak hulánova prostata.

[Miloslav Ponkrác]

Někomu jsem šlápl na paleček a jeho ego.

[pavlix]

Někomu jsem šlápl na paleček a jeho ego.

To musí být dobrá schíza, šlapat si po vlastním :).

Mimochodem, převracet svoje problémy na ostatní, to můžeš zkusit. Ale otázka je, kdo je tady na tom tak špatně, aby ti to sežral.

Naopak mi přijde, že tím ukazuješ úroveň svých argumentačních schopností.

[Miloslav Ponkrác]

Jinak IMHO (subjektivní názor) C++0x není pro C++ až tak zásadní. Obsahuje pár užitečných věcí a ruší pár nesmyslných limitací vzniklých drobnostmi při návrhu C++.

C++ dopředu zase tolik nepůjde. Není ani moc důvod.

Mně vyhovuje plus mínus C++ tak jak je dnes. Pár věcí by se dalo vylepšit, ale nic kritického.

Co si ale myslím je, že by bylo dobré sjednotit C a C++ do jednoho standardu. Zatím jsou ty dva jazyky od sebe ještě ne tak daleko aby to nebylo možné – a spoustu problémů by to vyřešilo.

Ale v zásadě to není nutné, protože C tak jako tak bude ustupovat C++.

De facto dnes zájem o C je vlastně relikt z doby, kdy Linux začal psát jádro v C a kdy unix vše programoval v C. Protože Linux posvětil C jako „guru jazyk“, řada lidí ho chce. Ale třeba ve Windows už C mizí i z kernelu a téměř nikdo už spoustu let v C nepíše.

Aby se nelichotivá neefektivita C zakryla, rozmohlo se na Linuxu velké množství interpretovaných jazyků. Prostě s C už to nešlo. Na jiných platformách nikdy taková potřeba tak rozdílného množství a velké plejády různých jazyků nebyla, protože se nepreferovalo C. A tudíž nebylo třeba až tak moc zakrývat a obcházet neefektivitu hlavního prostředku.

Záměrně šiju do C proto, aby Ti, kdo něco budou pro open source dělat si konečně k tomu vybrali efektivní jazyk. Nemusí to být C++, pokud jim nevoní. Ať to napíší třeba v Javě, Pythonu, LISPu, či co je jejich srdci milé. Záměrně tu ostře píšu, protože open source scénu brzdí „assembler like jazyk“ C. Nepotřebuji se tu přesvědčovat o své pravdě, já bych nyní jazyk C dobrovolně nepoužil. A to přesto, že jsem ho používal mnoho let a měl jsem ho moc rád. Kdyby se podařilo vykopat C z většiny projektů, celý open source by šel prudce nahoru.

[okbob]

Asi jste výjimka, ale ještě jsem nepotkal programátora, který by byl v C++ stejně produktivní, jako v Perlu, Pythonu, .. Nevím, které jiné platformy myslíte - jestli windows, tak tam rozhodně C++ není dominantním jazykem - gró aplikací je napsáno v Visual Basicu. Lidí, kteří jsou schopni psát C++ aplikace v MS Win bych v ČR možná spočítal na prstech jedné ruky.

[Miloslav Ponkrác]

Ona je důležitá ta definice slova „produktivní“.

Ve Windows je C++ rozhodně dominantním jazykem, byť dnes už začíná být C#.

Jinak já naepropaguji C++, já jen se snažím lidem říct, že mají zahodit C. Je úplně jedno, třeba přechodem na ten Python. Já jsme tu porovnával C s C++.

[pavlix]

Jinak já naepropaguji C++, já jen se snažím lidem říct, že mají zahodit C. Je úplně jedno, třeba přechodem na ten Python. Já jsme tu porovnával C s C++.

Kolik lidí jsi konvertoval? :)

[jas]

Len tak zbezne, nech nemusim komentovat na viacerych miestach.

Na zaciatok by som rad pridal varovanie, ze v podstate proti c++ ako jazyku nemam nic. Ked som sa ho ucil, tak sa mi na nom dokonca par veci celkom pacilo.

Je celkom zrejme, ze C bude stracat na popularite. Vypoctoveho vykonu zacina byt miestami prebytok a nejake dvojnasobne spomalenie, uz nic moc neznamena (do tohto spomalenia sa zmesti prekvapivo vela skutocne high-level jazykov, samozrejme nie dynamicky typovanych :) ). Ovsem obavam sa,ze skor oproti pythonu a pod. nez c++.

Chceli ste dovody preco nepouzivat c++:

1. Interface pre ine jazyky. Mal som za ulohu vytvorit wrapper pre c++ kod do nejakeho vyssieho jazyka. Vzhladom na moje preferencie som planoval haskell. S C haskell funguje perfektne, to sa uz neda povedat o c++. Podpora velmi, velmi slaba. Samozrejme slo by to spravit cez iny jazyk (i.e. spravit wrapper napr. do C a potom wrapper do haskellu), ale na co sa kopat zbytocne do zadku? Nakoniec som skoncil u pythonu a aj tak to nebola ziadna slava (podpora tiez nebola dokonala, napr. problem s "nested classes"). Keby to bolo v C, ide to v podstate out of box.

2. Stale je prilis malo high-level. Tu to vidim ako problem hlavne kvoli snahe o spatnu kompatibilitu s C. To ten jazyk proste nehorazne brzdi.

3. Tendencie ludi nepouzivat v c++ pointere za kazdu cenu. Videl som uz nejeden c++ kod, kde radsej pouzili niekolko (> 5) abstraktnych tried namiesto toho aby nejak jednoducho pouzili pointere. Jasne, da sa to napisat aj v c++ cez pointere, ale z nejakeho dovodu to ludia nerobia.

4. Za vrchol vtipnosti povazujem tento kod:

struct nocase_compare: public std::binary_function<unsigned char, unsigned char, bool>
{
  bool operator() (const unsigned char& c1, const unsigned char& c2) const
  { return tolower(c1) < tolower(c2); };
};

Keby som ten kod nevidel na vlastne oci pouzity, tak neuverim. Len pripominam, ze tamto je kompletna deklaracia tej strukturo-funkcie. Je mi celkom jasne, co to robi, ovsem dekodovat to oproti klasickej deklaracii funkcie zaberie o dost viac casu.

5. Tendencia zahadzovat klasicky imperativny pristup za kazdu cenu. Netusim preco sa to robi, ale robi sa to (prikladom moze byt snad symbian c++, viem, ze je to modifikacia c++, ale aj tak...). Keby sa c++ pouzivalo v style: Toto by bolo zbytocne zvrhle/zdlhave v C, hodme tam c++, tak nic nepoviem. Preto mi napr. nevadi c++ v gcc (zatial).

6. Konecne sa mozme dostat k debugovaniu. Opravoval som uz C a c++ po mnohych ludoch preto viem, ze v oboch jazykoch sa da pisat celkom zvrhlo (aj ked c++ je v tomto skutocny prebornik). Vacsina c++ hlasok ma tendenciu byt, povedzme, ukecana (pouzival som ho jedine s gcc, netusim ako je to v inych kompilatoroch). Pri C si clovek precita hlasku (par sekund) a opravi kod (tiez zvacsa celkom kratko). Pri c++ si radsej z tej hlasky len pozrie riadok (asi rovnako dlho ako precitat hlasku pri C, lebo najst cislo riadku v tej zmati znakov skutocne nie je moc vtipne) a opravi kod (omnoho dlhsie lebo, ked do toho ide, netusi, kde je problem, aj ked casto kratsie nez citat celu tu hlasku).

7. Boost. Skutocne vtipna kniznica. Pri kompilacii tej kniznice som sa prvy krat v zivote bal, ze mi dojde aj swap (swap som zapinal prave kvoli tomu boostu, inak ho moc nepotrebujem).

Mozme sa dostat k sekera-motorova pila problem. Tento problem nie je ani zdaleka tak jednoduchy ako sa moze zdat.
Jeden priklad: Aj ja (v rubani amater) dokazem casto rozstiepit drevo na polovicu jednym uderom. A to sa samozrejme nebavime len o pidipolienkach. S motorovou pilou by len jej nastartovanie trvalo dlhsie nez rozrubanie toho polena/casti stromu. A to sa bavime o slabej sekere. Plus samozrejme pri motorovej pile su tu celkom velke rezijne naklady a celkom vysoka vstupna cena.
Proste C ma casto svoje opodstatnenie. Na celkom vela problemov je proste z nejakych dovodov vhodne. So zvysujucim vykonom bude zrejme stracat na vyznamnosti (ovsem tu bude stracat aj c++). Samozrejme, na niektore projekty su ine jazyky omnoho vhodnejsie uz teraz (prave spominane gui).

[bubla]

Hle, zase další troubové, kterým nestojí za to pořádně se naučit autotools... Ale stejně je ten jejich software převážně pro BFU, takže to by tou úrovní tak zhruba odpovídalo.

[kralyk z abclinuxu]

Proč je podle tebe někdo, komu nestojí za to naučit se autotools, trouba? Imho je to spíš rozumný člověk.

[bubla]

Autotools ty věci dělají nejlíp. Například pokud si chce člověk ověřit, že v systému existuje určitý header, tak autotools se "zeptají" přímo kompilátoru, v případě knihoven linkeru atd., takže je to sice pomalé, ale zato při správném použití 100% spolehlivé.

Nehledě na to, že jsou self-contained (nepotřebujete autotools k buildu projektu, který autotools používá) a posloupnost
./configure --help
# teď si čtu help a koumám, jaký build si mám poručit
./configure blablabla
make check -j3
sudo make install
je pro koncového uživatele zdaleka nejpohodlnější způsob, jak k obrazu svému buildovat projekt

[thingie]

Já si to teda raději napíšu v cmake-gui, než abych procházel tisíc parametrů v configure a opisoval to do řádku.

[pavlix]

Nedávno jsem potřeboval jeden projekt dostat do autotools, pravda, půl dne jsem učením strávil. Ale dostal jsem docela slušný výsledek a tisíc parametrů jsem k tomu nepotřeboval.

Parametry v configure jsem v jednoduchém projektu v podstatě nepoužil, ale vypsání těch důležitých do řádky je podle mě daleko jednodušší než si na to otevírat nějaké gui (funguje to stejně i ve skriptech a při generování balíčků). Na cmake-gui se rád podívám.

[thingie]

Největší nevýhoda CMake samozřejmě je, že potřebujete CMake Autotools vám vyrobí šílené skripty a potřebujete jenom shell a make…

Na tom GUI je dobré, že když uděláte nějakou chybu, snadno a rychle to napravíte. Spouštět configure několikrát a pokaždé opravovat co je na řádku je docela nuda, a ani slušná znalost readline to neudělá nějak zajímavým.

[pavlix]

Největší nevýhoda CMake samozřejmě je, že potřebujete CMake Autotools vám vyrobí šílené skripty a potřebujete jenom shell a make…

To chápu a řekl bych, že několik málo build-závislostí bych byl ochotný v systému tolerovat, pokud budou command-line only a půjdou kompilovat prakticky na čemkoliv. Nezkoumal jsem, ale předpokládám, že to cmake splňuje (a že cmake-gui je nepovinná nadstavba).

Na druhou stranu mít jednu základní sadu nástrojů pro bootstrapping je výhoda.

Nepochybuju, že půjde gui používat (doprogramovat) i pro autotools.

Na tom GUI je dobré, že když uděláte nějakou chybu, snadno a rychle to napravíte.

Tuhle výhodu asi nedocením... podle mě to není zase tak složité ani command-line.

Navíc jsem celkem spokojeným uživatelem mnoha příkazových UI, takže je nepovažuju za nevýhodné. Možná by pomohlo na to vyladit bash-completion.

[major]

Doufám, že na cmake přejde většina projektů a autotools zemřou bídnou smrtí!

[chrono]

Čím je cmake pre ne-KDE projekty lepšie ako autotools? Samotné skripty, ktoré hľadajú knižnice... sú v cmake minimálne tak isto hnusné ako tie v autotools a ani syntax súboru CMakeLists.txt nie je, podľa mňa, výrazne lepšia (a skript pre NASM tam ešte stále nie je :) ).

[kralyk z abclinuxu]

Čím je cmake pre ne-KDE projekty lepšie ako autotools?

Tohle evokuje dojem, že cmake je dobrý pro KDE, či nějak pro KDE uzpůsobený. Není to tak, CMake má s KDE společné jen to, že je v KDE použit, a je stejně (ne)vhodný pro jiné projekty jako pro KDE.

I kdyby opravdu nebyl CMake přehlednější/použitelnější než Autotools, pořád je ještě výrazně rychlejší

[biolog]

A proč by se měli učit autotools? Vždyť ta věc dělá jen to, co stejně vyplývá ze zdrojáků a programátor autoconfu nic lepšího říct nedovede.

Software, který dovedou používat i BFU, musí být fakt dobrý - protože BFU nedovedou programům plnit náhodné požadavky. (Pokud myslíte kvalitu kódu aplikace, tak ta nezávisí na tom, jestli je pro BFU nebo ne.)

[robotics]

Ten compiz je stejně na nic, když se kvůli hrám musí vypínat.

[tsLnox]

Ten compiz je stejně na nic, když se kvůli hrám musí vypínat.

Ty hry jsou stejně na nic, když se kvůli nim musí Compiz vypínat :-P

Ne, to byl joke :) Já Compiz kdysi použil jenom, abych se podíval, že i v tomhle dokáže GNU/Linux překonat MS Windows (myslím tím v hezkých efektech), a pak jsem ho vypnul. Co taky s tím, je to sice hezký, ale k bežný práci k nepoužití... :)

[pozortucnak]

Compiz obshuje i pár užitečný vlastností, jako třeba tiling...

[vlastikroot]

Compiz je stejně podivná věc, přijde mi, že až moc kompletní WM. Třeba xcompmgr se mi líbí mnohem víc, protože mužu použít svůj oblíbenej WM a přitom mám compositing. Škoda, že není compiz víc podobnej xcompmgr, pak by byl třeba víc použitelnej. Ale je možný, že přepisem do C++ se umožní takovýhle upravy si udělat, compiz ořezat.

[Rovano]

V některých případech na něm běžící hra je dokonce rychlejší, než kdyby jela v např. v Metacity. Aspoň to prokázaly některé Phoronix testy. Z těch her si pamatuju jen Tremulous :)