Společnost Amazon miliardáře Jeffa Bezose vypustila na oběžnou dráhu první várku družic svého projektu Kuiper, který má z vesmíru poskytovat vysokorychlostní internetové připojení po celém světě a snažit se konkurovat nyní dominantnímu Starlinku nejbohatšího muže planety Elona Muska.
Poslední aktualizací začal model GPT-4o uživatelům příliš podlézat. OpenAI jej tak vrátila k předchozí verzi.
Google Chrome 136 byl prohlášen za stabilní. Nejnovější stabilní verze 136.0.7103.59 přináší řadu novinek z hlediska uživatelů i vývojářů. Podrobný přehled v poznámkách k vydání. Opraveno bylo 8 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Homebrew (Wikipedie), správce balíčků pro macOS a od verze 2.0.0 také pro Linux, byl vydán ve verzi 4.5.0. Na stránce Homebrew Formulae lze procházet seznamem balíčků. K dispozici jsou také různé statistiky.
Byl vydán Mozilla Firefox 138.0. Přehled novinek v poznámkách k vydání a poznámkách k vydání pro vývojáře. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 138 je již k dispozici také na Flathubu a Snapcraftu.
Šestnáctý ročník ne-konference jOpenSpace se koná 3. – 5. října 2025 v Hotelu Antoň v Telči. Pro účast je potřeba vyplnit registrační formulář. Ne-konference neznamená, že se organizátorům nechce připravovat program, ale naopak dává prostor všem pozvaným, aby si program sami složili z toho nejzajímavějšího, čím se v poslední době zabývají nebo co je oslovilo. Obsah, který vytvářejí všichni účastníci, se skládá z desetiminutových
… více »Richard Stallman přednáší ve středu 7. května od 16:30 na Technické univerzitě v Liberci o vlivu technologií na svobodu. Přednáška je určená jak odborné tak laické veřejnosti.
Jean-Baptiste Mardelle se v příspěvku na blogu rozepsal o novinkám v nejnovější verzi 25.04.0 editoru videa Kdenlive (Wikipedie). Ke stažení také na Flathubu.
TmuxAI (GitHub) je AI asistent pro práci v terminálu. Vyžaduje účet na OpenRouter.
Autor tohoto blogu, Mgr. Šimon Tóth v současné době působí jako výzkumný pracovník ve společnosti Cesnet z.s.p.o. a dlouhodobě vede pokročilá a speciální cvičení jazyků C a C++ na Fakultě informatiky MU.
linkedin
Tento zápisek je takový menší průzkum. Při svém hledání práce jsem narazil na poměrně zvláštní přístup k Céčku a C++. V ČR (přinejmenším v Brně) se v podstatě nedá narazit na místo pro C++ programátora. V podstatě ze všeho se vyklubala práce v čistém Céčku (ideálně ještě v Céčku alá Microsoft). Pokud se vám chce budu rád když trochu rozvedete svoje odpovědi v diskuzi.
Tiskni
Sdílej:
24.6.2009 22:35
Michal Fecko | skóre: 31
| blog: Poznámkový blog
Inac C89 (ako hobby)
Jinak u toho objektoveho programovani je napriklad ultra opruz v Cecku delat simulaci konstruktoru a destruktoru.
Ale jinak reference, sablony, silnejsi typova kontrola, mnohem lepe definovane pretypovani... porad nic?Zrovna tohle je spíš věc vkusu – pro každou z těchto věcí najdete i spoustu argumentů, proč ji v jazyce nemít
Například reference značně snižují čitelnost kódu: když voláte funkci a předáváte jí argument, najednou při pohledu na volání nepoznáte, jestli funkce ten argument může modifikovat. Šablony jsou pěkné při triviálním použití, cokoliv složitějšího už je podobně strašná houština, jako když na generika používáte v Céčku preprocesor. Silnější typová kontrola často překáží (nekonečné zástupy přetypování výsledků mallocu), a někdy zase není dost silná, aby zabránila míchání integerů s floaty tam, kde před tím chcete ochránit.
Ano, v Céčku spousta věcí citelně chybí. Jen se nemohu ubránit dojmu, že C++ je přidává jedním z těch méně šťastných způsobů.
Nenaučíme se radši všichni Perl6?
najednou při pohledu na volání nepoznáte, jestli funkce ten argument může modifikovatIMHO by to funkce neměla dělat - má přece návratovou hodnotu. Pokud je potřeba z nějakého extra důvodu mít parametr typu "out" tak by to mělo být jasně vidět při čtení daného kódu (např. názvem parametru nebo proměnné, komentářem, ...).
nekonečné zástupy přetypování výsledků mallocuTohle by mělo řešit použití new
Nenaučíme se radši všichni Perl6?Ten už jsme se naučili, ale jaksi ho nemůžeme pořádně ozkoušet.
IMHO by to funkce neměla dělat - má přece návratovou hodnotu.No ano, nemela. Stejne jako by nemela pouzivat vstup, vystup, zapisovat do globalnich promennych...
25.6.2009 12:50
Jardík | skóre: 40
| blog: jarda_bloguje
No ano, nemela. Stejne jako by nemela pouzivat vstup, vystup, zapisovat do globalnich promennych...Proč? Ve všech systémech/kompilátorech podporujících vícevláknové aplikace existuje něco jako thread local storage, takže když píšete vícevláknové aplikace, použijete to. V opačném případě je to úplně jedno. A proč by neměla používat vstup/výstup, to nechápu. Systém si sám ohlídá zapisování do stejného descriptoru (sice tam bude guláš smíchanej z několika vláken, ale nerozbije se to).
A proč by neměla používat vstup/výstup, to nechápu.
IMO Martin spíš myslel omezit počet míst v programu, kde se vstup a výstup provádí a tato místa odlišit od těch, kde se neprovádí.
A vubec, pochybuji, ze mistni "padousi" kdy poradne vyzkouseli poradny funkcionalni jazyk. Pak by rozhodne nemohli rikat, ze v C++/C#/Jave se pise rychle :o)V C++/C#/Javě se rychle přemýšlí a pomalu píše, v Haskellu se rychle píše a pomalu přemýšlí
Kde se funkcionalni jazyky realne nasazuji? (nerypu, jsem zvedavy)
Bohužel se zatím moc nenasazují. Například něco o komerčním užití Haskellu najdete v Haskell Communities and Activities Report (kapitola 7), ale bohužel toho moc není.
A proč myslíte, že se nenasazují? Ono to není samo sebou. Možná je to tím, že vlastnosti funkcionálních jazyků nejsou pro praxi vždy až tak výhodné vlastnosti. Navíc si funkcionální jazyky velmi libují v trikování a různých chytácích – což také není dobrá vlastnost pro praktické nasazení.
Navíc si funkcionální jazyky velmi libují v trikování a různých chytácích...
To bych neřekl. Funkcionální jazyky si libují ve znovuvyužívání již napsaných funkcí.
Python se naopak snaží od funkcionálního hodně distancovat. Jeho autor prohlašoval, že chce z Pythonu vše funkcionálního vyhodit s tím, že Python není LISP. V posledních letech se vedly tvrdé boje s autorem Pythonu o to, že by měl řadu věcí v Pythonu 3 nechat.
Problém je ten, že v praxi nemůžete nasadit jazyk, který by v pohodě sloužil pro luštění hádanek. A tím bohužel Haskell v určitých aspektech je, stejně tak jako řada funkcionálních jazyků. Můžu si myslet o Haskellu cokoli, včetně toho, že je nejlepší, ale v praxi je potřeba jednoduchý, nezáludný jazyk, který necvičí matematickou obratnost programátora. Nasazení takového jazyka masově by při kvalitě (a kvalita je tu odvozená z platů, které takový programátor dostane) skončilo katastrofou.
Ostatně klidně střelím v tomto i do C++. Největší překážkou nasazení C++ nejsou jeho vlastnosti, ale jeho složitost. Pro mnoho lidí je C++ za hranicemi jejich možností, či možností, které se dají naučit za pár týdnů. Začátečník se naučí Céčko velmi rychle, ono je primitivní, ale C++ se dobře za měsíc nenaučíte ani náhodou od nuly.
Funkcionální jazyky si libují v trikování, ale praxe si v tom nelibuje. Proto se v praxi uplatňují blbé jazyky.
Problém je ten, že v praxi nemůžete nasadit jazyk, který by v pohodě sloužil pro luštění hádanek. A tím bohužel Haskell v určitých aspektech je, stejně tak jako řada funkcionálních jazyků. Můžu si myslet o Haskellu cokoli, včetně toho, že je nejlepší, ale v praxi je potřeba jednoduchý, nezáludný jazyk, který necvičí matematickou obratnost programátora.tak to reknete rovnou, ze haskellu nebo jinym funkcionalnim jazykum nerozumite...
Napsal jsem ve funkcionálních jazycích možná víc, než Vy. Ale do praxe v týmu bych ho nenasadil. Jen v případě vyjímečných okolností.
Ach jo. Řeknu to přímo: Jestliže je někdo debil a začíná argumentovat funkcionálními jazyky jako argumenty proč C ano a proč C++ ne, a ani po několikátém upozornění mezi řádky, že je totálně mimo, pak je třeba naznačit tvrději. To ohledně včerejší diskuse.
Jinak já proti funkcionálním jazykům nic nemám, líbí se mi v mnoha ohledech. Ale vím, že pro většinu lidí jsou těžké, a tudíž v praxi nepoužitelné.
Jsou lidi, kteří prostě rádi střelí, že když tvrdím, že jsou pro většinu lidí těžké, že já jsem je nepochopil. Aniž by reflektoval, že stejnou municím střílím i do C++.
Prostě pokud někdo argumentuje konkrétně, klidně i tím, že se mu jazyk líbí, já to beru a nemám problém. I mě se některé věci a jazyky líbí a nelíbí, a občas použiji i věci, které jsou méně vhodné jen proto, že k nim mám kladnějších vztah.
Pokud ale někdo jenom střílí bez argumentů, pak střílím také.
Já jen napsal, že od funkcionálních jazyků se ustupuje – a je to trend posledních dvaceti let, co to sleduji. Funkcionální jazyky rozvíjí především teoretici, kteří „potřebují“ dynamický dispatch a dynamické konstruktory, abych parafrázoval tuhle debatu, a považují tyto vlastnosti za praxi tak klíčové, že si myslí, že hned zítra díky tomu se budou používat funkcionální jazyky. Pro praxi jsou přesložité. V praxi je hlavně potřeba jazyk, který zvládnout lidí s běžným IQ a řadu věcí napíší zcela rutinně při vaření kafe. Jazyk, který bude maximálně udržovatelný a bude vychytávat maximum chyb a bude v něm rozumně levný vývoj. A zbytek je o módě a o preferencích.
Jazyk C++ také ustupuje ze své slávy, protože je zkrátka složitý a řada lidí v něm naseká chyby. C je zase jednoduchý jazyk, ale je v něm mnohem dražší vývoj, než v C++, a je méně udržovatelný. Upřímně ustupují proto oba jazyky.
Právě proto je trend Javy, C#, a kdyby byl standardní a profesionální přístup od autorů, tak i Pythonu a Ruby. Proto se dřív začal používat Perl, či PHP, protože to proti C/C++/bash rutinám byl velký skok vpřed.
Kdysi byl velmi rozšířený Smalltalk. To je rozumně jednoduchý jazyk, který minimálně trikuje a je lidmi velmi dobře zvládnutelný. Jenže zase není bezpečný.
Před mnoha lety byla obrovská éra LISPu. Dnes tu máme relikty LISPu jako skriptovací jazyky v mnoha starších programech, například emacs, nebo autocad.
Jinak já proti funkcionálním jazykům nic nemám, líbí se mi v mnoha ohledech. Ale vím, že pro většinu lidí jsou těžké, a tudíž v praxi nepoužitelné.
To určitě neplatí pro všechny funkcionální jazyky. Například Haskell je velice jednoduchý jazyk a pro jeho naučení na průměrné úrovni stačí středoškolské znalosti z matematiky.
Bohužel řada lidí nemá ani ty znalosti. To je realita.
Já jen zkopíruji větu z WIkipedie: "The subtle syntax and sophisticated type system of Haskell are a double edged sword — highly appreciated by experienced programmers but also a source of frustration among beginners, since the generality of Haskell often leads to cryptic error messages."
Už to stačí pro vytěsnění z praxe. Je to pro lidi co rádi experimentují.
To ale samozřejmě neznamená, že se používají všude tam, kde tyto kapacity nepostačují. Své místo na světě tyto jazyky mají, možná dokonce, že pokud bude v budoucnu kladen větší důraz na paralelní programování (dosavadní vývoj by to mohl naznačovat), tak jejich podíl docela stoupne, ale majoritní podíl nebudou mít nikdy, to je jasná věc.
Kde se funkcionalni jazyky realne nasazuji? (nerypu, jsem zvedavy)
Treba takovy erlang ma pomerne mnoho realnych nasazeni, od telefonich ustreden az po chat na facebooku. A to odhlizim od open source produktu jako je CouchDB, Rabbit MQ nebo treba ejabberd
Eiffell jsem zkoušel. Tam je problém, že v zásadě pro dobrou práci musíte koupit vývojové prostředí, i když něco bylo i open source. Zatímco pro řadu jazyků je zdarma kvalitní prostředí.
Jinak jsem měl u Eiffellu pocit, že je to zbytnělý design by contract. A některé věci byly dost nezvyklé. Například u tříd je možné v potomcích nejenom přidávat data a metody, ale také ubírat. Dokonce je možné třeba metodu, která je v předkovi veřejná (public) v potomkovi přeznačit jako skrytou (private). Kompilátor pak detekuje, jestli potomek změnil něco významného a zabraňuje pak takové třídě vystupovat na místech, kde používáte polymorfismus. Je to pak sranda, když potomek je typově předkem, ale nejde ho použít na místě předka.
Osobně mi Eiffel přišel jako trochu zmatený. S ne zcela domyšlenou syntaxí a rozhodně to není konzistentní jazyk, i když Meyer ho chtěl takový udělat.
Ale je to zajímavý jazyk, těžko v něm uděláte chybu, protože mám pocit, že víc píšete testy, než programujete. Hezké na něm je, že dokáže kompilovat do Java bytekódu i do .NET bytekódu.
A také mám pocit, že v případě Eiffelu si každý kompilátor jde svou vlastní cestou.
Osobně bych v případě kritických aplikacích sáhl spíše po Adě.
Je to pak sranda, když potomek je typově předkem, ale nejde ho použít na místě předka.Ono totiž třída a typ objektu jsou dvě různé věci, i když to lidi spojují. Takže typ instance potomka nemusí být nutně podtypem typu instance předka. Což teda samo o sobě není tak hrozné, horší je, že Eiffel umožňuje kovariantní změnu typu parametru metody v podtypu, což je u jazyka zaměřeného na statickou typovou bezpečnost bezskrupulózní zvrhlost
Souhlasím.
Nicméně si myslím, že Eiffel nebyl dobře trefen. Je to prostě jazyk typu: „Hurá, uděláme bezpečnost“.
Taky se v diskusi o C versus C++ můžeme kromě funkcionálních jazyků bavit třeba o výchově dětí, stavbě dálnic, nebo koncovkách v šachu. Bude to naprosto stejně off topic jako v případě funkcionálních jazyků.
Jinak ve funkcionálních jazycích jsem toho napsal dost. Dříve byly totiž daleko daleko rozšířenější, než dnes. A celkem se nedivím, že se jejich použití v praxi snížilo. Ony jsou totiž ohromně mocné, elegantní, dokáží všechno na světě, jenom jsou velmi často nepraktické. A tím bych tak nějak se vrátil k tématu článku.
Taky se v diskusi o C versus C++ můžeme kromě funkcionálních jazyků bavit třeba o výchově dětí, stavbě dálnic, nebo koncovkách v šachu. Bude to naprosto stejně off topic jako v případě funkcionálních jazyků.To sice ano, ale to se obcas v diskuzich stava, ze pres pribuzna temata se dostaneme dal. Byva to mnohem horsi. A vubec, otazka "proc radsi pouzivam neco jineho nez C++ na takove to domaci programovani" je docela on-topic.
To ano, ale třeba normálně se nergumentuje tím, že je dobré nasadit Céčko, protože třeba Kasparov vyhrál svůj 40. zápas.
A argumentovat funkcionálními jazyky v argumentech C versus C++ jako argumentem pro Céčko mi přijde poněkud – no s IQ želvy. A jistý člověk přímo, či nepřímo takto idiotsky argumentoval mnohokrát, a zrovna měl křestní jméno Martin.
Jinak samozřejmě bavit se dá o čemkoli, nic proti.
A argumentovat funkcionálními jazyky v argumentech C versus C++ jako argumentem pro Céčko mi přijde poněkud – no s IQ želvy. A jistý člověk přímo, či nepřímo takto idiotsky argumentoval mnohokrát, a zrovna měl křestní jméno Martin.Jojo, my Martinove jsme tvorove lini a hloupi. A Martinove z Matfyzu maji IQ hrocha natuty. :o)
25.6.2009 12:45
Jardík | skóre: 40
| blog: jarda_bloguje
IMHO by to funkce neměla dělat - má přece návratovou hodnotu. Pokud je potřeba z nějakého extra důvodu mít parametr typu "out" tak by to mělo být jasně vidět při čtení daného kódu (např. názvem parametru nebo proměnné, komentářem, ...).Je dobré to sice okomentovat, ale kvůli tomuto účelu existuje slovíčko "const", díky kterému jednoznačně vidíte, že se nic modifikovat nebude (i když je tu const_cast<>, ale v céčku taky můžete násilně přetypovat const na ne-const).
V tomhle se mi líbí řešení Microsoftu v jejich headerech.
#define __in
#define __out
#define __inout
void funkce(int __in a, int& __out b);
25.6.2009 13:09
Jardík | skóre: 40
| blog: jarda_bloguje
#undef __in #undef __out #undef __inout
IMHO by to funkce neměla dělat - má přece návratovou hodnotu.Opravdu by to funkce neměla dělat. Jenže nedělat si to může dovolit jen v jazycích, ve kterých není problém vrátit z funkce více hodnot.
Zkuste srovnat:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
(a,b,c) = f(1,2,3); g(a+b*c);
s něčím jako:
struct f_ret_value x=f(1,2,3); g(x.a+x.b*x.c);
Tohle by mělo řešit použití newBohužel neřeší: často si potřebujete vybrat, jakým způsobem paměť alokovat: na zásobníku (alloca), na haldě (malloc), v nějakém memory poolu, ve sdílené paměti atd.
for Muj_Typ'Storage_Pool use Muj_Alokator;
... a pak už se nestarám.
Integeru je jedno, jestli je naalokovaný mallocem nebo zrovna bydlí v lokální proměnné na zásobníku – pořád je to stejný integer.Já bych to zrovna nemíchal s proměnnými které se definují lokálně. Technicky tam sice nějaký alokátor je, ale je zabudovaný v jazyce a programátor žádné ...alloc nevolá, prostě proměnnou zadefinuje a hotovo. Pokud se bavíme o proměnných, které musí programátor explicitně vytvořit, tak tam samozřejmě typ proměnné hraje přinejmenším roli toho, že podle něj poznáte, kolik se té paměti bude alokovat. Od toho už je jen krůček k tomu, že typ neurčuje jen kolik paměti ale taky kde. Tudíž jak tu někdo správně poznamenal, pokud chci alokovat integer v poolu jednom, tak mám jeden typ proměnné a pokud chci alokovat integer v poolu druhém, mám druhý typ. Z tohoto pohledu už pak není jedno kde ten integer bydlí. Ono to vlastně není jedno nikdy, protože nemůžu volat nad tou proměnnou pool1_alloc a pak pool2_free. V céčku si to musím hlídat sám, tady to za mě ohlídá počítač. Ostatně pro céčko je integer téměř všechno
Alokátory souvisí s životností proto, že mnohé z nich se starají o automatickou dealokaci objektů.To ano, samozřejmě to takto souvisí. Ale oponuju tvrzení že "alokátor je vlastnost toho jakou mají mít data životnost".
Já bych to zrovna nemíchal s proměnnými které se definují lokálně.Naopak: tento příklad, i když se zde o alokaci programátor explicitně nestará, jasně ukazuje, že typ a způsob alokace jsou ortogonální. Jistě, můžete různé druhy alokace specifikovat pomocí typů, ale je to značně umělé. Představte si, že v programu používáte 10 různých poolů a v každém z nich mohou bydlet objekty 10 různých typů. Opravdu chcete jen kvůli tomu definovat 100 typů? A vzdát se možnosti napsat funkci, která naalokuje nějaký systém objektů v poolu, který dostane jako parametr?
Ono to vlastně není jedno nikdy, protože nemůžu volat nad tou proměnnou pool1_alloc a pak pool2_free.Pokud si ovšem vše nenavrhnete tak, že paměť uvolňuje destruktor, který ví o tom, kde byl objekt naalokován. Nebo pokud si nenavrhnete takové pooly, aby si uvolňovací funkce sama uměla zjistit, o který pool se jedná (tak se chová třeba alokátor v linuxovém jádru).
V opravdovem C++ by se tohle resilo sablonou abstrakni tovarny. Dokonce si myslim ze knihovna Loki neco takoveho obsahuje. Je tam tovarna, ktera ma jako parametry -mimo jine - jmeno tridy kterou ma vytvaret a jmeno tridy ktera alokuje pamet. Jinak doporucuji knizku "Modern C++ Design" tak je hezky ukazano kam az se da v C++ zajit a taky je z toho patrne co vsechno v C++ chybi.
PS: tuple jako l-value se da v C++ implementovat prave pomoci referenci, viz knihovna boost.
V opravdovem C++ by se tohle resilo sablonou abstrakni tovarny.Jinými slovy na chycení vrabce si už ani nepořizujeme kanón, nýbrž rovnou celou zbrojovku
27.6.2009 23:58
Marek Bernát | skóre: 17
| blog: Arcadia
Ale len abstraktnú, takže je to v poriadku
Naopak: tento příklad, i když se zde o alokaci programátor explicitně nestará, jasně ukazuje, že typ a způsob alokace jsou ortogonální.Já myslím, že ne tak docela. Už jen proto, že proměnná mimo stack (nebo globální haldu) je pointr a tudíž vlastně jiný typ. Samozřejmě jde pointrem ukázat i na auto-proměnnou na stacku, ale už ne přes "new".
Jistě, můžete různé druhy alokace specifikovat pomocí typů, ale je to značně umělé. Představte si, že v programu používáte 10 různých poolů a v každém z nich mohou bydlet objekty 10 různých typů. Opravdu chcete jen kvůli tomu definovat 100 typů? A vzdát se možnosti napsat funkci, která naalokuje nějaký systém objektů v poolu, který dostane jako parametr?Není to umělé, protože v základu počítač (překladač) kromě typu o té proměnné nic neví a pokud mu chci říct, jak se starat o alokaci, tak musí být u typu proměnné uveden i způsob alokace. Samozřejmě je to otázka terminologie, můžeme si (typ,způsob alokace) nazvat třeba "flerb" a bavit se o flerbech. Ad 100 typů: ve výsledku tam asi budou, ale psát se s tím nemusíme, pokud máme dědění a/nebo generika. Otázka taky je jestli člověk opravdu využije všech 100.
Pokud si ovšem vše nenavrhnete tak, že paměť uvolňuje destruktor, který ví o tom, kde byl objekt naalokován. Nebo pokud si nenavrhnete takové pooly, aby si uvolňovací funkce sama uměla zjistit, o který pool se jedná (tak se chová třeba alokátor v linuxovém jádru).To je taky možnost. Pak se o to nestará počítač, ale já, ale opět to lze řešit klasickým new, kterému přibude ten jeden parametr navíc. V tom případě lze udělat i to, že si tuhle informaci schovám (nebo později nějak dovodím) a případný delete bude uvolňovat ze stejného poolu. Při vší úctě k tomu, co hackeři na jádru vykouzlili si myslím, že v něm svým způsobem postavili pomník Céčku a že kdyby všechy ty vychytávky raději zakomponovali do překladače nějakého nového jazyka, tak by ten kód byl přehlednější.
Není to umělé, protože v základu počítač (překladač) kromě typu o té proměnné nic neví a pokud mu chci říct, jak se starat o alokaci, tak musí být u typu proměnné uveden i způsob alokace.Existence mallocu jasně ukazuje, že nemusí
24.6.2009 22:55
Luk | skóre: 47
| blog: Kacířské myšlenky
| Kutná Hora
objektove se da programovat i v tom CSpíše bych řekl "objekty se dají naprasit i do C", což mi moc jako výhoda nepřijde (viz GTK+).
Btw. co si predstavujes pod objekty?V podstatě balíčky dat s dobře definovaným interfacem. Zkrátka chci, aby jazyk uměl popsat "chci nad těmito daty provést tuto operaci" a při vzniku objektu (nebo i později) bylo možné říci, co toto zaříkadlo má provést. Ideálně tak obecně, aby záležitosti typu dědičnosti nemusely být zadrátované do jazyka, nýbrž definované v knihovnách a v případě potřeby ovlivnitelné.
Takze v principu neco jako Javascript.Spíš něco jako Perl6 s jeho systémem tříd a metatříd.
Coz je ale uuuuplne mimo to o cem se tady bavime.Ale kdeže. Pouze to podtrhuje jeden z nejsilnějších argumentů proti C++, totiž: "Když už si chci vybrat objektový jazyk, vyberu si takový, který má pořádné objekty a ne pouze parodii na ně."
26.6.2009 23:07
Marek Bernát | skóre: 17
| blog: Arcadia
To ale nie je vôbec silný argument, vzhľadom k tomu, že závisí na kope predpokladov (potrebujem poriadny objektový jazyk & nezaujíma ma nič iné). V tom prípade si skutočne môžete vybrať smalltalk, alebo čo chcete. Ale ak Vás zaujíma rýchlosť kódu a ďalšie veci a stačia Vám objekty na úrovni C++ (čo rozhodne nie je paródia, ako ste si to dovolili označiť, je to veľmi dobre použiteľné na riešenie kopy problémov. Samozrejme, nie je to čistý objektový jazyk, to je však zasa len akademická hodnota), tak to nie je žiadny argument.
* C++ is designed to be a statically typed, general-purpose language that is as efficient and portable as C
* C++ is designed to directly and comprehensively support multiple programming styles (procedural programming, data abstraction, object-oriented programming, and generic programming)
* C++ is designed to give the programmer choice, even if this makes it possible for the programmer to choose incorrectly
* C++ is designed to be as compatible with C as possible, therefore providing a smooth transition from C
* C++ avoids features that are platform specific or not general purpose
* C++ does not incur overhead for features that are not used (the "zero-overhead principle")
* C++ is designed to function without a sophisticated programming environment
že jednak to nezpomalování není pravdaporad dokola stejna pisnicka
a když začnu používat smart pointery a podobné vymožnosti, tak už to není pravda vůbecNapriklad scoped ukazatele maji zcela nulovy overhead (ok, overhead na urovni jednoho testu pri zaniku). V Cecku vetsinou v situacich kde se pouzivaji chytre ukazatele skonci programator s nejakym GC nebo memory poolem, pripadne necha aplikaci leakovat.
že je často lepší vybrat si jazyk, který toho nabízí ještě daleko víc (byť za cenu výkonu)Proc ne, mame tady zajimave jazyky. Vetsinou jsou dost pomale, ale pokud to v danem pripade nevadi, neni co resit. Osobne dynamicke jazyky moc nemusim, protoze napsat korektni kod v dynamickem jazyku je fakt na masli (promenna muze neexistovat, nemusi byt inicializovana, nekdy vznikne jenom tim ze otestuji zda je inicializovana).
Ta celkova koncepce mi prijde pomerne jasna:To jsou cíle, ne koncepce.
V Cecku vetsinou v situacich kde se pouzivaji chytre ukazatele skonci programator s nejakym GC nebo memory poolem,Jistě. A to jsou v mnoha situacích daleko přiměřenější prostředky, mimo jiné proto, že je daleko jednodušší je použít správně (např. se u cyklických struktur nemusíte starat o to, které ukazatale mají být reference-countované a které ne). Navíc pooly mají oproti počítaným pointerům řádově nižší režii.
To jsou cíle, ne koncepce.Mne to do vyznamu slova koncepce docela sedi.
Jistě. A to jsou v mnoha situacích daleko přiměřenější prostředky, mimo jiné proto, že je daleko jednodušší je použít správně (např. se u cyklických struktur nemusíte starat o to, které ukazatale mají být reference-countované a které ne). Navíc pooly mají oproti počítaným pointerům řádově nižší režii.Pokud je to prijemnejsi/vykonnejsi prostredek, tak samozrejme nemam duvod ho nepouzit v C++.
Nahraďte si tedy v mém příspěvku slovo "koncepce" nějakým jiným vhodným, které bude vystihovat vnitřní strukturu jazyka a nikoliv jeho vnější chování, a zkuste odpovědět znovu
27.6.2009 18:58
Marek Bernát | skóre: 17
| blog: Arcadia
Čo keby ste sa radšej Vy naučili používať svoj materský jazyk a nenechávali na ostatných, aby sa Vás snažili pochopiť? To slovo si nájdite sám. Ak také neexistuje, tak pravdepodobne ani netušíte, čo chcete vlastne povedať? Čo je to chovanie jazyka? Jazyk je malé dieťa, aby sa nejak choval? Naučte sa prosím vyjadrovať. A neberte toto ako ad hominem. Keď sa diskutujúci nie je schopný vyjadriť, tak diskusia postráda zmysel...
27.6.2009 19:52
Marek Bernát | skóre: 17
| blog: Arcadia
A čo je to teda chovanie jazyka? Nemusíme to nechávať tak -- ak je to tak dobre definované, ako hovoríte, tak mi napíšte tú definíciu a sme vybavení.
Takže sa bavíme o štandarde daného jazyka. Fajn, to ste mali povedať hneď.
S tým haskellom ste zrovna poriadne vedľa. Je pravda, že ciele toho jazyka sú minimalistické (byť čisto funkcionálny), ale vnútorná štruktúra až tak jednoduchá nie je. Už krátke nahliadnutie do štandardu (predpokladám H98) to potrvdí. Ak ste chceli vybrať skutočne minimalistický jazyk, tak potom C, alebo Scheme (piatu revíziu pre konkrétnosť), kde sú tie štandardy skutočne na 50 strán.
Je pravda, že C++ je nesúrodá zmes kadečoho a veľkosť jeho štandardu ďaleko presahuje štandardy oných minimalistických jazykov, ničmenej, opäť, zas a znova, je to len akademická hodnota. Fakt, že (ako sám uznávate) sa podarilo splniť ciele, ktoré si vývojári predsavzali a možnosť nasadenia jazyka na riešenie veľkého množstva reálnych problémov, je úplne postačujúce.
Ako dobré prirovnanie C vs. C++ môže slúžiť Scheme vs. Common Lisp. CL má tiež ráďovo 10x väčší štandard ako Scheme a tiež je v ňom kadečo možné, na druhej strane to však umožňuje oveľa väčšiu praktickú použiteľnosť jazyka. Skrátka, veľkosť štandardu jazyka nie je veľký argument proti jazyku samotnému.
Takže sa bavíme o štandarde daného jazyka.Nikoliv. Nemluvím o kompletní specifikaci jazyka, nýbrž o jeho základech. Specifikace je obvykle značně rozsáhlá, protože obsahuje popis hromady knihovních funkcí a všelijakého syntaktického pozlátka. To je přesně příklad Haskellu. Základy velmi jednoduché, ale syntaxe značně rozkošatělá. Složitost jazyka (nebo ještě spíš jeho přímočarost) není pouze akademická hodnota. Velmi na ní záleží, jak jsou programy v daném jazyce zapsané srozumitelné.
27.6.2009 20:13
Marek Bernát | skóre: 17
| blog: Arcadia
Netuším, čo sú to základy jazyka. Opäť Vás musím poprosiť o definíciu.
To je úplná hlúposť. To jak sú programy zrozumiteľné záleží takmer výlučne na programátorovi. Nie je problém v haskelli písať úplne kryptický kód a v C++ kód úplne bez problému čitateľný a naopak. Predsa obfuskovať sa dá v každom jazyku. Jasné, že ak jazyk umožňuje programátorovi lepšie a konzistentne sa vyjadrovať bez písania kopy balastu (viď javovské public static void main...), tak je to výhoda, ničmenej, nie je to žiadny extrémny problém (o čom svedčia milióny opíc, ktoré v jave píšu...).
Netuším, čo sú to základy jazyka. Opäť Vás musím poprosiť o definíciu.Formální definici Vám bohužel nepovím (to je žel podobně marné jako ptát se lingvisty na formální definici slovesa). Ona se obecně celá tato debata týká spíš toho, jak na sebe navzájem působí lidé a programovací jazyky, než nějakých dobře definovaných vlastností jazyků samotných.
To jak sú programy zrozumiteľné záleží takmer výlučne na programátorovi.Záleží, ale nikoliv výlučně. Tak elegantní a snadno pochopitelný program, jako můžete napsat v Haskellu, prostě ve Fortranu nebo Cobolu nenapíšete, ať se budete snažit sebevíc.
27.6.2009 21:08
Marek Bernát | skóre: 17
| blog: Arcadia
Nepotrebujem formálnu definíciu. Stačí mi akákoľvek rozumná. Skutočne ťažko sa nám bude komunikovať, keď sa nedohodneme na tom, čo si predstavujeme pod pojmami, ktoré používame. Je pravda, že zadefinovať sloveso nie je jednoduché, ale dá sa opísať: slovo, ktoré popisuje akciu/dej/proces, ktorá sa nejakému objektu deje, prípadne ktorú jeden objekt koná na inom objekte. Dá sa to ľubovoľne viac formalizovať ak zavedieme formálnu gramatiku a sloveso bude nejaký neterminálny symbol s danou sémantikou a pod., ak máte záujem Ďalej sa dajú uviesť príklady slovies a z toho to človek tiež môže pochopiť. V každom prípade, kde je snaha, tam je cesta. Vy sa však zatiaľ stále vyhýbate tomu, aby ste špecifikovali, o čom vlastne hovoríte
Záleží od druhu programu. Je pravda, že quicksort sa tak elegantne ako v haskelli nedá napísať takmer nikde (okrem funkcionálnych jazykov), lenže nie každý problém je vhodné riešiť funkcionálne a v tom momente Váš argument padá. Ak potrebujete písať imperatívne, tak v Haskelli musíte používať všelijaké netriviálne obkľuky (monády napríklad), aby ste mohli napísať to, čo v imperatívnom jazyku dosiahnete na pár riadkoch. Takže by som nepaušalizoval.
Nepotrebujem formálnu definíciu. Stačí mi akákoľvek rozumná.Však jsem se o ni již pokusil (viz níže).
Ak potrebujete písať imperatívne,A kdy to doopravdy potřebujete?
27.6.2009 21:37
Marek Bernát | skóre: 17
| blog: Arcadia
Súhlasím. Haskell je pekný funkcionálny jazyk vhodný na riešenie veľa problémov, zďaleka však nie na všetky. To isté sa dá povedať o väčšine jazykov
Perl 6 som nikdy nevidel. Len chvíľu som robil v Perle 5. A to teda bol bordel, oproti nemu sa môže schovať určite aj C++, ktoré tu zatracujete. Predpokladám, že Perl 6 taký bordel už nie je a má rozumnejšiu myšlienku?
Predpokladám, že Perl 6 taký bordel už nie je a má rozumnejšiu myšlienku?Naštěstí ano.
27.6.2009 21:33
Marek Bernát | skóre: 17
| blog: Arcadia
Napríklad keď pracujete s grafmi, už som o tom písal nižšie. Bežné prístupy v Haskelli len emulujú imperatívne programovanie, pričom sa často zhoršuje zložitosť. Ono je to samozrejme relikt toho, že už 50 rokov sa nad grafmi nijak inak neuvažuje (prehľadávam graf -> mám množinu vrcholov, ktoré si musím pamätať je myšlienkový proces šitý na globálne pole a side efekty), takmer nikto neuvažuje nad grafom ako induktívnou štruktúrou, na ktorú by sa dal pustiť map alebo foldr, čo by bol prístup hodný funkcionálneho jazyka (viď článok, ktorý som linkoval niekde dole v diskusii). Samozrejme to chce čas, možno o 50 rokov to bude inde (myslím aplikáciá funkcionálneho programovania tam, kde sa bežne používa imperatívne), ale v dnešnej dobe by som grafové algoritmy rozhodne v Haskelli neprogramoval. A nielen tie, existuje proste kopa algoritmov v teoretickej informatike, ktoré sú imperatívne orientované a nie je zrejmé ako ich prepísať do funkcionálnej podoby pri zachovaní zložitosti.
Jen se Vám to hodí (a mně u grafových algoritmů také, byť mi přijde, že se mnohé z nich dají i funkcionálně napsat obstojně hezky).
Netuším, čo sú to základy jazyka.Já si to představuji jako to, co zbude, když sloupnete všechno, co se uvnitř jazyka dá nadefinovat (knihovny, prvky jazyka, které by v knihovně být mohly, ale z nějakého důvodu nejsou), a seškrábete syntaktické pozlátko (součásti jazyka, které se dají přímočaře rozepsat na jiné, elementárnější). V Céčku tedy bezpečně mimo základy leží
printf nebo operátor ->, a bezpečně uvnitř jsou základní typy a mechanismus sequencing pointů.
27.6.2009 21:25
Marek Bernát | skóre: 17
| blog: Arcadia
To je ale veľmi ošemetná záležitosť, napríklad už kvôli tomu, že Haskell Vám bez monádov nebude fungovať. Alebo chcete povedať, že aj monády sú len pozlátko? A keď pridáme ku základom monády (obyčajný objekt štandardnej knižnice), tak čo ešte máme pridať? Čiže vaša definícia základov jazyka je veľmi problematická. Mne osobne to pripadá, že existujú len nejaké subjektívne dojmy o tom, čo si predstavujeme, že jazyk zhruba je (jeho základná myšlienka).
To je ale veľmi ošemetná záležitosť, napríklad už kvôli tomu, že Haskell Vám bez monádov nebude fungovať.Jak to? Nebude mi fungovat jeho I/O knihovna.
Čiže vaša definícia základov jazyka je veľmi problematická.Však jsem také nic za definici základů nevydával, pouze jsem se snažil přiblížit, co tím myslím, a přiznával, že přesně to nadefinovat neumím
27.6.2009 23:35
Marek Bernát | skóre: 17
| blog: Arcadia
Tak teraz si nie som celkom istý, či Vám rozumiem. Nie je snáď entry point do programu "main :: IO()"? Ako bude bez IO knižnice fungovať akýkoľvek program? A ďalej, načo je jazyk, ktorý nie je schopný ani len robiť IO? Zrovna to IO by som určite do základov zahrnul.
Pravda
Nie je snáď entry point do programu "main :: IO()"?Jak vypadá vstupní bod programu, bývá obvykle určeno standardní knihovnou, ne jazykem samotným. Podobně v Céčku existence nějakého mainu a formát jeho parametrů je čistě knihovní záležitost (například linuxový kernel je napsaný v Céčku a žádný main nemá).
Ako bude bez IO knižnice fungovať akýkoľvek program?To velmi záleží na tom, čemu říkáte program
Za program můžete považovat i funkci, která dostane nějakou datovou strukturu a vrátí jinou datovou strukturu.
27.6.2009 23:56
Marek Bernát | skóre: 17
| blog: Arcadia
Fajn, beriem. Lenže takto je to definované práve kvôli tomu, aby aj I/O bolo navonok funkcionálne. Ak zoberiete monády, haskell prestane byť čisto funkcionálnym jazykom, čo zmení základnú myšlienku celého jazyka, práve kvôli práci so vstupom a výstupom. Non?
No, to je otázka, musím sa zamyslieť V každom prípade však hovorím program tomu, čo bežne píšu milióny ľudí, totiž nejaká aplikácia, ktorá komunikuje so svetom. Keby sa v haskelli nedali takéto aplikácie tvoriť, tak by bolo skutočne chabé
Keby sa v haskelli nedali takéto aplikácie tvoriť, tak by bolo skutočne chabéChabe, to jo. Ale je to velice zajimavy napad! Udelat vystup tak neprijemne (jeden jazyk na I/O a druhy na pocitani), aby se uzivatel snazil nejdriv si veci napocitat a pak vypsat cely kontext, az kdyz je to opravdu potreba. Mozna, ze je to docela rozumna programatorska praktika (i kdyz, casto tohle vubec nepripada v uvahu). Priznam se, monady se mi taky na Haskellu moc nelibi. Chapu jejich funkci a jejich rekneme nutnost, ale stejne cekam na "neco lepsiho", ne matematicky, ale hlavne z vyukoveho a uzivatelskeho pohledu.
28.6.2009 09:37
Marek Bernát | skóre: 17
| blog: Arcadia
Tak z ostatných funkcionálnych jazykov je zrejmé, že spraviť poriadne IO nie je nič triviálne. Väčšina jazykov proste pripúšťa side efekty. A tiež je jasné, že vymyslieť koncept, ktorý je schopný zahrnúť IO do funkcionálneho štýlu programovania, nie je nič jednoduché; nízkoúrovňovo je I/O program zobrazenie medzi dvoma nekonečnými streamami, alebo kontinuáciami, alebo ako chcete a v literatúre vidno, že keď z toho chcete dostať niečo rozumné (ako mať možnosť skladať I/O príkazy sekvenčne), tak dospejete k realizácii kategorických monádov. Ale kto vie, možno je aj iná cesta...
Jen dodám, že některé funkcionální jazyky (Clean a Mercury) používají tzv. Uniqueness type
ale vnútorná štruktúra až tak jednoduchá nie je. Už krátke nahliadnutie do štandardu (predpokladám H98) to potrvdí.
Osobně si to nemyslím. IMO Haskell 98 patří k těm jednodušším jazykům.
Ještě dodám: mám na mysli jednodušší na pochopení (ne délka standardu).
27.6.2009 20:22
Marek Bernát | skóre: 17
| blog: Arcadia
To s tým priamo súvisí. Jazyk je popísaný štandardom. Ak ho chcete poriadne pochopiť, skôr či neskôr budete musieť ten štandard kompletne vstrebať.
S tím souhlasím. Nicméně Haskell 98 je docela konzistentní a mnoho věcí se tam chová tak, jak očekávám, tudíž není problém je pochopit (a zapamatovat si je).
27.6.2009 20:46
Marek Bernát | skóre: 17
| blog: Arcadia
Nehovoril som o prečítaní štandardu (hoci to je zjavne najlepšia možnosť, ak ten jazyk chceš pochopiť kompletne a byť si istý, že ti nič neuniklo), ale o jeho vstrebaní, akoukoľvek cestou -- pomocou tutoriálov, kníh a programovania napríklad. Samozrejme za predpokladu, že implementácia spĺňa štandard, takže to, s čím prichádzaš do kontaktu bude skutočne štandard -- ostatne, týmto spôsobom si tie štandardy vstrebal zrejme ty sám a je to najbežnejší spôsob.
Ničmenej, nemyslím si, že je možné sa napríklad C++ naučiť poriadne bez toho, aby človek videl štandard, alebo aspoň knihu ten štandard reflektujúcu. Na to je príliš zložité. V tom C to ide, pretože to je naozaj minijazyk.
27.6.2009 20:23
Marek Bernát | skóre: 17
| blog: Arcadia
Mimochodom, to sa asi nebavíme o monádoch, ktoré sú jednou z najzložitejších vecí, ktoré som vôbec v nejakom jazyku videl...
Já se bavím i o monádách.
27.6.2009 20:40
Marek Bernát | skóre: 17
| blog: Arcadia
A tvrdíte, že je jednoduché ich kompletne pochopiť? Vrátane ich algebraických vlastností ako endofunktorov v kategórii monoidov? Tak to klobúk dolu
Vrátane ich algebraických vlastností ako endofunktorov v kategórii monoidov?
To už neříkám Mám na mysli pochopit, co to je v Haskellu monáda, a jak použít ty, co jsou ve standardní knihovně Haskellu 98.
Když bych to bral takhle formálně, tak bych potom ani nevěděl, co je to OOP.
27.6.2009 20:57
Marek Bernát | skóre: 17
| blog: Arcadia
Hm, tak ale to potom treba rozlišovať pochopiť jazyk a pochopiť jazyk Jedno je len dostatočne na to, aby ste v ňom vedeli ako tak písať, druhé ovládať ho odzadu dopredu, keď Vás niekto o polnoci zobudí
27.6.2009 21:28
Marek Bernát | skóre: 17
| blog: Arcadia
Zasa reductio... Je zrejmé, že existujú rôzne úrovne chápania jazyka a chápať jazyk lepšie je určite výhodnejšie, než ho chápať horšie... Uznávam, že moje "pochopenie jazyka do hĺbky" je relatívne, ale zároveň si myslím, že existuje určitá objektívna hranica, kedy sa dá povedať, že "človek pozná jazyk ako svoje boty"
27.6.2009 21:16
Marek Bernát | skóre: 17
| blog: Arcadia
Nepovedal som, že som toho schopný, to ani zďaleka. Ničmenej, presne tak si predstavujem guru v danom jazyku a som si istý, že pár sa ich na tomto svete pre každý jazyk vyskytuje A je podľa mňa zrejmé, že by sa o dosiahnutie tohoto stavu mal každý programátor usilovať.
27.6.2009 21:13
Marek Bernát | skóre: 17
| blog: Arcadia
Prosím? Vy nerozumiete celým číslam? Čo je ťažké pochopiť na grupe (Z, +). Prípadne euklidovskom okruhu, prípadne hocijakej inej štruktúre? A áno, ja od poriadneho programátora vyžadujem pochopenie do hĺbky. Treba rozumieť floatom a tomu, kde všade môžu vzniknúť zaokrúhľovacie chyby, atď. Inak sú Vaše znalosti neúplné (hoci možno na 100% aplikácií, ktorým sa venujete, dostatočné).
Súhlasím, monády sú len súčasťou štandardnej knižnice; to ale nič nemení na tom, že bez nich žiadny program ani nespustíte, keďže Main :: IO()
Prosím? Vy nerozumiete celým číslam?Opravdu nemám pocit, že bych jim úplně rozuměl. Vy ano? Tak to mi povězte, jak rozumíte Velké Fermatově větě, nebo třeba proč platí Goldbachova hypotéza o prvočíslech? Moc rád se to naučím
27.6.2009 21:19
Marek Bernát | skóre: 17
| blog: Arcadia
Veľkej Fermatovej vete môže už asi tak 15 rokov rozumieť každý, kto má trochu snahy naučiť sa niečo o modulárnych formách a eliptických krivkách A Váš argument neberiem, lebo je to klasické reductio ad absurdum. Keď sa to takto preženie, tak nerozumieme (ako rasa inteligentných bytostí) vôbec ničomu a nemá zmysel sa snažiť ničomu porozumieť...
Veľkej Fermatovej vete môže už asi tak 15 rokov rozumieť každý, kto [...]A té Goldbachově hypotéze?
Není to tak, že kategorickým vlastnosti monád potřebujete při programování v Haskellu rozumět přibližně stejně dobře, jako Goldbachově hypotéze a při používání integerů v Céčku
27.6.2009 23:45
Marek Bernát | skóre: 17
| blog: Arcadia
K tej sa bohužiaľ nevyjadrím, lebo nie som až taký odborník na celé čísla, ako som si myslel
Nie, ja v tom vidím rozdiel. Sú totiž isté základné axiómy danej teórie a základné vlastnosti, na ktorých je tá teória celá vystavaná. Pre tie celé čísla by to boli axiómy grupového násobenia a základne vety toho sa týkajúce. Goldbachovu hypotézu (predpokladajme pre jednoduchosť, že platí, takže by to bola veta) by som tam rozhodne nezaradil. Týka sa to toho, ako často danú vlastnosť používate. To, že 2 + 3 = 3 + 2 využijete dosť často, na rozdiel od toho Goldbacha a ďalších pokročilých viet, napríklad tej Fermatovej, ktoré ste zrejme nikdy pri práci s celými číslami nepoužili. Samozrejme, že každá ďalšia vlastnosť je dobrá a môžete ju niekde teoreticky využiť, ale dá sa bez toho žiť. Zatiaľ čo bez tých základných vlastností nie (tj. ak tomu chcete "poriadne" rozumieť = viac ako len empiricky). Podobne pri monádoch sú ich algebraické vlastnosti základom. Budete schopný z nich niečo zosmoliť a bude to nejak fungovať, ale nikdy nepochopíte, prečo to vlastne funguje.
28.6.2009 14:07
Marek Bernát | skóre: 17
| blog: Arcadia
Nehovorím, že musíte. Musí sa len umrieť Hovorím len, že ak chcete vedieť, čo sa tam skutočne deje, tak je užitočné rozumieť matematickej stránke veci. A ostatne, už overenie tých axiómov podľa mňa presahuje úroveň, na ktorej s tým pracuje bežný Franta programátor
27.6.2009 20:20
Marek Bernát | skóre: 17
| blog: Arcadia
Súhlasím, že patrí k tým jednoduchším (v zmysle vnútornej konzistencie a dĺžky štandardu), ale na úrovni tých dvoch jazykov, ktoré som spomenul, to IMHO nie je.
), který umí něco na úrovni struktury či asociativního pole a dokáže volat funkce přes odkaz/referenci. S tím jde implementovat veškerá funkčnost (koneckonců, nakonec i objektový jazyk je přeložen do assembleru), i když plnohodnotnou implementaci všech vlastností "objektovitosti" nelze zařidit bez podpory v samotném jazyce a chybějíci vlastnosti (např. problém se jmennými prostory) se musí řešit pomocí rozličných obezliček (v C typicky prefikem před jmény).
V C ale narazíte na problém, kterým je omezená délka identifikátoru. Ve starém C směl být identifikátor dlouhý max. 6 znaků a jako dědictví máme v C velmi krátké názvy funkce, které se snažily do 6 znaků vejít, viz strlen, memcpy, apod.
Podle novější ANSI normy nemusí kompilátor rozlišovat více, než 32 znaků identifikátoru. Ono se to nezdá, ale Ti, co tu chtějí vše v C vyrábět integrováním do jména funkce (například tu kdosi chtěl nahrazovat new tím, že bude mít jméno funkce s prefixem typu) by mohli docela ošklivě narazit. Ono 32 znaků není moc.
egg_dbus_bus_name_tracker_get_known_well_known_bus_names_for_unique_bus_name
Pokud budete mapovat do názvu funkce všechny ty věci, co ty Céčkaři píšou jako triviální emulace C++, narazíte. To je celé, co jsem chtěl napsat.
Mimochodem, C++ to v kompilátoru pro linker přesně takto dělá – mapuje funkce/globální proměnné/metody a další do jednoznačných názvů, do kterých zahrne parametry, jejich typy, návratovou hodnotu, volací konvenci, a ještě leccos dalšího a občas z toho vycházejí hodně dlouhé názvy.
Vy jste asi nepochopil, jaký byl cíl jazyka C++.
C++ je jazyk zaměřený na maximální rychlost jehož rychlost je srovnatelná s rychlostí assembleru (tím se tedy vylučuje garbage collector, pořádná reflexe), zároveň jazyk, který je nenáročný na prostředky počítače (tím se opět vylučuje garbage).
C++ je jazyk odvozený od Simuly, škoda že ho neznáte. Vynikající jazyk, bohužel právě měl garbage collector, a Pascalovskou syntaxi. Tedy byl blíže tomu, co požadujete a řadu dalšího. Díky tomu byl tak nechutně pomalý, že se autor C++, Stroustrup, dostal do slepé uličky. Realizoval v Simule složité simulace, ale pomalost Simuly učinila tento jazyk nepoužitelným. Právě proto se rozhodl autor udělat efektivní a rychlý jazyk odvozený od Simuly a s C syntaxí, která už v té době byla obvyklejší. Rozhodl se, že nový jazyk bude rychlostně totožný s C, případně rychlejší a zároveň se v něm bude programovat rychleji a efektivněji, než v C. A to se na 100% podařilo.
Až budete někdy vymýšlet jazyk, jehož cílem je, aby výsledný program byl nejrychlejší co to dá – což je hlavní cíl C++ – tak vymyslíte něco podobného.
Takže Vaše argumenty jsou zcela mimo – protože by maximální rychlost jazyka neumožňovaly a proto nejsou v C++. Některé věci jsou v C++ složitější, než by musely být právě proto, že umožňují vyšší rychlost programu. To je určení C++ jazyka – použít ho tam, kde potřebujete z kompu vyždímat maximum. Pokud Vám na výkoně nezáleží, dají se použít i jiné jazyka.
protože by maximální rychlost jazyka neumožňovalyDobře, pomineme argumenty že "maximální rychlost jazyka" 1) nikdo nepotřebuje 2) ten kdo ji potřebuje, použije stejně asm. Pokud by C++ bylo tím, co jsem popisoval (zhruba to odpovídá současné JITované Javě nebo .NETu), co je podle vás důvodem, že by to nutně bylo pomalejší než C (nebo C++)? Typová kontrola, kontroly hranic polí- to se běžně vyhazuje v vnitřních smyček, a je zadarmo. To že garbage collection nemá oproti explicitnímu malloc/free žádnou systematickou režii navíc bylo taky dokázáno už mnohokrát. Takže co vám zbývá?
To že garbage collection nemá oproti explicitnímu malloc/free žádnou systematickou režii navíc bylo taky dokázáno už mnohokrát.Tomu se veri jen tezko. Ale rikate, ze to bylo dokazano... dukazy, tem ja verim, mate odkaz?
To že garbage collection nemá oproti explicitnímu malloc/free žádnou systematickou režii navíc bylo taky dokázáno už mnohokrát.Vzal jsem to hopem, ale clanek priznava, ze necim se platit tak jako tak bude. Cituji:
As memory increases, the number of garbage collections becomes proportionately fewer, and the time per garbage collection does not increase.
Ale trochu si odporujete.
Garbage collector je věc, která automaticky uvolňuje paměť, ale za cenu větší režie (což tvrdíte, že nemá žádnou systematickou režii navíc). Ta režie je buď snížení výkonu, a nebo plýtvání pamětí a její větší spotřeba oproti maloc/free. Oba případy znamení větší režii – jednou výkonovou, podruhé paměťovou.
Slovo „výhodnější“ je závislé na tom, jak si tu výhodnost nadefinujete.
V C++ se používají dvě cesty kromě malloc/new:
1) Použije se RAII koncept, který provádí automatickou dealokaci sám. Jeho výhodou je, že zatímco garbage collector jenom suše uklízí paměť, a zbytek je pro něho dost na hraně, takže se často v mnoha jazycích používá to, že programátor se stará o prostředky alokované objektem a gc za něj vyřeší paměť. Tedy dost často sám je nucen volat metodu dispose(), aby prostředky sytému nebyly zabrané dlouhou dobu, čímž by třeba byly vyčerpány a program by nemohl dále běžet. RAII koncept v C++ tohle řeší vše naráz, nic takévého se s ním stát nemůže – řeší paměť i prostředky systému a obojí automaticky uvolňuje včas.
2) Napíšete si vlastní alokaci, která je šitá na míru tomu co potřebujete. Většinou je to pár desítek řádků C++ kódu. S touhle možností počítá i STL, kde pro všechny objekty máte parametr allocator, který mu můžete předat. Můžete tak použít vlastní metody alokace a dosáhnout ještě dalšího výrazného zvýšení efektivity pro Váš konkrténí případ.
26.6.2009 17:46
Jardík | skóre: 40
| blog: jarda_bloguje
int * a = ALLOC(sizeof(unsigned long));Na to jsem alergický ... hádejte proč. Je to z toho prikladu (ať to znamená, co chce). Sice dle standardu sizeof(int)<=sizeof(long), ale pak následuje
*a = i * 2; kde i je typu unsigned long a může dojít k ošklivým věcičkám.
int *a = ALLOC(sizeof(*a));
26.6.2009 19:21
default | skóre: 22
| Madrid
Já tomu nerozumím. Když mám na levý straně int, proč mám mít na pravý long?
Třeba je to v pořádku. Vůbec tomu nerozumím, tak se omlouvám…
26.6.2009 19:53
Marek Bernát | skóre: 17
| blog: Arcadia
Si úplne mimo: "a" je len pointer. Alokuje sa unsigned long, to znamená, že *a odkazuje na miesto v pamäti, kde máš k dispozícii 8 bajtov a môžeš tam pohodlne nacpať i*2. Typ pointru a alokovaný typ spolu nijak nesúvisia.
26.6.2009 20:15
default | skóre: 22
| Madrid
Díky za odpověď. Už jsem to pochopil.
A taky jsem pochopil, o čem Jardík mluví: do unsigned long nemůžu přiřadit dvojnásobek unsigned longu. Obecně: dvojnásobek maximální hodnoty celočíselného datového typu T nemůžu uložit do stejného datového typu T, protože se to tam prostě nevejde.
26.6.2009 20:24
David Watzke | skóre: 74
| blog: Blog...
| Praha
Typ pointru a alokovaný typ spolu nijak nesúvisia.Protože nic jako "alokovaný typ" tady není. Operátor sizeof() se během kompilace promění v číslo.
26.6.2009 20:27
Marek Bernát | skóre: 17
| blog: Arcadia
Samozrejme. Len sa to tak môže niekomu zdať, keď vidí unsigned int takmer ako argument...
Dobře, pomineme argumenty že "maximální rychlost jazyka" 1) nikdo nepotřebuje
Na to se nedá říct nic jiného, než že ty lysohlávky už neberte.
2) ten kdo ji potřebuje, použije stejně asm
A také to už nepijte ani ředěné.
Pokud by C++ bylo tím, co jsem popisoval (zhruba to odpovídá současné JITované Javě nebo .NETu), co je podle vás důvodem, že by to nutně bylo pomalejší než C (nebo C++)
Protože bylo. Protože v odbě běhu programu by to řešilo více věcí, než řeší dnešní C++. A dělat více věcí = pomalejší běh programu.
Typová kontrola, kontroly hranic polí- to se běžně vyhazuje v vnitřních smyček, a je zadarmo.
Ne vždy. Někde to jde a někde ne. Koneckonců kontrolu hranic polí je věc, kterou řada lidí v C++ používá. Dokonce to C++ kompilátor také dokáže odstranit z vnitřních smyček.
To že garbage collection nemá oproti explicitnímu malloc/free žádnou systematickou režii navíc bylo taky dokázáno už mnohokrát.
Ha ha ha.
které za runtime řeší více věcí než C, např. dyn dispatch nebo castyJo a tohle je presne vas dementni prvotni predpoklad. C++ neresi v runtime nic navic vuci Cecku.
Protoze s vami ztraci trpelivost? Ja jsem stary flegmatik, takze vam to vysvetlim znovu.
Virtualni funkce ani dynamic_cast nejsou nutnou podminkou pro napsani programu v c++, pokud je nechcete pouzivat, tak je nepouzivejte a zadny overhead se konat nebude. Ted pozor: pokud se rozhodnete, ze byste virtualni funkce fakt potreboval, tak v c budou mit stejny runtime overhead, jako v c++. A kdyby se vam osklivilo klicove slovo virtual, muzete to i v c++ udelat rucne pres tabulku funkci a vyuzivat jenom sablony. Napriklad.
nejsou nutnou podminkou pro napsani programu v c++ ... a zadny overhead se konat nebudeStejně tak lze v dynamicky kompilovaném silně typovaném jazyku určité runtime kontroly vypnout. I GC lze vypnout- nastavíte velký treshold, a připravíte si velký swap. Ale to že něco LZE vypnout je přece irelevantní, mnohem důležitější je jestli se něco v praxi skutečně používá nebo ne.
Ted pozor: pokud se rozhodnete, ze byste virtualni funkce fakt potreboval, tak v c budou mit stejny runtime overhead, jako v c++. A kdyby se vam osklivilo klicove slovo virtual, muzete to i v c++ udelat rucne pres tabulku funkci a vyuzivat jenom sablony. Napriklad.Já jsem také trpělivý, proto mi vaše teatrální gesta nevadí, a nemusím na ně reagovat. Jedním z důvodů proč se v C++ používají virtuální funkce, je code reuse. Base class obsahuje velkou funkci F(), která na některých místech volá malé virtuální funkce, a proto můžou instance derived classů dělat pro F() pokaždé něco trochu jiného. Jenže v "C" virtuální funkce nemáme, použijeme tedy metodu copy-paste-replace. A ouha, máme identickou sémantiku, ovšem s inlinováním místo dynamického dispatche, tudíž bude C rychlejší než C++. Samozřejmě že je to uhozený argument, a že v C++ lze napsat stejnou verzi s inlinovanými virtuálními funkcemi (a když zná překladač typy staticky, udělá to dokonce za nás), nicméně (viz první odstavec) není důležité CO JDE v jazyku udělat, ale JAK se používá. Proto je pravda že "C++ toho za runtime dělá více než C".
Base class obsahuje velkou funkci F(), která na některých místech volá malé virtuální funkce, a proto můžou instance derived classů dělat pro F() pokaždé něco trochu jiného.Fuj! Radsi fakt zustante u toho Cecka. Takove veci jako navrh zalozeny na zasadach k vam asi zatim nedoputovali.
Kdyz nepouzivam virtualni funkce, tak je proste nepouzivam, nic "vypinat" nemusim. V C volat funkce pres ukazatel nejde? Nebo jde, ale v praxi se to nepouziva? Kdyz je volam normalne, take "vypinam" dynamicky dispatch?
Hlavne se tim chlubte, ze copy-pastujete kusy kodu. Krom toho jste tady slapnul trosicku vedle, protoze v C++ staticky dispatch mame, zcela prirozeny a bez kopirovani. A ti prostsi mezi nami mohou v C++ prasit kopirovanim stejne produktivne, jako v C.
Ja nevim, souhlasil byste s tvrzenim, ze C trpi overheadem kvuli volani funkci pres ukazatele a nic na tom nemeni fakt, ze to lze vypnout?
... použijeme tedy metodu copy-paste-replace. ...
Protoze jste daval priklad zbytecneho uziti virtualnich funkci v C++ jako ukazku jeho pomalosti a provnaval to s C, kde to delate staticky? Jestli vite, ze v C++ to jde staticky take a jeste ke vsemu bez kopirovani, tak ceho to melo byt dukazem?
Třeba nějaká widgetová knihovna, ta bude mít hromadu kódu, který bude volat různé get_bbox(), paint() apod, který se specializovat pro každý widget nevyplatí, proto budou ty metody virtuální.A kdyz to same napises v Cecku tak budes pouzivat simulaci virtualnich metod. Jediny rozdil je v tom ze zatimco C++ kompilator nad tim bude schopen udelat nejake optimalizace, Ceckovy nema sanci.
26.6.2009 17:58
Jardík | skóre: 40
| blog: jarda_bloguje
Ja nevim, souhlasil byste s tvrzenim, ze C trpi overheadem kvuli volani funkci pres ukazatele...?To bude asi tím, že ve všech programech pro x86/x86_64 a spoustu dalších architektur se provádí volání funkcí přes ukazatele. Prostudujte si např. instrukci "call" pro x86_64 a zjistíte, že vyžaduje ukazatel (adresu).
call není volání funkce přes ukazatele. Běžná C funkce je, že máš adresu v paměti kam se jumpne (call je jump s uložením return address na stack, že...) a případně se předtím nastrkaj argumenty do registrů/stacku.Volanim pres ukazatele jsem myslel neprima volani, neboli situaci, kdy adresa, kam se ma skocit, je ulozena bud v registru, nebo v pameti. Bavime se tu o virtualnich funkcich...
Rozhodl se, že nový jazyk bude rychlostně totožný s C, případně rychlejší a zároveň se v něm bude programovat rychleji a efektivněji, než v C.muzete uvest nejaky zdroj, nebo se jako obvykle jedna o vasi domenku?
Až budete někdy vymýšlet jazyk, jehož cílem je, aby výsledný program byl nejrychlejší co to dá – což je hlavní cíl C++ – tak vymyslíte něco podobného.vy uz jste nekdy nejaky programovaci jazyk navrhoval?
muzete uvest nejaky zdroj, nebo se jako obvykle jedna o vasi domenk?
Chápu, že Vaše IQ Vám nedovoluje zvládnout Google. Ale třeba za pomoci někoho dalšího to zvládnete.
vy uz jste nekdy nejaky programovaci jazyk navrhoval?
Důvod této otázky?
Chápu, že Vaše IQ Vám nedovoluje zvládnout Google.prestante argumentovat tak detinsky a ukazte mi nejaky zdroj. staci treba jenom nejaky puvodni TR.
Důvod této otázky?vyborne se bavim... ;-]
25.6.2009 12:52
Jardík | skóre: 40
| blog: jarda_bloguje
Nie je nad funkcie akoViděl jsem horší - z tohohle alespoň clověk pochopí, co ona funkce dělá, i když hrozí, že pokud nemá v IDE auto-competition, upíše se k smrti. Horší je, když z něj skoro nejde poznat, co funkce vlasně dělá (v C např. funkce zegg_dbus_bus_name_tracker_get_known_well_known_bus_names_for_unique_bus_name
wchar.h) a stejně se nevejde do limitu 6 nebo 8 znaků/jméno. Když se do toho navíc zamíchá ještě madarská notace zohlednující typ, způsob volání a já nevím co ještě, tak často vylezou jména, za která by se nemuseli stydět ani zplozenci Chthulhu
m_lpszFileName som našťastie už dlho nevidel
_ZNK5boost6spirit4impl15concrete_parserINS0_8sequenceINS0_6actionINS0_4ruleINS0_7scannerISt20_List_const_iteratorINS_4wave8cpplexer9lex_tokenINS8_4util13file_positionINSB_11flex_stringIcSt11char_traitsIcESaIcENSB_9CowStringINSB_22AllocatorStringStorageIcSG_EEPcEEEEEEEEENS0_16scanner_policiesINS0_28skip_parser_iteration_policyINS0_11alternativeINSS_INS0_5chlitINS8_8token_idEEESV_EESV_EENS0_16iteration_policyEEENS0_12match_policyENS0_13action_policyEEEEENS0_15closure_contextINS8_8grammars8closures16cpp_expr_closureEEENS0_5nil_tEEEN7phoenix5actorINS1B_9compositeINS1B_9assign_opENS1C_INS1B_14closure_memberILi0ENS1B_7closureINS16_13closure_valueENS1B_5nil_tES1I_S1I_S1I_S1I_EEEEEENS1C_INS1B_8argumentILi0EEEEES1I_S1I_S1I_S1I_S1I_EEEEEENS0_11kleene_starINSS_INSS_INSS_INS3_ISV_NS4_IS1A_NS1C_INS1D_IS1E_S1L_NS1C_INS1D_INS1B_8lt_eq_opES1L_S1O_S1I_S1I_S1I_S1I_S1I_EEEES1I_S1I_S1I_S1I_S1I_EEEEEEEENS3_ISV_NS4_IS1A_NS1C_INS1D_IS1E_S1L_NS1C_INS1D_INS1B_8gt_eq_opES1L_S1O_S1I_S1I_S1I_S1I_S1I_EEEES1I_S1I_S1I_S1I_S1I_EEEEEEEEEENS3_ISV_NS4_IS1A_NS1C_INS1D_IS1E_S1L_NS1C_INS1D_INS1B_5lt_opES1L_S1O_S1I_S1I_S1I_S1I_S1I_EEEES1I_S1I_S1I_S1I_S1I_EEEEEEEEEENS3_ISV_NS4_IS1A_NS1C_INS1D_IS1E_S1L_NS1C_INS1D_INS1B_5gt_opES1L_S1O_S1I_S1I_S1I_S1I_S1I_EEEES1I_S1I_S1I_S1I_S1I_EEEEEEEEEEEEEES13_S1H_E16do_parse_virtualERKS13_
To je bohužel asi jedinná věc na kterou je C++ dobré- dají se s ním vyhrávat soutěže o nejdelší identifikátor :) :) :)
libboost_wave.a. Je weak, to je důsledek toho že C++ má hokej v tom kdy instancovat templaty, takže potřebuje aby mu linker podával tuhle berličku.
> je to vznik z mnoha šablon
A?
> Všechno co jde napsat v C++ jde i v C, ale i naopak
Naprostý souhlas.
> se stejným výkonem i velikostí binárek.
Bohužel ne. Už jen ta blbinka, že C++ potřebuje volat statické inicializátory a destuktory, vám nafounkce startup kód zhruba na trojnásobek. A nevyhnete se tomu ani tím, že nepoužijete žádnou C++ featuru.
Je to úplně normální globální exportovaný symbol z knihovny libboost_wave.a. Je weak, to je důsledek toho že C++ má hokej v tom kdy instancovat templaty, takže potřebuje aby mu linker podával tuhle berličku.Ale přece vás nikdo nenutí používat boost, tak jako v C vás nikdo nenutí používat glib. Já si myslím, že je opravdu omyl soudit jazyk podle různých knihoven. Podle mě, pokud někdo potřebuje tak dlouhý symbol, je něco v kódu špatně (ne překladači).
je to vznik z mnoha šablon...AA nic, pokud se budete řídit koncepty STL knihovny, tak vám ten design asi vyhovuje a neměl by jste si na to stěžovat. Já osobně koncept šablony-na-všechno nepoužívám, protože mi nesedí, a věřím, že nejsem sám. Tímto jsem chtěl říct, že nějaké STL nebo Boost přece nemůže ovlivnit C++ jazyk samotný, nikdo vás přece nenutí to používat.
Bohužel ne. Už jen ta blbinka, že C++ potřebuje volat statické inicializátory a destuktory, vám nafounkce startup kód zhruba na trojnásobek. A nevyhnete se tomu ani tím, že nepoužijete žádnou C++ featuru.Toto mi prosím objasněte, trojnásoběk čeho? V C++ jsem schopný napsat binárku, která má 4kB, ptám se, je to moc? Když v C napíšete tu samou binárku, co má 3.9kB, tak je C nepřekonatelně lepší jazyk a C++ by díky 100 bytům měl být zatracen? Pokud se vám chce reagovat, tak mě zajímá ten startup kód. Startup čeho, koho, které knihovny, atd. A pokud vám jde o to, že knihovna nebo binárka obsahuje o pár symbolů víc kvůli C++ jazyku, tak to je podle mě jen nano detail, který nemá absolutně na nic vliv. ------- Podle mě se dobrá knihovna pozná podle použitých algoritmů a programovacích technik, a ne podle náboženského sporu o C nebo C++. Jaktože Qt totálně válcuje Gtk a přitom je psané v tom pomalém C++? Jaktože Qt-Arthur, AntiGrain, GDI+ válcuje Cairo i s pangem a tím vším dohromady, i když je to psané v tom pomalém C++ (kromě GDI+)? Mám pocit, že to čísté C a všechny ty nádstavby alá GObject, Gtk, GAtd jsou tak neefektivně napsané, že udělat to hůř snad ani nejde. Podle mě to je chybou vývojářů, ale i jazyka v tom smyslu, že místo toho, aby se programátoři věnovali algoritmům a návrhu knihovny, tak si hrají s low-level C a přemýšlí, jak z toho udělat high-level C. Ale pořád je to jen to C. Nechci vypadat jako někdo, kdo nemá rád C, já mám rád C i C++, a klidně bych programovat i v čistém C, bylo by li to nutné, jenže není (nejsem kernel vývojář, a na nic jiného podle mě v současnosti není potřeba). Omlouvám se, pokud jsem něco překroutil, ale začínám mít pocit, že při srovnání těchto dvou jazyků velmi často mizí objektivní posouzení a místo toho se omýlají pořád dokola nějaké mýty.
24.6.2009 22:54
Luk | skóre: 47
| blog: Kacířské myšlenky
| Kutná Hora
printf() místo streamů), ale zrovna moc často.
"nevyhovujici objektovy model" - tj napr nemoznost dynamickeho volani konstruktoru, problematicka RTTI, nebo neportabilni ABI mezi ruznymi verzemi prekladaceTohle tezko muze byt brano jako duvod proc pouzivat radsi Cecko nez C++. Btw. kde bylo konkretne neportabilni ABI (btw. MSVC nepocitam mezi C++ kompilatory).
Tohle tezko muze byt brano jako duvod proc pouzivat radsi Cecko nez C++.Může: Když už tak jako tak potřebujete implementovat svůj vlastní objektový model, je někdy lepší stavět na zelené louce než na mizerném objektovém modelu
Přeci jenom oproti opravdové rozšiřitelnosti syntaxe a sémantiky (třeba takovému, jako má již zmíněný Perl6) je to jenom velmi slabá náhražka.
To je ve své podstatě jenom syntaktické pozlátko.
Ale ani v C, ani v C++ si nemůžete pořídit vlastní dispatch metod (a tedy si například definovat vlastní pravidla pro přetěžování).
Za cenu, že to bude 3× pomalejší, když to hodně dobře ten jazyk s dynamickým disptachem implementuje.
Možná Vám ušlo, že jazyk C i C++ byl dělán v první řadě pro maximální rychlost programu a pro možnost vymáčknout maximum výkonu ze stroje co to dá.
Dovolte tedy abych Vám to připomenul.
Můžete se maximálně limitně blížit k rychlosti C++, to je vše. Navíc C++ nemá ani ten overhead prvního zavolání. A velmi často se dokonce vituální metoda volá staticky, on kompilátor C++ dosti optimalizuje.
Znovu zdůrazňuji, že hlavní v návrhu C++ byla rychlost. Díky tomu také C nemá oproti C++ rychlostně co nabídnout.
Můžete se maximálně limitně blížit k rychlosti C++, to je vše. Navíc C++ nemá ani ten overhead prvního zavolání.Pri pouziti 'inline cache' je kazde volani metody prelozeno na PRIMY call na pravdepodobny receiver (tato instrukce se pri cache missu patchuje), coz je rychlejsi nez virtualni metody v C++. Na zacatku kodu metody se sice musi overit ze se typ objektu nezmenil (jeden cmp na konstantu a dobre predikovatelny skok), ovsem to se da v prologu funkce docela dobre zamaskovat (mnoho instrukci, malo zavislosi). Takze tvrdit neco o 'limitnim blizeni se C++ idealu) je dosti nesmysl.
Implementace prijimani zprav (jak dynamicka tak staticka) je v C++ na par radku.
Račte se tedy s párřádkovou implementací vytasit (takovou, která nebude vědět nic o metodách objektu, jehož zprávy předává), já ze sebe rád nechám příslušné hovado udělat.
struct Message { };
class CanAcceptMessage
{
public:
virtual bool accept(Message*) = 0;
};
class MyClass : public CanAcceptMessage
{
public:
bool accept(Message* m) { if (dynamic_cast<MyUnderStoodMessage*>(m)) return true; else return false; }
};
int main()
{
CanAcceptMessage* obj = new MyClass;
Message* mes = new SomeMessage(....);
obj->accept(mes);
}
Staci takhle?Kdepak. Já chci něco, co mi vzdálený objekt (se kterým se komunikuje pomocí zpráv) zabalí tak, abych ho mohl používat jako objekt obyčejný, a přitom ono zabalení nemuselo obsahovat kompletní výčet metod vzdáleného objektu (jinými slovy aby bylu univerzální a fungovalo s libovolným vzdáleným objektem).
Volání metod je čistě syntaktická záležitost. Její sémantika může být různá: zavolání funkce, poslání zprávy jinému objektu/vláknu/procesu/počítači/... Ve slušných objektových jazycích si sémantiku můžete zvolit.
Zrovna u Martina bych si na takova vyjadreni daval pozor, protoze je temer 100%-ni sance, ze se ztrapnite vy.
Zatím je Martin samá sranda. Ne, že by tvrdil vyslovené ptákoviny, ale jinak je dost mimo.
Ale ani v C, ani v C++ si nemůžete pořídit vlastní dispatch metod (a tedy si například definovat vlastní pravidla pro přetěžování).
To ale nic nebrání tomu, že v C++ jsou možnosti programátora něco ovlivnit výrazně vyšší, než v C. A výsledek je i čitelnější.
Argumentovat extrémy nemá moc smysl.
Jinak veškeré vyšší programovací jazyky nejsou vůbec nic jiného, než syntaktické pozlátko pro člověka. Procesor jim přímo nerozumí a je potřeba je přeložit do jemu srozumitelné řeči.
To ale nic nebrání tomu, že v C++ jsou možnosti programátora něco ovlivnit výrazně vyšší, než v C.Nemohu se ubránit dojmu, že vyšší ty možnosti sice jsou, ale že ty opravdu podstatné věci stejně zcela chybí. A těch pár drobnosti navíc prostě nevyvažuje mnohem vyšší celkovou obludnost jazyka.
A právě proto se C++ tak rozšířilo. Asi proto, že to co umí nad C nestálo za to.
Nenajdete náhradu za C++ pro větší projekty, když potřebujete efektivitu a rychlost výsledného programu.
Právě proto se řada větších C projektů snaží přejít z C na C++.
Ono to vyvažuje tu vyšší obludnost jazyka. V C++ naprogramuje program výrazně (tj. i mnohonásobně) rychleji, a výsledek bude spolehlivější. Za předpodkladu, že oba jazyky umíte.
Nenajdete náhradu za C++ pro větší projekty, když potřebujete efektivitu a rychlost výsledného programu.Vy ji nenajdete
Ledaskdo jiný už ji dávno našel.
Ve větších projektech osobně sleduji úplně jiné tendence, totiž většinu projektu postupně přepsat do nějakého opravdu vysokoúrovňového jazyka a to málo, co musí být opravdu rychlé, držet co možná na nejnižší úrovni.
Zvláštní. Já když se setkám s lidmi, kteří mají volbu mezi C a C++, a umí obojí a nejsou fanatici snažící se prosadit C za každou cenu, v jeijch projektu není ani řádek C kódu.
Pokud někdy sledujete mé komentáře, určitě víte, že s kritikou se moc nemažu.
Ale nevidím opravdu ani jednu praktickou výhodu pro Céčko, pokud si můžete vybrat mezi C a C++. A to oba jazyky znám velmi dobře.
C nenabízí naprosto nic oproti C++. Není ani rychlejší, ani se nekompiluje rychleji, ani není výsledný kód rychlejší, než v případě C++. Ba dokonce je snažší napsat rychlejší program v C++ díky šablonám, kde Céčkař to dřív zabalí, než by to optimalizoval.
C++ přeci jenom nabízí výrazně pokročilejší věci, které v hlavně týmu, či větším projektu jsou neocenitelné. Namespace, řízení viditelnosti dat, možnost přetížení funkcí, vlastně celé OOP.
Na low věci není C vhodnější, než C++.
Osobně si myslím, že skutečně objektivní srovnání C a C++ by dopadlo pro C velmi katastrofálně. Nenašel byste jedinou skutenoču výhodu C. Je mi naprosto jasné, že řada lidí se tu C snaží prosazovat, ale z ryze subjektivních důvodů. Buď ho umí a v C++ selhali. Nebo si přečetli dokument od Linuse, který nikdy C++ neuměl a nikdy ho nezvládl. Případně se pokoušeli C++ používat jako C, což je chyba. Atd. U Linuse je to poraněné ego, že nezvládne všechno na světě.
25.6.2009 08:06
mirec | skóre: 32
| blog: mirecove_dristy
| Poprad
Na low věci není C vhodnější, než C++.
Skúste obludnú štandardnú knižnicu nahrať do jednočipu. Inak s použitím C++ na normálnych strojoch súhlasím, má mnoho výhod oproti čistému C. No a C++0x, alebo boost je už fakt iné kafé, radosť s tým pracovať.
A proč bych měl chtít nahrávat celou C++ knihovnu do jednočipu. Vždyť se to nedělá ani v C!
Já nevidím jediný problém v C++ ani na jednočipu, pokud tam bude dobrý kompilátor C++. Nepoužil bych C, protože nevidím absolutně jedinou výhodu C oproti C++ ani v použití pro jednočipy.
Ono C++ je udělané dobře a dobře zastane vše, co udělá C a ještě mnoho věcí navíc. Pokud mám na jakékoli platformě – včetně jednočipů – možnost vybrat si mezi C a C++, tak neobhájím, proč by C++ nebylo lepší.
Nepoužil bych C, protože nevidím absolutně jedinou výhodu C oproti C++ ani v použití pro jednočipy.Je vidět, že o jednočipech víš asi tak tolik, jak o rozdílech v rychlosti počítání floatů s SSE a bez. Jenom ten kus kódu, který řeší věci okolo objektů, dědičnosti a spol. může být dost na to, abys program psaný v C++ do toho jednočipu vůbec nedostal.
V C++ není problém psát i neobjektově (a i tam je dost výhod nad C).
Dále jsou jednočipy, kam nedostaneš ani C kód. Některé jednočipy mají ukrutně malou paměť na program, a pak smolenka.
A znovu: Pokud někdo v C++ píše jako hovado, a není schopen použít adekvátní prostředky z C++ k tomu co tvoří (například Linus Torvalds), pak bude mít problémy nejenom v jednočipech. V C++ je většinou více cest, jak dosáhnout to samé, a je to tak proto, aby se to dalo použít pro všechny případy.
25.6.2009 18:50
mirec | skóre: 32
| blog: mirecove_dristy
| Poprad
C nenabízí naprosto nic oproti C++. Není ani rychlejší, ani se nekompiluje rychleji, ani není výsledný kód rychlejší, než v případě C++.Není pravda, že by nebylo rychlejší. Zkuste si například někdy pořádně změřit, jaký vliv na rychlost a hlavně na velikost (což díky cacheování obvykle také ovlivňuje rychlost) kódu mají C++kové výjimky. O ty se bohužel musí starat každý kus kódu, i ten, který sám výjimky nevytváří ani nechytá, ale mohou skrz něj propadávat. Hlavní důvod, proč mám raději C než C++, je ale někde úplně jinde: v přehlednosti jazyka. Céčko je docela malý jazyk, který se dá za chvíli naučit do posledního detailu, a když vidíte Céčkový program, obvykle na první pohled poznáte, co dělá. C++ je mnohem komplikovanější, asi ani neznám člověka, který by ho uměl perfektně, a první pohled na programovou konstrukci prozradí daleko méně (kvůli přetěžování, šablonám, referencím, výjimkám a podobným věcem se může chovat a často i chová velmi neintuitivně).
Osobně si myslím, že skutečně objektivní srovnání C a C++ by dopadlo pro C velmi katastrofálně.Mimochodem, jak byste si představoval, že by takové objektivní srovnání mohlo fungovat?
Ve větších projektech osobně sleduji úplně jiné tendence, totiž většinu projektu postupně přepsat do nějakého opravdu vysokoúrovňového jazyka a to málo, co musí být opravdu rychlé, držet co možná na nejnižší úrovni.Asi tak.
O přepsání části projektu do vysokoúrovňového jazyka nikdo nepochybuje. Řada projektů si dokonce vlastní jazyk stvoří. Ale pro nízkoúrovňovou část není důvod použít C.
Aby nedošlo k mýlce, mně to baví číst a pokaždé se z vašich flejmů něco zajímavého dozvím. Ale nerozumím, co vede lidi, ke kterým mám pro jejich programátorské dovednosti v C a C++ docela dost respekt (MJ, pan Pokrác nebo třeba ty) nutkání se takhle do krve hádat. Já sice ani zdaleka tyto jazyky neovládám tak, jak bych chtěl, ale jsem schopen se díky tomu odosobnit a přiznat, že jsou oba stejně schopné a vhodné, pokud je dostane do ruky správný člověk. Píšu teda spíš v C++ než v C, ale to je čistě proto, že je pro mě C++ pohodlnější.
Nenechte se rušit, pokračujte.
Jednoduše – já se hádám jen do té míry, abych udělal osvětu, že C nemá žádnou výhodu oproti C++. Jiných ambicí nemám. V obou jazycích jsem dělal mnoho let, znám je jako vlastní boty a dost dobře nedokážu říct jedinou výhodu použití C oproti C++, a to v žádném případě použití – ani na jednočipech, ani na jakémkoli druhu projektů. V použití C vidím jen nevýhody. Pokud tedy existuje na danou platformu dobrý C++ kompilátor.
Jinak ať si každý používá co chce, klidně C. Pokud se mu líbí, proč ne, je to naprosto v pořádku.
Jen by si měl uvědomit, že C používá proto, že se mu líbí, ale ne proto, že je to výhodnější, než C++, což je lež.
A také to, že Céčkař není s to vůbec dohlédnout možnosti a efektivitu C++, protože ho zkrátka minimálně, pokud vůbec používá.
Mě se prudce zvýšila efektivita programování v C++ v okamžiku, kdy jsem si uvědomil, že nemůžu v C++ programovat stejným stylem jako v C. V tom okamžiku rychlost tvoření programů, jejich efetivita, spolehlivost i rychlost šla prudce nahoru i několikanásobně.
Nechci nikoho přeorientovávat na C++. Ať si každý programuje, v čem ho těší a v čem chce. Je to tak dobře. Klidně ať si tu 90% lidí dělá v C, když chtějí, je to v pořádku. Mám jedinou ambici – zarazit ty FUDy o tom, že C je výhodnější, než C++. Není. Není ani v jednom bodě a nikdo z Céčkařů by tohle nedokázat odargumentovat. V zásadě chci očistit C++ od lží, které na něj házejí z jedné strany Céčkaři a z druhé strany Javisti. To je vše.
Takové FUDy se ale šíří v mnoha směrech.
Ono to právě souvisí s neschopností, povrchností a malými znalostmi většiny dnešních programátorů. Zatímco dříve, když programátor musel znát hodně, tak většinou se nenechal zmást FUDy, a pokud ano, dost často na to tvrdě dojel.
Dnes jsou znalosti programátorů naprosto minimální, a proto o to více dají na povrchní argumenty. Těch FUDů a lží je moc. Typicky: „C je rychlejší, než C++“, „Java je rychlejší, než C/C++, případně stroják“, „Java je čistý OOP jazyk“, „používáme .NET protože Microsoft vytváří nejlepší technologie“, „gcc kompilátor dává dobrý a optimalizovaný kód“, „pleteme si jazyk s kompilátorem gcc a nedokážeme si uvědomit, že jazyk není nutně to co předvádí gcc a vlastnosti gcc nejsou vždy nutně vlastnosti jazyka“, „XML je nejlepší používat na úplně všechno“, „XHTML je výhodnější, než HTML“, „není důležité, aby se webové stránky dobře zobrazily ve všech prohlížečích, důležité je, aby W3C validátor neukázal žádnou chybu“, a tisíce dalších nepravdivých vět.
V reálném prostředí se člověk musí přizpůsobit.
Největší sranda je, že jsem asi před 6–7 lety jednoho dne odeslal snad stovce personálních agentur CV s tím, že chci programovat v C++. Byl jsem do jednoho odmítnut, načež asi po roce jsem byl doslova zahrnut asi od 10 z nich nabídkami na to, že shání C++ programátora. Pozdě.
„gcc kompilátor dává dobrý a optimalizovaný kód“
To vážně někdo tvrdí?!
Já jsem si před pár měsíci dělal porovnání – napsal jsem naprosto jednoduchý program (výpočet faktoriálu), několikrát jsem ho přeložil pro PowerPC (protože neumím x86 asm) se všemi smysluplnými kombinacemi optimalizací, postripoval a porovnával s vlastním kódem – ten nejoptimalizovanější výstup z gcc obsahoval asi deset naprosto zbytečných přesunů mezi registry (násobil 1 a 2, uložil do 3, přesunul 3 do 1 apod.) a šest no-opů (addi 1,1,0 apod.). Paradoxně byl tím nejlepším výstupem ten zkompilovaný s -O2 – -O3 i -Os propadly.
.
Ručně napsat assembler se vám asi vždycky rychlostně vyplatí, ale celý program v asm psát asi určitě nebudete, že:)
Ale to snad všichni víme, že GCC je mizerný překladačNa Intel architektuře to prý není tak hrozné. Ale i tak by člověk čekal, že alespoň tu jasně a čistě napsanou matematickou funkci to zoptimalizuje do čtyř instrukcí místo do jedenácti.
celý program v asm psát asi určitě nebudete, že:)To se raději ani nepokouším naznačovat. Mrazí mě jen při té představě – i miliony goto jsou lepší než stwu sthbrx mtsrin frsqrtes (a to jsou tam i šťavnatější kousky – někdo si stěžoval, že tam IBM dává málo samohlásek, tak zavedli eieio
).
Treba proto, ze jsem diky tomuhle FUDu mometalne nezamestnan?
tomu pane kolego neverim. Ten duvod lezi v povrchnosti dnesni spolecnosti, ktera se nechce zabyvat s problemy, ale pouze je delegovat (nejradeji do Ciny nebo Indie). Ve stavarine je to totiz podobne - zeptaji se vas, jestli umite pracovat s autocadem verze x.y. a kdyz znate nejakou jinou nebo nedejboze jiny nastroj, tak je HR-slecna v nejstote, jestli je dotycny humanni zdroj vhodny a schopny generovat dostatek nadhodnoty pro financni elity tohoto sveta.
pretezovani funkci a operatoru, specializace sablonZ toho bude mať najväčšiu radosť človek, ktorý to dostane do ruky po troch rokoch. Aj keby to mal byť pôvodný autor.
Tak já nevím, já udržuji svoje i cizí C/C++ projekty i po více, než 10 letech a nemám problémy.
Pokud jste do ruky nedostal jiný, než prasecký kód, tak je mi to líto.
Ale C++ je po letech výrazně čitelnější, než C. Právě proto, že jsou tam rozmně použité operátory, třídy, šablony. Zatímco v C je to emulováno, takže to v kódu splývá a každý to emuluje samozřejmě jinak.
každý výraz, operátor, volání funkce, a klíčové slovo, si lze v hlavě OKAMŽITĚ přeložit na nějaký kus nízkoúrovňového pseudokódu, tj sémantika je zcela zřejmáTy si pri chapani kodu kod v hlave prekladas do assembleru???
Uprostřed funkce (pardon, metody) vidím přiřazení do nějakého lvalue. A kurva, co je tohle zač? Že to není lokální proměnná lze zjistit snadno pohledem na blízké deklarace. Je to globální proměnná? Nebo atribut instance?Identicky problem mam v Cecku, jenom to nemuze byt atribut. Od toho aby se to jednoduse odlisilo se pouziva semanticke zvyraznovani kodu.
Při volání funkce, bez koukání na prototyp, nepoznáte díky referencím IN argumenty od INOUT argumentů.A jak proboha zavolam funkci bez toho abych znal prototyp?
Typ 'blah' je sice z kódu vidět, ale jaký typ tohle H() vrací nevíte, netušíte tedy ani která přetížená varianta G() neřkuli F() se vlastně volá.Jakto, ze to nevim? Vim to uplne stejne jako v Cecku.
C++ kód je bez symbol browseru skoro nečitelný- a abyste jej měli, musíte jej nejdřív přeložit, a když je zdroják z nějakého důvodu zrovna nepřeložitelný, jste v háji.WTF?
>Ty si pri chapani kodu kod v hlave prekladas do assembleru???
Tohle me take zaujalo. IMHO pan zde bude nejakej ultrabednahaker a je zvyklej videt matrix primo.
Soudě podle open source projektů, s kterými jsem se dosud setkal, je to obvykle naopak.
Já mám zkušenosti právě opačné. Dokonce můžu s přehledem říci, že nejprasečtěji napsané programy jsem viděl práve v Céčku (ze všech programovacích jazyků co jsem měl kdy tu čest potkat). A nejprasečtěji psali právě ti, kteří si za každým C příkazem představovali stroják, a vlastně psali ve strojáku, jen v C syntaxi.
Jinak naprosto nechápu Vaše další argumenty. Nepotřebuji za každým příkazem vidět jeho strojovou podobu. Stejně tak pokud operátor + dělá to co se od něho očekává, nezajímá mě, jak to dělá. A mě by zajímalo, jestli Vámi deklarované snížení čitelnosti kódu, když v C++ napíšu:
matrix a,b,c;
a = b * c + matrix::identity() + b * b - c;
oproti velmi čitelnému zápisu v C:
a = matrix_sub(matrix_add(matrix_add(matrix_mul(b,c),matrix_identity()),matrix_mul(b,b)),c);
by řada lidí sdílela s Vámi.
Co je v C emulováno? Každý to co potřebuje dělá tak jak chce a jak mu to vyhovuje, a díky dobré čitelnosti není problém použité konvence rychle pochopit.
Ano, každý si to napíše po svém. Stejná věc je řešena tisíci zápisy. Každý jinak.
další věc kterou jste zatajil je, že implementace té třídy matrix bude dosti složitá, díky tomu že bude potřeba řešit dealokaci mezivýsledkůJaka dealokace vysledku zase?
Protože ale lidé obvykle pro vysokoúrovňové věci C nepoužívajíJestli si to nezaregistroval (ocividne ne) tak cela tahle diskuze je o tom ze lide na vysokourovnove veci pouzivaji Cecko!
Ad 1) Bude čitelnější v mnoha případech. Vy víte něco o té třídě matrix, že mluvíte o dealokaci? Co když je to třeba transformační matice pro grafiku konstatního rozměru 4×4, tudíž žádnou dynamickou paměť nepotřebuje? Jinak C++ se chová naprosto předvídatelně a zvládnout napsat 2 metody: copy konstruktor a operator= není nic složitého.
Ad 2) Ale já nechci a většina lidí nechce maticovou knihovnu v C. Jednak bude nejspíš pomalejší, protože v C++ se to většinou naháže do kódu inline přes šablony, nebo inline funkce. A zrovna u operací matic s malými rozměry (třeba 4×4) může být režie volání a pak bindingu mezi C a Pythonem dost nenažraná.
A zrovna u operací matic s malými rozměry (třeba 4×4) může být režie volání a pak bindingu mezi C a Pythonem dost nenažraná.Pokud to napíšu v C, bude vnitřní smyčka překladačem odrolovaná. Podle mě je to lepší řešení než instancovat templaty pro každý rozměr matice, to povede akorát k obvyklému C++ code bloatu.
max operaci, která počítá minimum, je naprosto zvrhlé. Nebo přetížit strtof, tak, aby na vstupu akceptovalo i inty. Není ale podobným způsobem zvrhlé nazvat * operaci, která není komutativní?
26.6.2009 18:20
Marek Bernát | skóre: 17
| blog: Arcadia
Odporujete si. Vadí Vám, že C++ umožňuje pretypovávanie kvôli zníženej čitateľnosti, ale zavádzať úplne nové operátory by bolo v poriadku? V čom sa to líši? Inak súhlasím, že je škoda, že to C++ neumožňuje, ale je to len syntaktický detail.
Vadí Vám, že C++ umožňuje pretypovávanie kvôli zníženej čitateľnosti,Nic takového jsem z úst ni prstů nevypustil. Naopak jsem psal, že mi vadí, že C++ vynucuje použití přetypování na místech, kde pouze zaclání.
26.6.2009 18:36
Marek Bernát | skóre: 17
| blog: Arcadia
Tak to pardón, mal som zrejme halucinácie, skutočne som ešte pred chvíľou niekde videl Váš príspevok, ktorý to hovoril, ale už ho neviem nájsť o_O
26.6.2009 18:16
Marek Bernát | skóre: 17
| blog: Arcadia
Čo je na tom zvhrlé? Keď už, v matematike sa násobenie značí \cdot, napríklad multiplikatívna grupa (G, \cdot) a rozhodne sa nepožaduje abelovskosť, tá grupa môže rovnako dobre byť grupa matíc ako napríklad reálne čísla bez nuly. Maximálne sa tak dá povedať, že * je štandardný symbol pre násobenie v programovacích jazykoch, ale to neznamená, že nie je rozumné si ho predefinovať, keď sa to hodí; napríklad pri tých maticiach mi to pripadá úplne v poriadku. Aký iný symbol by ste navrhli vy? Navyše je to čisto akademická debata, lebo každý kto používa matice a nevie, že nekomutujú, by sa mal rovno ísť obesiť...
Navyše je to čisto akademická debata, lebo každý kto používa matice a nevie, že nekomutujú, by sa mal rovno ísť obesiť...Trik je v tom, že výpočet, na který se díváte, může být cosi velmi generického a na první pohled prostě nevidíte, že proměnné, které do něj vstupují, jsou matice.
26.6.2009 18:42
Marek Bernát | skóre: 17
| blog: Arcadia
Aby sme si to vyjasnili, tvrdil ste niečo o tom, že človek z matematiky predpokladá nejaké vlastnosti operátorov. Chcel som len oponovať, že ja rozhodne žiadne vlastnosti operátoru * neočakávam, lebo žiadny taký operátor v matematike nepoznám.
Ad kultúrne zvyklosti: môžete dať nejaký príklad? Čo sa týka predefinovania funkcie max na fukciu min, tak v tom Vám nezabráni žiadny jazyk. Ale takú blbosť snáď ešte nikto nikdy nespravil. Rovnako tak operátory použije človek tam, kde si chce situáciu sprehľadniť. Nechce si ju zhoršiť. To by bolo úplne proti zdravému rozumu. Alebo aký problém máte s tými operátormi?
Ad matice: nechápem. Ak programujem tie matice ja sám, tak samozrejme viem, že nekomutujú. Ak je to cudzí kód a potrebujem použiť knižnicu na matice, tak tomu tiež budem rozumieť. Nejak nechápem, ako by mi len tak niekde v kóde mohli vyrásť matice a nevedel by som o tom o_O
26.6.2009 18:44
Marek Bernát | skóre: 17
| blog: Arcadia
Aby som nekecal, operátor * poznám, ale s celkom iným významom, buď komplexného združenia, alebo obecnejšie nejakých automorfizmov, prípadne Hodgeov duál. Ale s tým si násobenie hádam nepopletiem
Chcel som len oponovať, že ja rozhodne žiadne vlastnosti operátoru * neočakávam, lebo žiadny taký operátor v matematike nepoznám.Když budete někomu výraz číst nahlas, nebudete náhodou hvězdičku číst jako "krát"? Pokud ano, není přirozené si představovat, že se opravdu jako násobení chová?
Ad kultúrne zvyklosti: môžete dať nejaký príklad?Třeba "násobení je komutativní, asociativní a má jedničku jako neutrální prvek"?
Rovnako tak operátory použije človek tam, kde si chce situáciu sprehľadniť.S tím zajisté souhlasím. Jen říkám, že to, co je zlepšení a co zhoršení, nemusí být na první pohled vůbec zřejmé. Tedy že přetěžování operátorů není samo o sobě špatné, ale musí se s ním zacházet velmi opatrně a není to také žádná killer feature.
Ad matice: nechápem.Představte si, že vidíte funkci (generickou, v C++ třeba šablonovou) pro řešení soustav lineárních rovnic. Hojně se v ní používají operátory pro sčítání, odčítání, násobení a dělení. Na první pohled ale nevíte, jestli se tato funkce bude vždy volat na klasická čísla, kde se operátory chovají mravně, nebo i na divočejší objekty (můžete mít třeba soustavu rovnic, v níž neznámé budou matice 2×2). Takže pokud se funkci rozhodnete upravit, netušíte, zda se můžete spoléhat na komutativitu násobení nebo ne. (Respektive většina lidí se na ni intuitivně spolehne a pak se možná napálí.)
26.6.2009 19:08
Marek Bernát | skóre: 17
| blog: Arcadia
*: áno budem predpokladať, že je to násobenie, ale nie kvôli matematike, ale kvôli tomu, že som to už videl v iných jazykoch. Nikde inde sa hviezdička na násobenie nepoužíva. Ničmenej, rozhodne nebudem predpokladať ani komutativitu, ani asociativitu, ani neutrálny prvok. To možno tak, keby som matematiku v živote nevidel a bol obmedzený na úroveň žiaka základnej školy...
preťažovanie: Opatrne sa musí zachádzať s kadečím, napríklad aj s nožom, ak sa nechcete porezať. To ale neznamená, že je zlý. A že to nie je killer feature, o to predsa nejde. Je to vlastnosť jazyka, ktorá môže mať užitočné uplatnenie.
matice: Hm, nie je mi teraz na prvý pohľad zrejmé, či funguje bežné riešenie sústavy rovníc ak sa nepracuje nad poľom, ale len nad okruhom (nemôžete deliť, nie sú tam inverzné prvky), takže tak či tak by ste asi museli zmeniť celý algoritmus riešenia (ak vôbec existuje). Ničmenej, ak je to generická funkcia a dostal som ju zo seriózneho zdroja, tak by som si v dokumentácii zistil, ako veľmi generická je. Skutočne stále netuším, ako by sa mi do kódu mohlo o dostať niečo, o čom neviem, ako to funguje. Ledaže vymyslíte ešte vykonštruovanejší prípad (a to tento je vykonštruovaný až až...).
prilis vysoky build overhead" (mnohomegabajtove object fajly a pomale linkovani)
Fakt? Já tedy nevím, ale na mém kompu se kompiluje/linkuje C i C++ zhruba stejně rychle.
A to kolik MB má object file je mi u zadnice a vůbec mě to nezajímá. Proč by mělo?
"nevyhovujici objektovy model" - tj napr nemoznost dynamickeho volani konstruktoru
A k čemupak to potřebujete?
problematicka RTTI
Důsledek toho, že se C/C++ kompilují jako samostatné moduly. tudíž typ struct A v modulu 1 může být něco zcela jiného, než struct A v modulu 2. To je problém společný pro C i pro C++, oba jazyky tento problém mají. A pokud na toto naroubujete RTTIi, které má zjistit typ z modulu 2 používaný v modulu 1 – to chce hodně velkou opatrnost, a proto RTTI to moc neznásilňuje.
Ostatně jakékoli vlastní RTTI, které naroubujete na C, i na C++, bude trpět úplně stejně a nevychytá všechny obecné situace.
neportabilni ABI mezi ruznymi verzemi prekladace
Z toho si nic nedělejte, Céčko také nezaručuje, že modul z kompilátoru verze x.y bude bez problémů v kompilátoru verze x.z. A často to také nechodí.
Protože ho musí při každém buildu překladač zapsat, a linker znovu načíst, například?
Tak to mi ušlo. Budu parafrázovat: Mám databázi, která má 10 GB databázový file. A nijak jsem si nevšiml, že by při každém SQL dotazu databáze celý tento file načetla.
Nechápu, proč by kompilátor, či linker musel načíst celý soubor – on totiž nemusí a v mnoha případech to ani nedělá.
Navíc i kdyby to dělal, tak čtení/zápis z dnešních disků a s cachemi operačních systémů u pár MB nestojí za řeč.
Navíc i kdyby to dělal, tak čtení/zápis z dnešních disků a s cachemi operačních systémů u pár MB nestojí za řeč.Naopak. IMHO v komunikácii s diskom sa trávi najviac času.
26.6.2009 19:28
default | skóre: 22
| Madrid
Fakt? Já tedy nevím, ale na mém kompu se kompiluje/linkuje C i C++ zhruba stejně rychle.
Já mám obdobnou zkušenost jako původní pisatel. Na mém původním PC byla Java 1.4! mnohem rychlejší než g++. Tak jsem si hrál s Javou… Když vyšla pětka a posléze beta šestky, nebylo už absolutně co řešit. Za to dobu, co g++ zkompilovalo (a možná i slinkovalo) Hello World v C++, najel mi celý Javí aplikáč.
25.6.2009 13:06
Jardík | skóre: 40
| blog: jarda_bloguje
dynamickeho volani konstruktoruCo je tím myšleno? Já vám klidně zavolám konstruktor 3x po sobě na stejný kus paměti. Sice ten objekt pak bude rozbitej ...
#include <new>
class Trida
{
// neco ve tride
};
...
char objekt[sizeof(Trida)];
new((void*)objekt)Trida();
new((void*)objekt)Trida();
new((void*)objekt)Trida();
A pokud je tím myšleno volat z jednoho konstruktoru druhý, tak to je na cestě.
Tak to asi nepujde v C++ napsat Factory, hmm, skoda.
Asi mam zvraceny vkus, ale tahle serializace mi nijak extremne oskliva nepripadne. Myslite, ze v cecku by to slo hezcejc?
Tak to asi nepujde v C++ napsat Factory, hmm, skoda.A: Vaše auto je rozbité a nejezdi.
gps_position newg;
...
ia >> newg;
Statická deserializace je samozřejmě triviální. Jak ale ten 'newg' načtete, když místo gps_position ve streamu může být instance 10 jiných tříd?
Pointa je, ze auto neni rozbite. Pokud si vezmu priklad ekvivaletni cecku, tj. hromadu trid, jejichz konstruktory maji stejnou signaturu, tak je naprosto trivialni napsat sablonu funkce, ktera mi bude vytvaret objekty danych trid, a odkazy na ni cpat do nejake hash tabulky.
Asi vas to bude sokovat, ale kdyz by newg byl typem odkaz na zakladovou tridu a
v datech by byl serializovan jeji potomek, tak by se stalo to, co byste (ne)ocekaval - deserializoval
by se ten potomek. Mate to v tom tutorialu, stacilo odrolovat dolu.
As can be seen in demo.cpp, serialization of pointers to derived classes through a base clas pointer may require explicit enumeration of the derived classes to be serialized. This is referred to as "registration" or "export" of derived classes.Tady máte tu odtahovku bez které auto nejezdí, ergo je rozbité.
ar & boost::serialization::base_object<bus_stop>(*this); je hezký? A použít operátor & mi taky nepřijde jako vhodný nápad, zejména když bude napravo int tak to vypadá jako binární AND, nebo deklarace argumentu, která se tam nějak zatoulala ze signatury funkce.
Na rozdil od C, kde je zcela bezna (de)serializace objektu, ktere jste pred tim nikde neregistroval, tam staci serializacni funkci predhodit ukazatel na void a uz to frci samo od sebe. Jestli tohle cini C++ rozbitym, tak je C rozflakano stejnym zbusobem daleko vice.
Co se vam na nem nelibi? Tentyz problem v C resite jak?
Jak jinak, jsme preci v metode serialize, prvni argument je typu Archive, kolem se s nim binarne anduji rozlicne typy, ale kdyz narazite na ar & 1, tak si hned pomyslite, ze tu kdosi kombinuje dve cisla a vysledek pote zahodi. Tahle silena uvaha muze snad platit kdyz takovou konstrukci vidite poprve v zivote, pak mozna budete chvili badat nad tim, co to asi dela. Nasledne nahlednete do dokumentace, zjistite, ze existuje neco jako boost::serialization, proletnete syntaxi a do konce zivota mate vystarano.
tam staci serializacni funkci predhodit ukazatel na void a uz to frci samo od sebe.Samo od sebe ne, když musíte ty třídy (resp jejich factory) napřed registrovat.
Tentyz problem v C resite jak?V C bych to řešil podobně jako C++, tj registrací každé třídy při startupu aplikace. Ale C není objektový jazyk, proto je nesmysl se tak ptát. V pythonu bych to řešil pomocí
__import__(), v perlu pomocí eval {}, a žádná registrace, psaní factories apod by potřeba nebylo.
Ale nic těžkého v tom nehledejte. Zkrátka najít lidi, co umí kvalitně C++ je tak těžké, že prostě nejsou. Dnešní programátoři mají mnohem menší znalosti a schopnosti obecně, takže je utopie najít tým kvalitních C++ programátorů.
Zatímco C je tak primitivní a jednoduché, že se to ještě řada lidí naučí, nebo umí z minulosti. Případně se tím dají nadělat menší škody v případě neznalostí.
Jde jenom o ekonomiku. Musíte stavět týmy z toho co je. Až nebude nikdo umět Céčko, budou se stavět zase z jiných jazyků.
Řada firem je mimochodem z kvality dnešních programátorů velmi rozčarovaná a znám řadu firem, kde betou hlavně starší programátory.
Dnešní programátor se nesetkal s nutností vyladit svoje programy pro slabý hw a málo paměti. Mladí lidé už vlastně ani nepočítají s tím, že by alokace paměti mohla skončit neúspěchem. Navíc počet low level programátorů se zmenšuje, většinou se jede na gc a lepí se volání knihoven. Počet profesionálních programátorů, kteří mají alespoň jakés takés teoretické základy a jsou schopni napsat složitější algoritmus a být si přitm vědomi slabých míst a použít vhodné postupy – to už dnešní programátor neumí a považuje za zbytečnost. A ekonomicky to také pro firmy ve většině případů zbytečnost je, protože stejně většina programátorů jen lepí volání knihoven. To není kritika úrovně programátorů, jen zdůraznění ekonomického vývoje a jeho vlivu.
Zkrátka katastrofální nedostatek C++ programátorů nutí firmy nestavět na něm. Vemte si jak živoří C++ open source projekty (I když tady to je také tím, že u C++ programátorů je mnohonásobně vyšší procento lidí nesnášejících GPL, než u jiných jazyků – a mnoho známých C++ projektů bláhově začla s GPL).
Je třeba hledat nejdříve ekonomické důvody. Lidé znající C++ jsou dost často rozčarování s nízkými platy nabízenými v této republice. A protože dobrý C++ programátor má dost hluboké znalosti, většinou se velmi snadno přeučí na něco lépe placeného (Java, SAP, C#). Navíc většinou už nelpí na tom, že nutně musí vše co dělá být low level, takže to nedělá potíže. A třeba v USA je programátor ovládající Javu + C++ placen výrazně lépe, než programátor umící jenom Javu.
Mimochodem, já programuji většinou v C++, ale také moje pozice není programátor C++. Vlastně nikdy v životě moje pozice nebyla programátor C++, ačkoli jsem v něm moc let dělal velmi často.
Dnes už se moc nenosí „programování v jazyce X“, ale „řešení problému Y“. A když se vhodně vybere, můžete se dostat k čemu chcete.
Zatímco C je tak primitivní a jednoduché, že se to ještě řada lidí naučí, nebo umí z minulosti. Případně se tím dají nadělat menší škody v případě neznalostí.Tohle je jenom iluze. Stejnou vec je v Cecku mnohem narocnejsi implementovat nez v C++ (jak casove tak myslenkove).
Jde jenom o ekonomiku. Musíte stavět týmy z toho co je. Až nebude nikdo umět Céčko, budou se stavět zase z jiných jazyků.Tohle je kec, C++ programatoru je spousta. Ja zacinam ale zjistovat, ze klicove slovo C++ v zivotopise znamena, ze zivotopis konci v kosi, takze pro priste budu uz to ze umim C++ zatajovat.
Zkrátka katastrofální nedostatek C++ programátorů nutí firmy nestavět na něm. Vemte si jak živoří C++ open source projekty (I když tady to je také tím, že u C++ programátorů je mnohonásobně vyšší procento lidí nesnášejících GPL, než u jiných jazyků – a mnoho známých C++ projektů bláhově začla s GPL).Ano, napriklad Mozilla je na tom uplne hrozne :) Ale uznavam ze tohle byla podpasovka (C++ v jejich podani je dost podivny hybrid).
Je třeba hledat nejdříve ekonomické důvody. Lidé znající C++ jsou dost často rozčarování s nízkými platy nabízenými v této republice. A protože dobrý C++ programátor má dost hluboké znalosti, většinou se velmi snadno přeučí na něco lépe placeného (Java, SAP, C#). Navíc většinou už nelpí na tom, že nutně musí vše co dělá být low level, takže to nedělá potíže. A třeba v USA je programátor ovládající Javu + C++ placen výrazně lépe, než programátor umící jenom Javu.Taky ted premyslim na co se preucim (jako Java junior bez zkusenosti mam sanci dostat vyssi plat nez C++ senior). Blbe se vybira na co.
Tohle je jenom iluze. Stejnou vec je v Cecku mnohem narocnejsi implementovat nez v C++ (jak casove tak myslenkove)
Ale tady se nebavíme o snadnosti/obtížnosti implementace, ale naučení se jazyka.
Tohle je kec, C++ programatoru je spousta. Ja zacinam ale zjistovat, ze klicove slovo C++ v zivotopise znamena, ze zivotopis konci v kosi, takze pro priste budu uz to ze umim C++ zatajovat.
Ale většina ho umí na úrovni 5% jeho možností. Tudíž ho vlastně neumí.
Ano, napriklad Mozilla je na tom uplne hrozne :) Ale uznavam ze tohle byla podpasovka (C++ v jejich podani je dost podivny hybrid).
A proto Mozilla ruší všechny projekty kolem, například vykopli Thunderbird, teď mi chtějí zrušit Sunbird, atd.
Nestíhá vyvíjet.
Já se teď zase učím vykopat ze svého počítače všechno na co sáhla Mozilla.
Opravdu nepotřebuji si zavádět programy, které pak Mozilla odstřeluje. Měla to říct hned, a já bych si zvykl a zavedl jiný program, který si to více zaslouží.
Jinak pokud někdo něco začne vyvíjet a pak se toho zbavuje, přestože je o projekty zájem, pak nestíhá.
25.6.2009 08:21
mirec | skóre: 32
| blog: mirecove_dristy
| Poprad
u nas ve firme byly formulovany nasledujici duvody (aby uz se o tom vecne a stale znova nediskutovalo), proc se pouziva jako primarni jazyk C:
Pouze u GUI se muselo sahnout k c++, protoze vetsina toolkitu v C neni k mani (gtk_bylo_zkouseno_a_propadlo_na_cele_care)
Ani jeden z těch důvodů není důvod pro upřednostnění C oproti C++, protože Céčko neposkytuje žádné výhody z uvedených bodů oproti C++. Na hodně exotických architekturách by se dala uvažovat o platnosti druhého důvodu.
Jinak samozřejmě poslední bod neposoudím, protože nevím, co kovbojové ve Vaší firmě mají za firemní filozofii – ale to je ryze subjektivní důvod.
obdivuji, pokud je někdo opravdu schopen dělat obojí v jednu chvíli.To já taky a jednou bych se to chtěl naučit. Imho to za to stojí, protože když se člověk naučí u objektovýho programování přemýšlet i nízkoúrovňově, je fakt king...
Ad 1) Pak volím buď asm, nebo C++. Ale pro asm je důvod tak v 0,0001%.
Jinak pokud potřebuji slušnou rychlost a rychlé výsledky, pak volím též C++.
) a pouze 16-bit immediate hodnoty, takže člověk musí do registrů loadovat velký čísla nadvakrát. Oproti x86 assembly něco naprosto jinýho. Navíc Sony pro psp upravili ELF formát do poměrně obskurně relokovatelné podoby, a kdo se v tom pak má vyznat...
Nadruhou stranu třeba teď makám na kernel-mode modulu do PSP (MIPS 4k záležitost), a tam se čisté C jeví mnohem výhodnější, vzhledem k tomu, že potřebuju co možná přímý přístup do paměti a celá věc je mnohem víc nízko-úrovňová, občas se nevyhnu i nějakému tomu assembly*. V tomhle případě by mě C++ zbytečně zdržovalo-
Proboha, kde by C++ zdržovalo? A mimochodem, kde má C++ problém s přístupem do paměti, případně s integrací asm?
Já pořád nevidím jedinou reálnou výhodu C pro tento případ oproti C++.
Proboha, kde by C++ zdržovalo?Ne výpočetně, zdržovalo ny mě při implementaci (v tomto případě)
A mimochodem, kde má C++ problém s přístupem do paměti, případně s integrací asm?C++ by samozřejmě taky šlo použít, jenže je to imho v tomto případě zbytečný overkill. Ten modul bude plugin na zobrazování titulků do vestavěného přehrávače a bude velmi velmi jednoduchý. Celá věc spočívá v tom, že naháčkuje pár funkcí OS (takže kdykoli nějaký modul zavolá danou funkci OS, provede se prvně můj kód a odchytim parametry).
Já pořád nevidím jedinou reálnou výhodu C pro tento případ oproti C++.
Kde bych tam mohl použít nějak smysluplně C++? Možná tak na parsing titulků a jejich uchování v paměti, ale na to bohatě stačí i jednoduchá struktura, takže nebudu kvůli tomu hrotit C++...To je spatna otazka. Jaky mas duvod zustavat u Cecka? Je mozne ze z velke casti skoncis u v podstate Ceckoveho kodu kde misto Ceckoveho pretypovani pouzijes C++ pretypovani, misto nekterych ukazatelu reference, ale i tohle prinasi dostatek vyhod k tomu abys nezustaval u Cecka.
Na trhu práce se musí lhát. Musíte říct to, co chtějí slyšet. Proč to neříct naplno?
Jedna firma mě vyhodila málem za to, že jsem mluvil o zkušenostech z minulé firmy, kde jsem se prořekl, že jsme honili Apache na Linuxu a Windows. Prý jsem lhář, protože Apache na Windows nechodí.
Nevyberete si. Ideální je zjistit si něco o firmě, zjistit jestli mám zájem pracovat a naservírovat jim co chtějí slyšet.
Je to smutné, ale dnes vás stejně většiou berou buď personalistky, které by nahradil automat porovnávají zkratky v CV a v požadavcích, které dostanou. A oni Vás obor neznají.
A nebo lidí, kteří mají velmi úzký rozhled, a je zbytečné jim ho brát.
Na trhu práce se musí lhát. Musíte říct to, co chtějí slyšet. Proč to neříct naplno .
v tom Vam davam 100% za pravdu a dodavam, ze to nikdy nebylo jinak. Ja jsem u sveho prvniho pohovoru (byl to kadrovak v CKD) plamene chvalil politiku komunisticke strany - slo o to, ze byla sance na podnikovy byt.
C++ by samozřejmě taky šlo použít, jenže je to imho v tomto případě zbytečný overkill.
Já chci jenom lidi dotlačit k tomu, aby si uvědomili, že použití C není nikdy objektivně výhodnější, než C++. Neexistuje naprosto jediný objektivní argument, proč použít C, když můžete C++. Nenajdete takový. Všechny pokusy tady obhájit C proti C++ by neobstály objektivní test. C nemá naprosto žádnou objektivní výhodu, kterou by mohlo nabídnout oproti C++ na žádné rovině a v žádném případě. Ani by to nebylo overkill.
Chci lidi dotlačit k tomu, aby konečně pravdivě přiznali: „Používám C, protože ho chci používat. Jiný důvod nemám.“. Jak vidíte, zatím tu žádný jiný argument proti C++ neobstál a ani nemůže obstát.
Samozřejmě si používejte C jak je Vám libo. Není důvod, proč byste neměl.
A věřte, že i v maličkém projektu je C++ mnohem příjemnější.
Volba jazyka je pro většinu lidí věcí preference.
to co tu celou dobu vykladate je pro me nepresvedcive. Problem vidim v tom, ze operujete s pojmy jako 'objektivni argument'. Pouziti jakekoliv jazyka se kona v realnem svete, a tento svet neni jen objektivni a spociva vicemene v interakci subjektu mezi sebou a z konfrontace techto subjektu s tvrdymi fakty (coz vy patrne nazyvate objektivni argumenty).
A na zaver pak uvedete ten 'objektivni argument': A věřte, že i v maličkém projektu je C++ mnohem příjemnější.
Pro pouziti nejakeho jazyka mohou existovat _pouze_ racionalni argumenty. A ty zde byly jiz dostatecne prezentovany.
Objektivní argument je argument, který lze objektivně prokázat – například testem, pokusem, či jiným experimentem. Tedy objektivní argument je argument, u kterého nezáleží na tom, jak se určitý člověk vyspí, a nebo jestli má rád Spartu, či Slávii, a nesnáší C++ za to, že jeho název měl třeba konkurenční tým na tričku.
Objektivní argument = dokazatelný argument.
Jakýkoli objektivní pokus, experiment, atd.. by neprokázal výhodnost C. Proto také řada projektů přepisuje z C do C++. Například Firebird přepsal do C++.
Subjektivně samozřejmě existuje řada argumentů pro C, jako například „nesnáším C++“, „chci dělat v C“, a nebo „líbí se mi C“.
Pro použití jazyka neexistují pouze racionální argumenty, ale také emocionální argumenty, které právě zde byly pro C prezentovány v míře více, než hojné. To podtrhnuté slovo pouze je hodně lživé ve Vašem posledním odstavci.
25.6.2009 14:13
xxx | skóre: 42
| blog: Na Kafíčko
ja si myslim, ze je to ok, ze rezolutne obhajujete nejaka stanoviska, jsem natolik pri smyslech, ze vim, ze jsem jako mlady clovek videl svet take tak. A dokonce si myslim, ze to tak ma byt, kdo jiny nez mladi schopni lide bez zavazku mohou pohnout tento svet snad zase k lepsim zitrkum.
Asi to nema cenu Vam to rikat, ale kdyby nahodou - vytisknete si tuto diskuzi, zalozte si ji a podivejte se na to za 20 let. Vim, ze se na podobne, dobre minene rady neda nic rici, uvadim to zde, protoze mi neco takoveho rekl kdysi muj prvni nadrizeny a ja se nad tim trochu zamyslel. Mozna ze to udelate take, a pak jsme jako starsi kolega splnil.
Aby bylo jasno – použijte si C i C++. C i C++ se dají použít i na osekané knihovně.
pouze 16-bit immediate hodnoty, takže člověk musí do registrů loadovat velký čísla nadvakrátTo má PowerPC taky a taky mě to dost sejří, i když samozřejmě chápu důvod, proč je to tak udělané. Načíst navrch, načíst dospod, otočit o 32 bitů, načíst navrch, načíst dospod… To je vlastně hlavní důvod, proč při programování v jazyku symbolických adres preferuji 32b mód před 64b – načtení je na dvě operace místo na pět.
.
Asi jo, turingove-orientovane programovani bylo v mode tak pred 50ti lety.
.
Pokud bych si měl vybrat, tak buď použiju čisté C a "třídy" si udělám přes pointery na funkce a nebo použiju pokud možno co nejčistší C++ (popř. s něčím jako boost). Přesněji řečeno bych si nevybral ani jedno, protože nechci dokola řešit, že mi někde přetéká index nebo odkazuju pointrem někam doprdele, ale někdy člověk holt musí.
Bohužel ta pravidla byla už v době tvoření stará tak 10 let, takže dnes nemají naprosto opodstatnění. Kdysi jsem chtěl s Mozillou a kódem dělat, ale pak jsem si řekl, tohle já fakt nemusím.
To je právě o tom, že Céčkaři se pokusili ohnout C++ na svoje Céčko. Nepochopili většinu věcí v C++ a tak si zavedli tato pravidla.
Jinou hnusárnou je „embedded C++“, který je o něčem podobném.
Výjimky mají určitou režii, nicméně stojí za to. Je to jedna z možností, jak psát rychlejší a bezpečnější programy.
Zkuste si napsat někdy program bez výjimek, který by naprosto důsledně ošetřil všechno. To jest kontroloval všechny návratové hodnoty i chybové kódy. Pokud to uděláte důsledně, pak je jednak program dost těžko čitelný. Bude zaneřáděn spoustou ifů a switchů, které nemají jiný úkol než kontrolovat chyby. Díky tomu také kód bude neustále vykonávat nadbytečné ify a switche, které budou program zpomalovat, byť mírně.
S výjimkami je kód velmi přehledný, a pokud nenastane chyba, kód se nezdržuje s žádnou kontrolou hodnot.
Výjimky jsou dnes v C++ velmi úsporně napsány. Na rozdíl od mnoha jazyků typu C#, Python, Java a další nemusí nést výjimky žádnou jinou, než typovou informaci. Nemusí mít nutně přibalenou zprávu, pokud nechcete, ani nemusí obsahovat záznam o všech vnořených voláních na stacku.
Třeba Microsoft ve svých Windows v kernelu používá výjimky i pro thready, které mají jednu stránku paměti jako zásobník a není s tím sebemenší problém. Proč by také měl?
goto nedostřelí mimo vlastní funkci, výjimka ano
Takže sice třeba ošetříte chybu pomocí goto, ale zase jen uvnitř jedné funkce. Takže musíte vrátit nějakou chybovou návratovou hodnotu, nebo nastavit chybobý kód. Nadřazená funkce, která funkci volala se musí podívat, jestli to skončilo chybou – a případně na to nějak reagovat a zase vrátit návratovou hodnotu, případně nastavit někde příznak chyby. Pak funkce o úroveň výš, která volal nadřazenou funkci opět musí detekovat, zda došlo k chybě, atd..
Zatímco u výjimky je to jednoduché – chyba? vyhodím výjimku. Funkce se nemusí o nic starat, a jestli je do sebe vnořeno deset volání funkcí a chybu umí ošetřit až ta funkce o deset úrovní výš – těch devět se o chybu nijak nestará. Tím se program velmi očistí od zbytečných vícenásobných detekcí chyb – kód se tím zrychlí, protože v tomto případě ušetříte devětkrát if a goto. A těch devětkrát if se provede ať chyba nastala, nebo ne. V případě výjimek a bezchybového stavu se ušetří v kódu 9× if, které tam nebude.
Tím se program velmi očistí od zbytečných vícenásobných detekcí chybTo že vám _TEXT nabobtná o nějakých 10-50% díky unwind tabulkám, které kompilátor samozřejmě musí vygenerovat i pro funkce kde nejsou potřeba, vám nevadí? Nebo o tom snad ani vůbec nevíte, když stále vehementně tvrdíte že C++ nemá žádnou režii navíc?
kód se tím zrychlí, protože v tomto případě ušetříte devětkrát if a goto.Jen tak mimochodem, kolik jste už napsal aplikací, kde jedna atomická akce (u které chcete jako u celku rozhodnout jestli uspěla nebo selhala) vyžadovala devítinásobný nesting funkcí, z nichž každá mohla uspět nebo selhat?
V případě výjimek a bezchybového stavu se ušetří v kódu 9× if, které tam nebude.Ano, za cenu spousty binárních zvratek v kódovém segmentu, za cenu potřeby pěkně macatého runtime (koukal jste vůbec na zdrojáky?), který ty zcela neportabilní blitky bude interpretovat, ušetříte pro každé volání vnořené funkce JEDEN korektně predikovaný if, který pravděpodobně na čemkoliv od pentia 1 nahoru bude spárován s předchozím
or eax, eax, takže ušetříte maximálně 1 hodinový cykl. Na druhou stranu ty exception tables vám dosti výrazně sníží code density, takže vám pak třeba klidně vnitřní smyčka vypadne z L1 cache, a celý kód se naopak o 50% zpomalí, haha. To vám nevadí? Inu, C++ programátoři..
Tohle samozřejmě platí pro normální programy, nikoliv pro embedded zařízení s daleko kontrolovanějším prostředím.Já se právě snažím zdůvodnit, že udělat kontrolovanější prostředí na desktopu nestojí o moc námahy navíc.
%08x už vůbec není problém... Ale je jasný, že tohle nikdo dělat nebude, takže v každým případě má pravdu kolega pht, když říká, že to je koncepčně nahov..., ehm, nahouby...
Printf může selhat například pokud píše do roury nebo socketu, který umře.Ja myslel ze pak dostanu SIGPIPE, takze navratovy kod printf() resit netreba..
goto ale nevola destruktory trid a neresi dealokaci objektu. Takovy to "divny Cko" s tridama a milonem maker preprocesoru je mozna rychlejsi nez C++, ale kod je totalne neprehlednej(alespon pro me), pro makra preprocesoru se negeneruje dubug info, takze tomu nerugumi gdb a hlavne kdyz ma aplikace nekolik GB RAM ve swapu tak je uplne jedno je jestli pouzivate SSE instrukce nebo ne.
Takovy to "divny Cko" s tridama a milonem maker preprocesoru je mozna rychlejsi nez C++No to teda imho není.
25.6.2009 18:14
Fluttershy, yay! | skóre: 93
| blog:
25.6.2009 11:21
unknown_ | skóre: 30
| blog: blog
Doufam, ze nejsu sam.
25.6.2009 12:40
Jardík | skóre: 40
| blog: jarda_bloguje
v čistém C++ (bez char*, printf, etc...)Bez char* se snad ani obejít nedá. I když v C++ napíšete
std::string bla("bla"), tak jste zrovna použil argument typu const char* pro konstruktor std::string. Osobně jsem hlasoval pro v C++, ale včetně vlastností a funkcí z Céčka, s tím, že céčkové hlavičkové soubory includuju přes ty z c++ (tj. místo např string.h includuju cstring).
Není důvod se připravovat o funkce z Céčka. Například si myslím, že printf je v mnoha případech šikovnější, než operátory <<.
Jak třeba napíšete funkci, která modifikuje výstup, modifikuje formát výstupu a na konci ho zase vrátí do původní podoby?
Já to psal tak, že jsem si napsal třídu ios_saver, která v konstruktoru uložila formáty a v destruktoru je obnovila, ale přijde mi to přes ruku.
void neco_vypis()
{
ios_saver __ios_saver(::std::out);
....
}
To už mě přijde šikonvnější použít nestavové printf v mnoha případech. Později jsem si také svůj vlastní printf nad ostream napsal. Můžete se u toho skvěle vyblbnout a syntakticky vyřádit. Ideální je nepoužít va_arg, a tedy ani ellipsis ve svém printf, stane se to tak typově bezpečným.
stane se to tak typově bezpečnýmDnesni prekladace umi kontrolovat, zda typy argumentu odpovidaji formatovacimu retezci, pokud je znam pri prekladu. U GCC si to muzete zaridit i pro sve vlastni funkce.
Ono se to ale bez ellipsis zjednoduší. Například jsou zbytečné prefixy l a h, když vlastní printf funkce zná typy parametrů. Není tedy potřeba mu napovídat v parametrech. Hodně se to zjednoduší a pročistí. Například mu nemusíte ani napovídat, jestli jste předali ukazatel na char*, nebo wchar_t* a řadu dalších věcí.
Kompilátor sice zkontroluje typy, ale tuhle typovou informaci už do Céčkového printf nepředá. Takže stejně musíte ve fromátovacím řetězci funkci printf napovídat a zbytečně tam typovou informaci zanášet.
Hlavní devizou vlastní, typově bezpečné funkce printf je kromě typové bezpečnosti také přenositelnost programů. Tím, že formátovací řetězec očešete o všechnu typovou informaci, je to najednou nezávislé na platformě. Například %d bez problémů přijme jak int, tak long, tak long long, tak jakýkoli jiný integer typ, pokud ho kompilátor má. Zatímco klasická Céčková printf funkce když vidí %d a vy jí předáte parametr typu int32_t, tak to může, ale nemusí dopadnout dobře – podle toho na jaké platformě.
Není tedy potřeba mu napovídat v parametrech.Se mi líbí jak C++ vždy spolehlivě uhodne jak NECHCI formátovat floaty :)
C++ je uplne nejvic nejlepsi jazyk, protoze je uplne nejvic nejrychlejsi, nejcitelnejsi a ma nejchytrejsi prekladaceNe, C++ je lepsi volbou nez Cecko v pripadech kdy neni Cecko jedinou moznosti.
smula je, ze jenom identity Let_Me_Be a Miloslav Pankrac ho umi poradne pouzivat a ostatni jsou loseri, kteri nicemu nerozumi a vubec nic nechapouC++ ma v ankete docela dost procent (uprimne vic nez bych cekal), takze asi nejsme jenom dva.
Shrneme:
Ad 1) Mezi C a C++ nemá objektivně C žádnou výhodu. Nic jiného o dalších jazycích tu nebylo tvrzeno. Důvod pro výběr jazyk C oproti C++ je ten, že se některým lidem jazyk C líbí, a chtějí v něm dělat, což je naprosto v pořádku a nechť C používají. Bylo by ale třeba aby nešířili lži o výhodách C, které nejsou.
Ad 2) Smůla je, že deda.jablko je extrémista a vidí závěry, které nikde nejsou.
Mezi C a C++ nemá objektivně C žádnou výhodu.
26.6.2009 09:41
Marek Bernát | skóre: 17
| blog: Arcadia
Zamysli sa trochu prosím ťa. V C++ je tisíc spôsobov ako spraviť načítanie vstupu. V C takisto. To, že zoberieš najrýchlejší spôsob v C a najpomalší v C++ a z toho usúdiš, že C je lepšie v tomto ohľade je predsa uvažovanie na úrovni toho hrocha čo si spomínal Nikto ťa nenúti používať streamy, keď na to nie je dôvod, normálne použiješ scanf/printf. Rovnako tak výnimky, ale to už bolo rozobrané inde...
Aby sme to zhrnuli, skutočne ťažko sa ti bude hľadať argument pre to C, lebo C++ je jeho rozšírením (všimol si si to C v názve C++?), teda nadmnožinou a ak chceš, môžeš programovať takmer v čistom C a len prekladáš C++ kompilátorom. Prečo si to ľudia nie sú schopní uvedomiť nechápem...
Castecne souhlasim. Prvni cast shrnuti tohoto problemu jste udelal - C++ je (vicemene) nadmnozina C, takze se v nej da programovat i zpusobem jako v C.
Druha cast shrnuti tohoto problemu spociva v tom, ze ne vzdy a ne kazdy zjevne vnima jazyk, ktery umi nadmnozinu, jako lepsi. Napr. oba Martinove vyznavaji Haskell, ktery je ciste funkcionalni a tim programatora _omezuje_. Ja jsem zastancem spis multi-paradigmatickych jazyku, jako je Python a Common Lisp. Nerikam, ze ty duvody (proc maji Martinove radi FP a ja ne) jsou tytez jako proc maji radi C a neradi C++ (ono ostatne tech duvodu, proc nam muze vice vyhovovat jednodussi jazyk je rada), ale jen to ukazuje, jak subjektivni cela tato zalezitost je.
26.6.2009 18:30
Marek Bernát | skóre: 17
| blog: Arcadia
Samozrejme, že výber jazyka je čisto subjektívny, o tom sa nemá zmysel baviť. Hovoril som len o vzťahu C <-> C++. Ja osobne mám rád všetky netriviálne jazyky LISPom počnúc, Haskellom pokračujúc a smalltalkom končiac, ale keď sa jedná o rýchle napísanie programu, tak často siahnem po C++, lebo s ním mám najviac skúseností, alebo pythone, lebo sa v ňom pohodlne robí kopa vecí. Čím chcem povedať, že podľa mňa neexistuje vyložene zlý jazyk a je v záujme programátora mať nadhľad a použiť na daný problém správny nástroj (dokonca aj Java a PHP majú svoje uplatnenie, akokoľvek tie jazyky neznášam) a nie tlačiť všade (vrátane tejto diskusie) _svoj jediný správny jazyk_.
Tak to zas ne! Vyse tvrdim (a to mam namerene), ze programovani pomoci streamu je pomalejsi, nez ekvivalentni kod v Cecku. Stejne tak vyjimky prinasi overhead (a dost lidi je spatne pouziva).
Jenže:
1) to máte vyzkoušené na gcc (tedy pak to není vlastnosti C++, ale gcc), a nebo obecně?
2) v C++ klidně můžete použití stejné věci jako v C, nikdo Vás do streamů nenutí
3) výjimky vytváří overhead, ovšem pouze pokud jsou vyhozeny. pokud ve vašem programu nenastane důvod k vyhození výjimky (což je ve většině případů), použití výjimek vede k rychlejšímu, čitelnějšímu a spolehlivějšímu kódu. to, že spousta lidí výjimky špatně používá je fakt.
Proč si většina lidí myslí, že programovat v C++ znamená nepoužívat C knihovny, když je to vhodné? Opravdu v C++ někdo nutí používat C++ streamy? Osobně považuji C++ streamy za nejméně povedenou část C++ a sám se jim dost vyhýbám. Podle mě jsou nedomyšlené.
Já netvrdím, že lidi musí psát v C++, klidně si piště v C. Naprosto pochopím, že řadě lidí je C++ nesympatické a proto píší v C. Pro mě je toto dost pádný argument, proč by měli používat C. A ten argument beru.
Stejně tak se mi líbí i Vaše argumenty. Něco jste si ověřil a jdete po tom.
26.6.2009 09:51
Marek Bernát | skóre: 17
| blog: Arcadia
Haskell nie je odpoveď na všetko. Je to len ďalší jazyk, v ktorom sa niektoré veci robia lepšie a iné horšie. Porovnávať ho s pythonom mi príde úplne mimo.
Mimochodom, ak chceš peknú úlohu, tak si skús naprogramovať nejaké grafové algoritmy v Haskelli. Prídeš na to, že reformulovať bežné algoritmy (ktoré sú čisto imperatívne) je vysoko netriviálne (ak chceš použiť funkcionálne programovanie a nie len threadovať stav cez monady, atď), takže minimálne v dnešnej dobe by som na túto oblasť Haskell nepoužil ani omylom. A nielen na túto. Ničmenej, na kopu iných vecí je Haskell skvelý a hlavne je to super hračka Ale to isté (plusy aj mínusy, len v iných oblastiach) platí aj pre python.
26.6.2009 14:05
Marek Bernát | skóre: 17
| blog: Arcadia
Nom, problém je v tom, že všetky grafové algoritmy, kde napríklad hľadáš najkratšiu cestu, alebo inak prehľadávaš graf, spoliehajú na to, že si vieš pamätať množinu navštívených vrcholov. Imperatívne sa to rieši pohodlne pomocou side-effectov (modifikujem si globálne pole navštívených vrcholov), v Haskelli sa to dá emulovať rôzne, buď posielaním toho zoznamu vrcholov ako argumentu a to samozrejme veľmi zhorší zložitosť, alebo pomocou monádov, ale to tiež nie je úplne ono. Ale ani jedno nepovažujem za veľmi funkcionálny prístup. Funkcionálny prístup by bolo definovanie grafu pomocou konštruktorov ako "prázdny graf" a "vrchol a hrany z/do neho + ďalší graf" a pracovať na tom, pomocou funkcií typu najkratšia cesta :: Graf -> [vrchol], ktoré budú pekné rekurzívne a jednoriadkové, ako je v Haskelli zvykom pri práci napríklad nad zoznamami, alebo stromami. Chceš mi povedať, že toto je jednoduché? Mne osobne to totiž tak nepripadá a našiel som články len pár rokov staré, ktoré sa práve týmto zaoberajú (volá sa to induktívne deklarované grafy).
Ale ak máš nejaký pekný spôsob ako implementovať grafové algoritmy funkcionálne a v dobrej zložitosti, tak som samé ucho.
v Haskelli sa to dá emulovať rôzne, buď posielaním toho zoznamu vrcholov ako argumentu a to samozrejme veľmi zhorší zložitosť
Často se to také řeší přes mapu (Data.IntMap) nebo přes množinu (Data.IntSet).
alebo pomocou monádov, ale to tiež nie je úplne ono
No, ono to není až taková hrůza.
26.6.2009 15:48
Marek Bernát | skóre: 17
| blog: Arcadia
Nehovorím, že je to hrôza, ale je to napasovanie imperatívneho programovania na funkcionálne. Nesnažíme sa vymyslieť niečo nové, ale len hľadáme metódy, ako donútiť haskell, aby spracoval staré známe imperatívne algoritmy. Ako funkcionálne naprogramované grafy si skôr predstavujem niečo takéto (článok). Byť schopný použiť štandardné funkcionálne mapy, foldy, filtre, atď na štruktúre grafu, to je skutočná sila Haskellu. A nie monádovo-emulované imperatívne programovanie, to už si rovno tie veci napíšem v C a hotovo...
Díky za odpověď a odkazy, na články se podívám.
nie len threadovať stav cez monady
Ale i to je funkcionální programování.
26.6.2009 13:57
Marek Bernát | skóre: 17
| blog: Arcadia
Asi sme sa nepochopili. Vďaka monadom zostáva síce haskell čistý funkcionálny jazyk, ale to nič nemení na tom, že Vám umožňujú písať imperatívne a nemusíte rozmýšľať nad implementáciou štruktúr a algoritmov funkcionálne (tj. jednoduchý konštruktor využívajúci rekurziu a rekurzívne algoritmy nad danou štruktúrou). Je jasné, že je to výhoda, lebo nie všetko sa dá robiť pohodlne funkcionálne, ale na druhej strane to človeka pripraví o kopu výhod funkcionálneho programovania.
výjimky vytváří overhead, ovšem pouze pokud jsou vyhozeny. pokud ve vašem programu nenastane důvod k vyhození výjimkyTo je sice názor velmi běžný, ale bohužel zcela mylný: (1) Obsluha výjimky stojí prostor. Prostor ovlivňuje čas: zbytečný kód zaplňuje cache, nějakou dobu trvá, než se načte do paměti, snižuje efektivitu TLB atd. (2) Existence out-of-line obsluhy výjimek v některých případech zabraňuje optimalizacím: překladač si v mnoha místech nemůže dovolit zkratku, neboť přestože ví, že v obvyklém běhu kódu se nějaké operace "navzájem požerou", při vykonání výjimky tomu tak není.
Mezi C a C++ nemá objektivně C žádnou výhodu.ISO C++ narozdil od ISO C neumi makra s vypustkou, __func__, #warn, automaticka pole, pojmenovane inicializatory, literály strukturového typu a nektere dalsi veci majici vliv pri optimalizacich, jako je restrict a standardizovana #pragma. Tucne veci povazuji za nejuzitecnejsi, makra s vypustkou se daji vetsinou nahradit sablonami.
C++ je uplne nejvic nejlepsi jazyk, protoze je uplne nejvic nejrychlejsi, nejcitelnejsi a ma nejchytrejsi prekladaceA tos pochopil až teď? /povzdech.../ :P
26.6.2009 14:11
Marek Bernát | skóre: 17
| blog: Arcadia
Vynikajúca kniha je Thinking in C++; myslím, že je dokonca voľne šíriteľná, ale nie som si teraz istý. Preberajú sa všetky záludností C++ do hĺbky a je v tom kopa cvičení, takže až ju celú prelúskaš, môžeš si byť istý, že ťa v tom jazyku len tak niečo nezaskočí. Ale upozorňujem, že to môže byť dosť nudné, v závislosti na tom, čo si predstavuješ pod "naučit C/C++".
26.6.2009 15:48
Fluttershy, yay! | skóre: 93
| blog:
Taky se zrovna snažím naučit C/C++. Jako naprostý začátečník jsem samozřějmě chtěl hned začít s C++, protože jsem se někde dočetl, že je to prostě ten nejlepší jazyk. Ale potom jsem zjistil, že bude lepší začít s něčím snažším, abych se naučil aspoň základy programování. Rozhodoval jsem se mezi Pascalem a obyčejným C. Nakonec jsem si vybral C, abych třeba někdy v budoucnu mohl snadněji navázat na C++. Takže jsem si koupil Učebnici jazyka C od Pavla Herouta. Jazyk popisuje docela stručně a obsahuje asi 120 programovacích cvičení. Myslím, že tahle učebnice dost naučí a je vhodná i pro naprosté začátečníky, akorát to chce trpěliivost. Já jsem třeba měl hned na začátku problém s entrem uloženým do bufferu:)
26.6.2009 18:13
Jardík | skóre: 40
| blog: jarda_bloguje