abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
dnes 13:00 | Zajímavý software

Společnost ISFG (Information Systems Factory Group) představila elektronickou spisovou službu SpisUm. Jedná se o open source řešení. Zdrojové kódy jsou k dispozici na GitHubu. SpisUm je postaveno na open source platformě Alfresco.

Ladislav Hagara | Komentářů: 0
dnes 02:22 | Zajímavý software

Video Trimmer je jednoduchá grafická aplikace umožňující vyříznout část videa. Vydána byla nová verze 0.2.0. K dispozici je již také ve formátu Flatpak na Flathubu.

Ladislav Hagara | Komentářů: 1
dnes 01:11 | Komunita

Byla vydána první RC verze svobodného kancelářského balíku LibreOffice 7.0. Dle plánu by finální verze měla vyjít počátkem srpna. Diskusi rozpoutalo označení Personal Edition. Dle prohlášení rady The Document Foundation označení vychází z pětiletého marketingového plánu (pdf). V plánu je LibreOffice Personal a LibreOffice Enterprise.

Ladislav Hagara | Komentářů: 9
včera 16:44 | Nová verze

Byla vydána nová major verze 3.15.0 grafického vývojového prostředí a platformy Gambas (Wikipedie) založené na interpretru programovacího jazyka Basic s rozšířením o objektově orientované programování. Přehled novinek v poznámkách k vydání. Zdrojové kódy jsou k dispozici na GitLabu.

Ladislav Hagara | Komentářů: 0
včera 15:55 | Nová verze

Byla vydána verze 2.6 svobodného nelineárního video editoru Flowblade (GitHub, Wikipedie). Přehled novinek v poznámkách k vydání a ve videu na Vimeu.

Ladislav Hagara | Komentářů: 2
včera 01:11 | Zajímavý článek

Na webu Libre Graphics World vyšel dvoudílný rozhovor s Paulem Davisem, hlavním vývojářem DAW Ardour. První část se zabývá především vývojem právě Ardouru a přepisem jeho částí, druhá část se věnuje jednak zvuku na Linuxu (PipeWire, PulseAudio, JACK) a jednak interoperabilitě s jinými DAW.

Fluttershy, yay! | Komentářů: 2
5.7. 15:55 | Komunita

V oblasti informačních a komunikačních technologií probíhají změny v názvosloví. Ke změnám se tento týden oficiálně vyjádřil CTO Red Hatu Chris Wright: nahrazením problematických slov se open source stane inkluzivnější. Také vývojáři Linuxu diskutují o inkluzivní terminologii. Do jádra se dostane soubor inclusive-terminology.rst.

Ladislav Hagara | Komentářů: 55
5.7. 13:55 | Nová verze

MaXX Interactive Desktop (navazující na projekt 5dwm.org) je linuxový port IRIX Interactive Desktop, desktopového prostředí z pracovních stanic Silicon Graphics. Vzniká s vědomím a svolením SGI, ale proto je také licence částečně proprietární. Aktuální, nově vydaná verze je 2.1. Do konce roku je plánováno přepracování grafické konfigurace, správce plochy a správce souborů.

Fluttershy, yay! | Komentářů: 6
3.7. 19:44 | Nová verze

Byla vydána nová verze 1.7.0 svobodného multiplatformního Markdown editoru Zettlr postaveného na platformě Electron. Podrobný přehled novinek na GitHubu.

Ladislav Hagara | Komentářů: 1
3.7. 08:00 | Humor

Linus Torvalds se v květnu v rámci oznámení o vydání Linuxu 5.7-rc7 pochlubil svým novým hlavním počítačem: Poprvé za 15 let není uvnitř Intel, není to ještě ARM, je to AMD Threadripper 3970x, allmodconfig je třikrát rychlejší. Následně v rozhovoru pro server ZDNet svůj nový počítač podrobně popsal. Linus Sebastian z YouTube kanálu Linus Tech Tips na základě tohoto rozhovoru včera na YouTube publikoval video s názvem Linus staví Linusův nový počítač.

Ladislav Hagara | Komentářů: 18
Používáte některé open-source řešení [protokol] pro šifrovaný instant messaging?
 (23%)
 (30%)
 (4%)
 (11%)
 (18%)
 (6%)
 (13%)
 (25%)
Celkem 308 hlasů
 Komentářů: 32, poslední 28.6. 17:51
Rozcestník

Malý C/C++ quiz

19.2.2009 19:55 | poslední úprava: 31.8.2009 14:21

Tento blog byl smazán autorem

       

Hodnocení: 54 %

        špatnédobré        

Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

Komentáře

Vložit další komentář

19.2.2009 21:19 Let_Me_Be | skóre: 20 | blog: cat /proc/idea/current | Brno
Rozbalit Rozbalit vše Re: Malý C/C++ quiz
1-4 by chtelo trochu lepe specifikovat (moc nechapu co se v tech vyrazech muze a nemuze objevit) 5 je dost zavisla na konkretnim procesoru 7 je zavisla na platforme (vazba na x86 nestaci) 8 je opet mozna zavisla na platforma (ale tady nejsem jisty)

Jinak celkove bych ty otazky kategorizoval jako dulezite zakladni znalosti (snad krome c. 5 a c. 6).
Linked in profil - Můj web - Nemůžete vyhrát hádku s blbcem. Nejdřív vás stáhne na svoji úroveň a pak ubije zkušenostmi.
19.2.2009 22:21 Deleted [8409] | skóre: 14 | blog: darkblog
Rozbalit Rozbalit vše Re: Malý C/C++ quiz
Ad 1, 2) Opravdu jen plus, minus a bitové operace (xor, and, shift, not, atd)

3) Nechci radit, cokoliv, ale jen jedna podmínka :)

4) To samé, kdybych specifikoval, tak možná odhalím princip. Až tu bude řešení tak mě můžete bombardovat :)

5) Právě tady bych postupoval úplně obecně. Řekl bych, že existují jen 2 možnosti jak to optimalizovat. PS: Vykašlete se na zarovnávání ukazatele a čtení jako WORD nebo DWORD, to není hlavní pointa.

7) Je to o architektuře x86, každý překladač by měl mít stejný výsledek (doufám).

8) Pokud bereme float jako normalizovane IEEEx.x, tak bych řekl, že by to na každé platformě, kde je int 32 bitů (mohl jsem tam napsat radší int32_t) mělo být stejné. Ale pokud někdo nezná, jakým způsobem funguje float, tak rovnou přeskočit:)

Já osobně bych kategorizoval jako základní všechno kromě 4, 6 a 8.
19.2.2009 22:47 Jiri Uncovsky | skóre: 5
Rozbalit Rozbalit vše Re: Malý C/C++ quiz

7) ne, to nezávisí na architektuře, ale jen a jen na překladači.

19.2.2009 22:49 Deleted [8409] | skóre: 14 | blog: darkblog
Rozbalit Rozbalit vše Re: Malý C/C++ quiz
Chcete říct, že konvenci cdecl (printf) může každý překladač implementovat jinak ? Nebo jinak, který překladač nevypíše to, co GCC a MSVC ?
19.2.2009 23:20 Jiri Uncovsky | skóre: 5
Rozbalit Rozbalit vše Re: Malý C/C++ quiz

Teď jsem to zkoušel na msvc 2003. Výsledky v debug a release se liší.

Bohužel, gcc trvá na stejném výsledku bez ohledu na optimalizaci, a pak že výsledný kód nemá být pomalý.

Doporučuju prostudovat normu C (ISO/IEC 9899:1999 (E)), paragraf 6.5, odstavec 2.

19.2.2009 23:47 Deleted [8409] | skóre: 14 | blog: darkblog
Rozbalit Rozbalit vše Re: Malý C/C++ quiz
msvc má asi nějakou chybu. Zkoušel jsem na VC8.0 toto:
int x = 0;
printf("%d %d %d %d\n", x++, x++, ++x, ++x);
A výsledek je naprosto nečekaný, řekl bych - vadný.

Ponaučení z tohoto příkladu mělo být totiž takové, že se vyplatí něco takového nepoužívat (tedy pokud se nejedná o jeden parametr).
20.2.2009 09:54 zde | skóre: 9 | blog: Linuch | Brno
Rozbalit Rozbalit vše Re: Malý C/C++ quiz
Podle normy není pořadí vyhodnocování (jak položek výrazu, tak arglistu) garantováno, takže výsledek závisí na konkrétním překladači. Myslím že jediné co je dáno je operátor čárka (ale ne v arglistu), a pak logický and a or. Takže msvc je v tomto ok.
Táto, ty de byl? V práci, já debil.
20.2.2009 10:42 Sinuhet | skóre: 31
Rozbalit Rozbalit vše Re: Malý C/C++ quiz

Asi mi unika nejaky trivialni poznatek, nebot vypadate, ze o c/c++ par veci vite, a zda se mi velmi nepravdepodobne, ze byste neznal tu o "sequence points" a "undefined behavior". Ale muj prvotni nazor by byl, ze tohle je klasicka ukazka nedefinovaneho chovani, ty parametry se mohou vyhodnotit v jakemkoliv poradi, takze jaky vysledek pro vas byl "naprosto necekany"?

20.2.2009 12:38 Deleted [8409] | skóre: 14 | blog: darkblog
Rozbalit Rozbalit vše Re: Malý C/C++ quiz
3 4 3 4
Jardík avatar 20.2.2009 17:08 Jardík | skóre: 40 | blog: jarda_bloguje
Rozbalit Rozbalit vše Re: Malý C/C++ quiz
To vám msvc vyhodil tohle? Mně dal 3 2 1 0.
Věřím v jednoho Boha.
20.2.2009 17:20 Deleted [8409] | skóre: 14 | blog: darkblog
Rozbalit Rozbalit vše Re: Malý C/C++ quiz
Zkuste toto:
int x = 0;
printf("%d %d %d %d\n", x++, x++, ++x, ++x);
21.2.2009 00:03 Miloslav Ponkrác | blog: miloslavponkrac
Rozbalit Rozbalit vše Re: Malý C/C++ quiz

„Zkoušel jsem na VC8.0 toto: printf("%d %d %d %d\n", x++, x++, ++x, ++x); A výsledek je naprosto nečekaný, řekl bych - vadný.“

Žádný výsledek není vadný, může Vám vyjít naprosto cokoliv a je to úplně v pořádku. Všichni programátoři, a všechny normy C/C++ hovoří, že zde je výsledek nedefinován – takže věta„vadný výsledek“ není na místě. Je to nepochopení funkce C/C++.

20.2.2009 13:19 Martin Mareš
Rozbalit Rozbalit vše Re: Malý C/C++ quiz
Chcete říct, že konvenci cdecl (printf) může každý překladač implementovat jinak?
Konvence cdecl je čistě microsoftí záležitost a navíc s pořadím aplikování side-effectů ve výrazech moc nesouvisí.
21.2.2009 00:13 Miloslav Ponkrác | blog: miloslavponkrac
Rozbalit Rozbalit vše Re: Malý C/C++ quiz

„Chcete říct, že konvenci cdecl (printf) může každý překladač implementovat jinak ?“

Může. A také implementuje.

Cdecl není žádný standard – je to pouze princip. Proto také při mixování funkcí mezi různými kompilátory (například sdílená knihovna přeložená kompilátorem X a používaná programem vyšlým z jiného kompilátoru) se používá jen podmnožina možností cdecl/stdcall.

Řada věcí se v konvenci nedefinuje vůbec. Například co se stane, když uložíte char a vyberete int. Ve vyšších bajtech můžete mít bordel, nebo nuly – dle situace. Není nikterak standardizováno, jak se uloží třeba struktury, ani jak se vrací. Není mezi kompilátory standardizován ani způsob a forma návratové hodnoty. Například v řadě případů si kompilátor optimalizuje tak, že namísto návratové hodnoty skrytě přidá na zásobník před první parametr další parametr, který pak slouží k předání návratové hodnoty funkce, zatímco jiný kompilátor to tak neudělá.

Každý programátor v C/C++ by si měl ve věcech udělat nejdříve pořádek. Jsou věci standardizované a normované, které fungují vždy přesně stejně. Pak jsou věci de facto standardizované, jako třeba, že char má 8 bitů (což norma nenařizuje).

A pak jsou extenze, jako třeba stdcall, nebo cdecl, které nemají naprosto žádný standard a každý kompilátor jej implementuje s odchylkami. Základ je, že stejně se implementuje jen předávání/vracení int a pointerů – a zbytek je compiler depended.

Proto se mi tak strašně nelíbí Vaše implicitní předpoklady, které nemusí vůbec platit. Je hezké si domýšlet, ale daleko lepší je vědět a být si jistý. To druhé je lepší cesta.

20.2.2009 09:49 Martin Mareš
Rozbalit Rozbalit vše Re: Malý C/C++ quiz
8) Pokud bereme float jako normalizovane IEEEx.x, tak bych řekl, že by to na každé platformě, kde je int 32 bitů (mohl jsem tam napsat radší int32_t) mělo být stejné.
... a kde se obojí ukládá ve stejném pořadí bytů [a pokud ten int bude unsigned] :-)
20.2.2009 12:41 Deleted [8409] | skóre: 14 | blog: darkblog
Rozbalit Rozbalit vše Re: Malý C/C++ quiz
Jaj, to je pravda :) Ale proto jsem zdůrazňoval hned na začítku to x86.
19.2.2009 21:41 zdenek
Rozbalit Rozbalit vše Re: Malý C/C++ quiz
Jsem se tesil ze se neco dozvim a same stare triky. Jeste by to chtelo treba vypocet hammingovy vzdalenosti dvou 32-bit vektoru na 5 scitani misto 32.
Josef Kufner avatar 19.2.2009 22:40 Josef Kufner | skóre: 69
Rozbalit Rozbalit vše Re: Malý C/C++ quiz
Tak krom 5. příkladu (optimalizace) je to všecko jen onanování nad blbostma, kterým je lepší se vyhnout, pokud má být program dlouhodobě udržovatelný a lehce čitelný.
Hello world ! Segmentation fault (core dumped)
19.2.2009 22:51 zde | skóre: 9 | blog: Linuch | Brno
Rozbalit Rozbalit vše Re: Malý C/C++ quiz

Souhlas. Spousta lidi se snazi byt "chytra", a pritom akorat udelaji kod temer necitelny.. http://dl.fefe.de/optimizer-isec.pdf

Táto, ty de byl? V práci, já debil.
19.2.2009 23:02 Deleted [8409] | skóre: 14 | blog: darkblog
Rozbalit Rozbalit vše Re: Malý C/C++ quiz
Ale i přesto generuje GCC stále 1.5x větší binárky než MSVC. Takže bych se neradoval nad tím, že překladač za vás udělá úplně všechno. Pokud by to 1024 nebylo číslo, ale proměnná, tak pochybuji, že to za vás ten překladač udělá.

Neříkám aby toto lidi dělali. Toto není nabádání k tomu, jak co dělat, ale ukázání možností, které třeba jiní neznají.
20.2.2009 02:55 deda.jabko | skóre: 23 | blog: blog co se jmenuje "každý den jinak" | za new york city dvakrát doleva a pak už se doptáte
Rozbalit Rozbalit vše Re: Malý C/C++ quiz
Pokud by to 1024 nebylo číslo, ale proměnná,
a pokud to nebudou mocniny cisla 2?
Asi před rokem se dostali hackeři na servry Debianu a ukradli jim zdrojové kódy.
20.2.2009 03:36 Deleted [8409] | skóre: 14 | blog: darkblog
Rozbalit Rozbalit vše Re: Malý C/C++ quiz
V tomto případě to nemá vliv. Já jen používám mě blízké čísla :-)
20.2.2009 05:17 deda.jabko | skóre: 23 | blog: blog co se jmenuje "každý den jinak" | za new york city dvakrát doleva a pak už se doptáte
Rozbalit Rozbalit vše Re: Malý C/C++ quiz
Já jen používám mě blízké čísla
aha... vzhledem ke stupidnosti predchozich (a vlastne vsech) otazek jsem predpokladal, ze to chces taky resit bitovyma operacema
Asi před rokem se dostali hackeři na servry Debianu a ukradli jim zdrojové kódy.
andree avatar 20.2.2009 08:23 andree | skóre: 39 | blog: andreeeeelog
Rozbalit Rozbalit vše Re: Malý C/C++ quiz

ono ale ze su 1.5x vacsie binarky (aj ked sa mi to nezda, urcite sa to vzdy nejak doladit, stipnut a pod.) neznamena, ze to produkuje 1.5x dlhsi kod... a aj keby bol 1.5x dlhsi ten kod, tak to neznamena, ze bude bezat dlhsie ako ten z msvc...

optimalizovat velkost kodu pri aktualnych stavoch diskov a ram sa mi zda nepodstatne - aj ked, samozrejme, treba mat hranice... nedavno sa mi podarilo vygenerovat z 50 riadkov 1MB binarku (kvoli wrapperom), to uz je vela, no :))

20.2.2009 12:50 Deleted [8409] | skóre: 14 | blog: darkblog
Rozbalit Rozbalit vše Re: Malý C/C++ quiz
Ale nic z toho co píšete netvrdím. Je to prostě fakt, že GCC buď neumí tak dobře optimalizovat a produkuje delší kód, nebo tak optimalizuje, že je výsledek větší. Ale pro mě ani MSVC nedělá optimální kód, taky bych chtěl, aby byly překladače chytřejší.
nedavno sa mi podarilo vygenerovat z 50 riadkov 1MB binarku (kvoli wrapperom), to uz je vela, no
To jsou ty header-only knihovny :-)
20.2.2009 12:54 petr_p | skóre: 59 | blog: pb
Rozbalit Rozbalit vše Re: Malý C/C++ quiz

Asi jste minul poučku, že libovolný program lze libovolně krát urychlit na úkor nabobtnání jeho velikost.

Takže kromě velikosti ještě změřte čas běhu programu.

20.2.2009 13:20 Deleted [8409] | skóre: 14 | blog: darkblog
Rozbalit Rozbalit vše Re: Malý C/C++ quiz
A myslíte, že to v tomto případě platí? Třeba takový firefox kompilovaný MSVC měl být až o 10% rychlejší (teda aspoň to margetingově prohlašovali:) ).

Pokud mi GCC z kódu bez cyklů (jen funkce pod sebou) vygeneruje 120kB program a MSVC pouze 70kB program, tak si ríkám, že to je dost.
Josef Kufner avatar 20.2.2009 13:26 Josef Kufner | skóre: 69
Rozbalit Rozbalit vše Re: Malý C/C++ quiz
Pokud ty funkce jsou použity jednou, tak gcc uzná za zbytečné se obtěžovat jejich voláním a vloží je. Aby ale pomocí dlopen() byly dostupné, musí je tam nechat i jako funkce. Takže ten kód je tam dvakrát. Pokud MSVC jednu z těhle věcí neudělá, bude mít menší výsledek.
Hello world ! Segmentation fault (core dumped)
20.2.2009 13:31 Deleted [8409] | skóre: 14 | blog: darkblog
Rozbalit Rozbalit vše Re: Malý C/C++ quiz
Tak pokud nastavím visibility=hidden, tak by se nemělo stát o o čem mluvíte. Jsem to akorát zapomněl zmínit. Jde prostě o kód vygenerovaný jen pro volání těch funkcí a pár konstruktorů (argumenty).

Ale nechtěl jsem se tu bavit o GCC vs MSVC. Já jsem vděčný za oba překladače.
20.2.2009 17:15 Andrej Herceg | skóre: 43
Rozbalit Rozbalit vše Re: Malý C/C++ quiz
Třeba takový firefox kompilovaný MSVC měl být až o 10% rychlejší (teda aspoň to margetingově prohlašovali:)
Ak je tá verzia, čo sa dá stiahnuť zo stránok Mozilla kompilovaná pomocou MSVC, tak je naozaj (aspoň pokiaľ ide o javascript) výrazne rýchlejšia ako tá pre Linux (u mňa je V8 test a Dromaeo vo Firefox cez Wine rýchlejšie o viac ako 20% ako vo verzii pre Linux). Test som robil po tom, ako som si prečítal Browser benchmarks 2: even Wine beats Linux Firefox. :)
default avatar 20.2.2009 10:52 default | skóre: 22 | Madrid
Rozbalit Rozbalit vše Re: Malý C/C++ quiz

No, mně je C++ úplně ukradený. Ale tohle:

Zanedbejte možnost přetečení datového typu.

mi teda žlučí pěkně hnulo. :-D

20.2.2009 12:52 Deleted [8409] | skóre: 14 | blog: darkblog
Rozbalit Rozbalit vše Re: Malý C/C++ quiz
A můžu se zeptat proč? (Tedy, v kterém praktickém příkladě je to nutné)

Ještě se mi nestalo, že bych v tomto případě musel řešit přetečení. Je to vzhledem k použití nelogické.
19.2.2009 22:42 zde | skóre: 9 | blog: Linuch | Brno
Rozbalit Rozbalit vše Re: Malý C/C++ quiz

Jednicka je trivialni, dvojka ma divne zadani, o "zaokrouhlení proměnné na 4" jsem neslysel. Jestli se mysli nasobek 4, tak dtto. Trojka je docela znama ale k nicemu protoze to prekladac zcela bezne dela sam, takze tim programator pouze prasi kod. Ctyrka je pekna, to uz moc lidi nezna, ale v dobe MMX/SSE/... taky passe. Petka viz 3. Sestka ma chybne zadani, chovani STDCALL je platformove zavisle (cdecl na nixu, pascal na winech, jedno pobezi druhe ne). Navic nechapu proc se tam blbne s uchylnym C++ castem, misto toho obvykleho zavorkoveho. Sedmicka je docela znama, to bude kazdy znat. Osmicka dtto- IEEE formaty z hlavy nevim, ale tenhle bit je jasnej. Devitka- na tom se snad nekdy spalil kazdy, tohle mi na C docela vadilo. Veci jako typedef struct { .. } Foo[1] maji sve vyhody, ale nevyhody podle me prevazuji.

Táto, ty de byl? V práci, já debil.
19.2.2009 22:59 Deleted [8409] | skóre: 14 | blog: darkblog
Rozbalit Rozbalit vše Re: Malý C/C++ quiz
Připomínka ke 2. bodu je na místě, myslel jsem to tak. Opravím, díky.

U ostatního si ale stojím za svým. STDCALL konvence pracuje stejně v Linuxu i pod Windows, proto tam je. Úchylný C++ cast je prostě C++ cast, zjistil jsem ale, že ten kód nezežere starší GCC (píše, že iso norma zakazuje cast na funkci).

PS: Aby se na té sedmičce nespálilo víc lidí, než si myslíte :-)
19.2.2009 23:29 zde | skóre: 9 | blog: Linuch | Brno
Rozbalit Rozbalit vše Re: Malý C/C++ quiz

Jojo, mate pravdu, overeno, omlouvam se. Nikdy jsem STDCALL nepouzival, ale protoze je to makro co se nastavuje kdesi hluboko v headerech tak jsem cekal ze je to platformove zavisle jako "OS nativni" konvence.

Táto, ty de byl? V práci, já debil.
20.2.2009 08:09 Tom.š Ze.le.in | skóre: 21 | blog: tz
Rozbalit Rozbalit vše Re: Malý C/C++ quiz

Řada otázek (ty bitové)  nemá nic moc společného s Cčkem a lépe by vyzněla do assembleru. A v tom už jsou podobné a řada dalších dost hezky popsané třeba v Knuthově Bitwise tricks and techniques, dokonce to snad teď jde i stáhnout.

20.2.2009 09:47 Martin Mareš
Rozbalit Rozbalit vše Re: Malý C/C++ quiz
(0) Žádný standard pro to, jak se má C/C++ chovat na x86, neexistuje. Věci, které norma Céčka označuje za implementačně závislé, jsou prostě implementačně závislé a ne architekturálně závislé.

(2) hezká ... co třeba bez bitových operací?

(3) asi dneska zvládne každý slušný překladač za Vás (alespoň GCC určitě ano).

(5) je zajímavá ... ale proč by někdo něco takového dělal? :-)

(6) nejde zkompilovat, standardní C++ žádný STDCALL nezná.

(7) ani nic vypsat nemusí, může třeba zformátovat disk, nebo může z disketové mechaniky vylézt kočka a sežrat myš. Standard jasně říká, že pokud mezi dvěma sequencing pointy (tady uvnitř závorek žádné nejsou) dojde k vícenásobné modifikaci téže proměnné, má program nedefinované chování. A nedefinované chování je definováno tak, že může udělat cokoliv :-)

(8) může dopadnout všelijak, nikdo nezaručuje, že na x86 je int i float 32-bitový.

Přidám pár svých:

(A) Zjistěte co nejrychleji, jestli je dané celé kladné číslo mocninou dvojky (bez cyklů a bez předpokladu konkrétní velikosti intu, samozřejmě).

(B) Spočítejte, kolik jedničkových bitů obsahuje dané 32/64-bitové číslo.

(C) Jak co nejrychleji k danému číslu najít nejbližší vyšší, které obsahuje stejný počet jedničkových bitů?
20.2.2009 11:34 Karel Zak
Rozbalit Rozbalit vše Re: Malý C/C++ quiz

ad (7); ano, dokonce C99 primo explicitne mluvi i o funkcich

6.5.2.2 Function calls

10. The order of evaluation of the function designator, the actual arguments, and subexpressions within the actual arguments is unspecified, but there is a sequence point before the actual call.

20.2.2009 13:13 Deleted [8409] | skóre: 14 | blog: darkblog
Rozbalit Rozbalit vše Re: Malý C/C++ quiz
U těch otázek ale vůbec nejde o to, proč by to někdo dělal. Jsou to podle mě buď blbosti, nebo věci, které se přihodí spíš omylem - proto je to kvíz. Takže pokud někde uvidím třeba f(x++, x++), tak budu vědět, že to mám radši přepsat na f(x, x+1); x += 2 a nevymýšlet blbosti, které nemusí fungovat.
Josef Kufner avatar 20.2.2009 13:29 Josef Kufner | skóre: 69
Rozbalit Rozbalit vše Re: Malý C/C++ quiz
(5) je zajímavá ... ale proč by někdo něco takového dělal? :-)
Třeba aby z algoritmu s kvadratickou složitostí udělal algoritmus s lineární složitostí, když optimalizace je to triviální a na čitelnosti neubere?
Hello world ! Segmentation fault (core dumped)
20.2.2009 16:10 Martin Mareš
Rozbalit Rozbalit vše Re: Malý C/C++ quiz
Já měl na mysli proč by někdo sčítal znaky stringu ukončeného nulou :-)

Ale i tak: v tomto případě je značně nepřirozené nejdřív napsat kvadratický algoritmus a ten pak pracně zlepšovat, když lineární je daleko přímočařejší.
20.2.2009 16:24 JS
Rozbalit Rozbalit vše Re: Malý C/C++ quiz

No, neco zkusim:

ad B - je klasicky POPCOUNT, je o tom cela kapitola v Beautiful Code.

ad C - bud x vstup, y vystup, x obsahuje jednickove i nulove bity:

z=1;

while ((mask=((x+z)^x))==z) z<<=1;

y=((x&mask)<<1)|(x&~mask)

Mohlo by to tak byt?

Zkusim jeste A.

20.2.2009 17:18 JS
Rozbalit Rozbalit vše Re: Malý C/C++ quiz

Ha, uz mam asi i to A, staci otestovat:

(x - ~((~x)+1)) == 1

Pokud plati, je cislo x mocninou dvojky.

Tim se zlepsuje i moje reseni C nahore (mel jsem to podezreni), staci misto cyklu udelat:

z = ((x ^ ~((~x)+1))+1)>>1;
mask= (x+z)^x;

A to uz by mohlo byt ono.

21.2.2009 01:36 Martin Mareš
Rozbalit Rozbalit vše Re: Malý C/C++ quiz

(x - ~((~x)+1)) == 1

To je určitě dobrý začátek, ale jde to ještě daleko přímočařeji.
21.2.2009 09:06 JS
Rozbalit Rozbalit vše Re: Malý C/C++ quiz

Hlavne je to spatne, jak jsem zjistil rano. Ale skutecne to jde primocarejii:

(x & (x-1)) == 0

Ze by?

21.2.2009 13:32 Martin Mareš
Rozbalit Rozbalit vše Re: Malý C/C++ quiz
Třeba tak.
20.2.2009 17:26 Ladicek | skóre: 28 | blog: variace | Havlíčkův brod
Rozbalit Rozbalit vše Re: Malý C/C++ quiz
ad B - je klasicky POPCOUNT, je o tom cela kapitola v Beautiful Code.
Jo. A zhruba v půlce té kapitoly jsem přestal chápat :-)
Ještě na tom nejsem tak špatně, abych četl Viewegha.
20.2.2009 17:34 JS
Rozbalit Rozbalit vše Re: Malý C/C++ quiz

No, me na tom nejvic udivil ten fakt, ze staci ta prorotovana cisla proste secist (a mozna vysledek jeste nejak zpracovat, nejsem si ted jisty). Ale neresil jsem to take proto, ze kdybych to nahodou potreboval (jako ze na modernich procesorech je to trochu passe), tak vim, ze to Martin Mares ma ve sve knihovne (dela to tam jinak, pres bitove manipulace, coz je primocarejsi a efektivnejsi). ;-)

20.2.2009 10:51 Petr Bravenec
Rozbalit Rozbalit vše Re: Malý C/C++ quiz
Příklad první: (x==0) ? -1 : 1;

Dál jsem to ani podrobně nečetl. C++ používám k programování aplikací a ne k řešení kvízů.

Navržené řešení možná funguje pomalu, ale zatím mi vždycky funguvalo jak na x86, tak na amd64, sparc, arm i avr - a pouze na té poslední architektuře bych uvažoval, jestli bych to přece jen neměl řešit jinak. Užitečnějším nástrojem bývá obvykle valgrind, až daleko za ním nějaký profiler.
20.2.2009 13:15 Deleted [8409] | skóre: 14 | blog: darkblog
Rozbalit Rozbalit vše Re: Malý C/C++ quiz
Možná by stačilo si přečíst tu podmínku
20.2.2009 13:31 Petr Bravenec
Rozbalit Rozbalit vše Re: Malý C/C++ quiz
Podmínkou rozumíte "Vzorec musí obsahovat jen jednoduché aritmetické nebo logické operace (plus, minus, bitové operace)"?

Znám lepší podmínku: "Vzorec musí fungovat a být čitelný. Obojí by mělo platit i za deset let."
20.2.2009 11:50 zde | skóre: 9 | blog: Linuch | Brno
Rozbalit Rozbalit vše Doporucena literatura

Spousta nadhernych hacku v C je zde http://www.cl.cam.ac.uk/~am21/hakmemc.html

Táto, ty de byl? V práci, já debil.
20.2.2009 12:59 Deleted [8409] | skóre: 14 | blog: darkblog
Rozbalit Rozbalit vše Re: Doporucena literatura
Je zajímavé, že jejich kód
union { int i; float f; } u;
if ((float)u.i == u.f) /* then we have u.i = 0x00000000 */
je v pořádku, kdežto já když použiju union, tak se hned objeví rýpalové:-) Jinak některé věci jsou zajímavé,
Jardík avatar 20.2.2009 17:00 Jardík | skóre: 40 | blog: jarda_bloguje
Rozbalit Rozbalit vše Re: Malý C/C++ quiz
Začnu nejjednodušším

5)
size_t sum(const unsigned char* str)
{
  register size_t result = 0;
  for(; *str; result += *str++);
  return result;
}
6) Pokud je STDCALL definován jako __stdcall a CDECL jako __cdecl a FASTCALL jako __fastcall, tak se u __stdcall stane to, že zeserete zásobník, protože uklízí volaná fce (z toho důvodu nelze použít ... operátor). U __fastcall se první dva argumenty "kydnou" do registrů a zbytek jako __cdecl. BTW ve Win64 je to všechno __fastcall.

7) "3 2 1 0"? (podváděl jsem, myslel jsem si "0 1 2 3" :-))

Už mě to neba.
Věřím v jednoho Boha.
20.2.2009 20:59 Deleted [8409] | skóre: 14 | blog: darkblog
Rozbalit Rozbalit vše Re: Malý C/C++ quiz
Konečně tu pětku někdo pochopil :-)
20.2.2009 21:26 Jary | skóre: 30 | blog: Jary má blog | Dům
Rozbalit Rozbalit vše Re: Malý C/C++ quiz

Ten specifikátor storage class, nebo jak se to správně nazývá,  "register", snad není třeba. Doufám, že překaldače nejsou úplné cvičené opice. Při -O2 se snad proměnné zbytečně na stack nedávají. Mýlím se?

.sig virus 3.2_cz: Prosím, okopírujte tento text do vaší patičky. GitHub
Jardík avatar 20.2.2009 17:13 Jardík | skóre: 40 | blog: jarda_bloguje
Rozbalit Rozbalit vše Re: Malý C/C++ quiz
Neřešte to a udělejte commit do Wde, už jsem tam nic dlouho neviděl a jelikož se mi to nechce zkompilovat s gcc (na linuxu) ani mingw-w64 (windows), tak se mi na tom nechce nějak dělat, abych vám to nerozbil v msvc :-)
Věřím v jednoho Boha.
20.2.2009 20:58 Deleted [8409] | skóre: 14 | blog: darkblog
Rozbalit Rozbalit vše Re: Malý C/C++ quiz
Bude brzy, jinak pod MSVC by měla ta SVN verze jít aspoň zkompilovat:)
20.2.2009 18:56 Miloslav Ponkrác | blog: miloslavponkrac
Rozbalit Rozbalit vše Re: Malý C/C++ quiz

Tohle není ani tak test C/C++, jako spíš test assembleru na x86.

20.2.2009 19:07 Miloslav Ponkrác | blog: miloslavponkrac
Rozbalit Rozbalit vše Re: Malý C/C++ quiz

Jinak některé správné odpovědi:

ad 5) správné řešení neexistuje – je to silně závislé na konkrétním optimalizátoru toho kterého kompilátoru, také na volbávh překladače, a správné řešení se tedy liší podle kompilátoru, a dokonce se může lišit i podle verze. Navíc na každém procesoru to rovněž může být jinak. Optimalizátor může kód naprosto a totálně překopat.

ad 6) může se stát cokoli, třeba pokud bude #define STDCALL __fastcall, určitě se stane něco jiného, než když bude #define STDCALL __cdecl. Žádná slova STDCALL, STDCALL atd.. nejsou součástí standardu C/C++ kompilátorů, a ani standardní součástí kompilátorů na x86

ad 7) výsledek je nedefinovaný a je závislý na kompilátoru

ad 8) Na každém procesoru, nejenom x86, dojde k obrácení znaménko reálného čísla. Zde je výsledek de facto nezávislý na procesoru, protože způsob reprezentace reálných čísel je určen multiplatformovou normou IIEE 754. Čistě teoreticky float jí nemusí vyhovovat, čistě v praxi téměř vždy.

ad 9) První printf – počet členů, druhé printf – délku pointeru / délku bázového typu pointeru, v tomto případě 1.

20.2.2009 20:56 Deleted [8409] | skóre: 14 | blog: darkblog
Rozbalit Rozbalit vše Re: Malý C/C++ quiz
Tak pokud jste nepochopil, co asi může znamenat STDCALL, tak to je potom těžké. Je tam jasně uvedené, že se jedná o 32 bit. Na 64 bitech žádný cdecl, stdcall ani fastcall není. Je to velkými písmeny právě proto, aby si lidi místo toho dosadili to "své" (přece nemá cenu do takového jednoduchého testu přidávat multiplatformní makra na detekce, o tom to fakt nebylo).

Celé to spíš spočívalo v tom, jestli programátoři vůbec ví, co tyto věci znamenají (třeba proč printf logicky nemůže být STDCALL). Kdybych měl brát jako argument to, že STDCAL bude definován jako CDECL, tak potom nechápu smysl toho STDCALL (Wine a Mono vývojáři by vám za to asi velmi poděkovali).

Jinak to beru, celé to byl blbý nápad na naprosto nevhodném portálu :)
20.2.2009 21:38 Miloslav Ponkrác | blog: miloslavponkrac
Rozbalit Rozbalit vše Re: Malý C/C++ quiz

„Tak pokud jste nepochopil, co asi může znamenat STDCALL“

Samozřejmě, že pochopil, ale problém je, že to tak znamenat nemusí. Pokud se zadává test, měl by být jednoznačný.

Nejvíce chyb v programech vzniká na základě faktu „programátor něco předpokládá, zato program na rozdíl od předpokladu provede co je napsáno, často zcela něco jiného, než si programátor myslí“. Tak vznikají nejzapeklitější chyby.

20.2.2009 20:57 Jary | skóre: 30 | blog: Jary má blog | Dům
Rozbalit Rozbalit vše Re: Malý C/C++ quiz

Já si myslím, že ta optimalizace existuje, projeví se snad všude, je naprosto kardinální, jednoduchá a přímočará, ale taky jsem si ji hned nevšiml.

.sig virus 3.2_cz: Prosím, okopírujte tento text do vaší patičky. GitHub
20.2.2009 21:01 Deleted [8409] | skóre: 14 | blog: darkblog
Rozbalit Rozbalit vše Re: Malý C/C++ quiz
Díváte se na to správně - Thinking Low Level, Writing High Level ;-)
20.2.2009 21:31 Jary | skóre: 30 | blog: Jary má blog | Dům
Rozbalit Rozbalit vše Re: Malý C/C++ quiz

Jestli myslíš to s tím register, jak psal někdo nademnou, tak to jsem nemyslel. Myslel jsem to s tou složitostí O(n) a O(n^2), jak psal někdo taky někde tady. Pravda je, že bych si toho nevšiml, ač jsem se s tím už jednou setkal => kvíz byl určitě užitečný a nevim, proř jsi ho nedal do zdejších kvízů. www.abclinuxu.cz/hry

.sig virus 3.2_cz: Prosím, okopírujte tento text do vaší patičky. GitHub
20.2.2009 21:33 Miloslav Ponkrác | blog: miloslavponkrac
Rozbalit Rozbalit vše Re: Malý C/C++ quiz

To platilo kdysi, ale dnes už moc ne.  Naopak dnes je nejlepší psát tak, aby kód šel co nejlépe udržovat a s použitím rozumně efektivních algoritmů.

Jediné co by snad šlo v bodě 5 zoptimalizovat je vyhození strlen před for, i když teoreticky vynikající optimalizátor by měl být schopen toto udělat sám (funkce strlen je pro něho známá a obsah pole se nemění – třeba fortran takové optimalizace na známých funkcích dělá zcela běžně).

Pro dobře optimalizující kompilátor není rozdíl, zda k poli přistupujete přes indexy, nebo přes pointer, který postupně inkrementujete. Pokud je mezi tím rozdíl, pak kompilátor špatně optimalizuje. Navíc na platformě x86 je i na úrovni strojového kódu rychlost přístupu přes index a přes pointer velmi blízká, u jiných procesorů jsou rozdíly často větší, nicméně i tak dobře optimalizující kompilátor ve zdrojov=m kódu převede jedno na druhé.

Dobře optimalizující kompilátor by dokonce měl být schopen celou smyčku převést na vektorové operace na SIMD strojových instrukcích, kdy najednou paralelně v jednom taktu vykonává třeba 16 průchodů cyklem v jednom taktu, protože daný algoritmus je dobře paralelizovatelný. A třeba Intel kompilátor to často i takto vymyslí. Zároveň mu toto nejste schopni moc v kódu napovědět, protože C/C++ nemá syntaxi na to to vůbec napsat, on na to Intel kompilátor analýzou přijde sám.

Ono stejně tak kdysi platilo třeba, že při tiskařské sazbě je třeba používat montérky, protože se jinak se umažete, ale to vám dnes třeba u Scribusu, nebo TeXu nehrozí. A stejně tak heslo „Thinking Low Level, Writing High Level“ už nemá zcela platnost a často jím naděláte více škody a vyrobíte pomalejší programy. Kdysi totiž věci bývaly jednodušší, kompilátory špatné, optimalizátory velmi mizerné, instrukční sada procesorů nebyla paralelizovatelná, struktury procesorů průzračné a procesory pomalé. Dnes už je všechno složitější, a troufám si říct, že lidí, kteří dokážet dobře vydedukovat, jak co bude na low level úrovni probíhat je naprosto mizivé množství. Daleko více je tu mýtů o low level úrovni.

20.2.2009 21:46 Deleted [8409] | skóre: 14 | blog: darkblog
Rozbalit Rozbalit vše Re: Malý C/C++ quiz
Nebudu psát tak dlouhou odpověď jako vy. Thinking Low Level, Writing High Level je knížka, kterou bych doporučil hodně programátorům, protože to co někdy vidím je katastrofa.

Například pokud budu mít alokované pole 128MB a budu do něj dělat append řetězce pomocí strcat() tak to asi taky není to pravé ořechové (a to je přesně o tom Thinking Low Level).

Je pro mě ale celkem zábavné, jak si myslíte, že překladač za vás udělá zázraky. Po fakt dlouhé době vím, že tomu tak není a asi nikdy nebude. Proč si myslíte, že MMX, SSE, SSE2 atd můžete volat přímo z C++ a pro kritické věci se to využívá? Udělal vám někdy překladač z čistého C třeba MMX kód ? (já myslím, že nikdy, maximálně SSE/SSE2, atd).

Ale stejně moc nechápu ty řeči o nepřehlednosti kódu. Optimalizace, které nejsou přehledné se dají dělat jako inline funkce. Kde je psané, že to musí programátor vkládat na každém místě zvlášť?

PS: Ten strlen() by vám překladač už z principu nikdy neměl optimalizovat.
20.2.2009 22:04 Miloslav Ponkrác | blog: miloslavponkrac
Rozbalit Rozbalit vše Re: Malý C/C++ quiz

Ad 1)

Já jsem jenom pochopil, že kdybyste zadával programátorské zadání Vy, tak by vzniklo obrovská spousta zmatků.

Já bych naopak doporučil Thinking High Level – v prvé řadě bych úplně zapomněl, že nějaké funkce typu strlen, strcat a strxxx existují. Zapomněl bych, že řetězce jsou bajtíky zakončené nulou a odnaučil se to. Dneska každý používá třídu, která nehledá nulu, ale má interně uložený počet znaků – například ::std::string. To je právě důsledek té blbosti Thinking Low Level – v ASCIIZ řetězcích miliónkrát hledáte nulu. Pokud budete mít rozumný řetězec, který bude mít řetězec s explicitně uloženou délkou, pak concatenation dvou stringů na 1 GB poli je leckdy i velmi efektivní operace – na rozdíl od blbých stringů zakončených nulou. Takže moje doporučení je Thinking High Level, Tiny Correct Low Level.

Překladač za Vás neudělá zázraky, ale naprosto zábavné je, jak si myslíte, že existuje přímé mapování zdrojový kód -> stroják. Dobře optimalizující kompilátor poznáte tak, že nejste schopni v dissasembleru, či debuggeru na strojové úrovni poznat, které kusy strojáku patří ke které části zdrojového kódu. Leckdy totiž ani funkce a rozdělení do podprogramů nesouhlasí s Vaším zdrojovým kódem. A v příkladu 5 si myslím, že po vyhození strlen není pro kompilátor problém poznat, že lze paralelizovat na úrovni SIMD. Pravda u gcc se toho zcela určitě nedočkáte, ale já mluvím o dobře optimalizujícím kompilátoru.

Ten strlen() nejenomže je bez problémů možné zoptimalizovat, dokonce ani norma C/C++ proti tomu nic nemá, ale dokonce to řada kompilátorů už minimálně 20 let dělá. Ono totiž optimalizací počtu volání strlen() často trhnete větší rychlostní zisk, než hledání pikosekund v tom, jak převrátit dvě instrukce v cyklu. A často se sejde několik volání strlen(), aniž by programátor musel být prase – uvědomte si, že v C++ se Vám ve funkci snadno složí X jiných, nezávislých inline funkcí a Y šablon.

 

 

20.2.2009 23:47 Deleted [8409] | skóre: 14 | blog: darkblog
Rozbalit Rozbalit vše Re: Malý C/C++ quiz
Mám z vás pocit, že věci záměrně překrucujete, i když dobře chápete, co chtěl autor říct.
20.2.2009 23:59 Miloslav Ponkrác | blog: miloslavponkrac
Rozbalit Rozbalit vše Re: Malý C/C++ quiz

Připouštím možnost nedorozumění.

21.2.2009 01:43 Martin Mareš
Rozbalit Rozbalit vše Re: Malý C/C++ quiz
Řetězce s explicitně uloženou délkou rozhodně nejsou samospasitelné. Někdy jsou efektivnější, jindy zase jednoznačně vedou řetězce ukončené nulou (například pokud potřebujete rozsekat dlouhý řetězec na spoustu menších). Pokud chcete programovat efektivně, tak zkrátka musíte mít povědomí o tom, jak jsou které řetězce implementovány, jak je proto která operace s nimi rychlá a tím pádem i kdy si které vybrat.

Pokud píši program, u kterého mi na efektivitě nijak zvlášť nezáleží, nepoužiji std::string, nýbrž Haskell ;-)
21.2.2009 02:09 Deleted [8409] | skóre: 14 | blog: darkblog
Rozbalit Rozbalit vše Re: Malý C/C++ quiz
Tak ono ty řetězce ukončené nulou nejsou podle mě výhodné snad nikdy;), ale je potřeba brát v úvahu, že celý C runtime a API různých knihoven jsou na tom založené. Nejvýhodnější se mi z hlediska C++ zdá implicitní sdílení a copy-on-write (tak jak to má třeba Qt). V C už by se s tím pracovalo asi trochu hůř, ale šlo by to podle mě taky - ale čisté C už jsem opustil;).
21.2.2009 13:31 Martin Mareš
Rozbalit Rozbalit vše Re: Malý C/C++ quiz
Jak jsem psal, výhodné jsou například při sekání dlouhého řetězce na menší, což je operace kritická pro výkon mnoha parserů. Taktéž si je třeba můžete snadno mmapnout ze souboru, zatímco u řetězců s explicitně uloženou délkou musíte řešit takové věci, jako v jakém formátu je délka uložena (a explicitně konvertovat endianitu, pokud si přejete mít soubory přenositelné atd.).

Na čisté C nezapomínejte, čistota je půl zdraví :-) [V tomto případě duševního.]
21.2.2009 14:42 Miloslav Ponkrác | blog: miloslavponkrac
Rozbalit Rozbalit vše Re: Malý C/C++ quiz

Já si matně nemůžu vzpomenout na jedinou výhodu řetězce zakončeného nulou. Pokud budu chtít pracovat se spoustou subřetězců z jednoho řetězce, pořád se dá pracovat s trojicí (řetězec, start_index, délka_subřetězce), která je velice efektivní.

Ohledně řetězců právě tyto věci jako endianitu řešit musíte. Hlavně zmodernizujte svoje názory, doby, kdy se znaková sada vešla do 8mi bitových znaků už jsou dost let neodvratně pryč. Mnohé asijské sady, nebo Unicode nenacpete do zažitého schématu starých Céčkarů, či unixových zakladatelů, které zní „znak je bajt“ – dneska už to neplatí.

Takže tak jako tak v praxi řešíte formát uložení znaků (který se nevejde dnes už do jednoho bajtu) do bajtů – a tím pádem Vám naplno vyvstává ta endianita, formát uložení znaků a další problémy. Jistě – můžete se nadále tvářit, že Vám znaková sada ISO-8859-? stačí, ale pak budete muse mít spousty výjimek, pokud hodláte produktovat programy, které mají hovořit dnešní řečí a pracovat s dnešními texty.

Takže znovu říkám, u dnešních řetězců a textů nevidím ani jeden přínos řetězců zakončených nulou. Veškeré operace nad takovými řetězci jsou dvojnásobně pomalé – najdříve musíte řetězec projít, najít nulu a podruhé teprve nad ním dělat danou operaci, což znamená znovu paměťová operace. Pokud provádíte operace nad subřetězci, pak při explicitně uložené délce nepoužívané části řetězců může procesor i os zapomenout (pokud se bavíme o těmch mnohaset megabajtových polích, jak bylo řečeno výše), zatímco při hledání nuly znovu a znovu nutíte projít celé pole (tím natáhnout vše do cpu cache a vyhodit tam něco co bude v cache užitečnější, dále os donutíte nahrát swapované stránky zpět do paměti, i když ty kusy paměti k ničemu momentálně nepotřebujete).

Čisté C je potřeba (jako emulátor asm), ale až budete propagovat low level úroveň (která je také důležitá), tak nezapomínejte, že na nejnižší úrovni je ve vodě bahno a slabý výhled.

Josef Kufner avatar 21.2.2009 15:57 Josef Kufner | skóre: 69
Rozbalit Rozbalit vše Re: Malý C/C++ quiz
Veškeré operace nad takovými řetězci jsou dvojnásobně pomalé – najdříve musíte řetězec projít, najít nulu a podruhé teprve nad ním dělat danou operaci, což znamená znovu paměťová operace. [...]
U drtivé většiny operací lze vše potřebné udělat už na první průchod, aniž by byla celková délka známá. Takže žádná režie navíc se nekoná.
Hello world ! Segmentation fault (core dumped)
21.2.2009 16:27 Miloslav Ponkrác | blog: miloslavponkrac
Rozbalit Rozbalit vše Re: Malý C/C++ quiz

Jenže ten jeden průchod je většinou pomalejší, než ty dva průchody. To je taková malá potíž. :-) Snadno nahlédne každý, kdo nějak výraněji rozumí programování a optimalizaci v současných procesorech (a koneckonců i v os). Proto také všechny knihovní funkce typu strxxx, které potřebují kromě zjištění délky i něco udělat z toho zásadně dělají prchody dva (snadno nahlédnete do zdrojových kódů standardních knihoven C/C++) – a to i přesto, že by to šlo udělat na jeden průchod.

To je právě to, co tu kritizuji – low level úroveň chce úplně odlišné myšlení, než běžný programátorská úroveň. Proto všichni chytrolíni, co mixují běžné programování s low level úrovní jsou vedle jak ta jedle. Dnes jsou obě úrovně velmi odlišné – a nedá se podle jedné programovat v druhé – tedy pokud Vám záleží na efektivitě a rychlosti výsledného kódu.

Prostě pro low level práci se stringem je rychlejší udělat dva průchody pro dvě akce nad stringem zakončeným nulou, než jeden průchod, ve kterém zkombinujete obě akce. Profesionálním assembleristům to přijde naprosto samozřejmé a ani by je nenapadlo pokusit se o jeden průchod, protože znají rychlostní poměry na procesoru.

Takže znovu si uvědomte, že doba se mění, a procesory i os jsou jiné, než před řekněme dvaceti lety. Mnohá pravidla a mnohé knihy dnes nejsou zcela použitelné bez přemýšlení.

21.2.2009 17:55 Jary | skóre: 30 | blog: Jary má blog | Dům
Rozbalit Rozbalit vše Re: Malý C/C++ quiz

Asi mluvíš o X86 instukcích pracujících se stringy, s prefixem REP*, že? Myslel bych si, že blábolíš koniny, kdybych se s těmihle instrukcemi nesetkal. Měl bys být příště asi více konkrétní, jinak to tady bude jeden velký flame.

Nikdy jsem tohle moc neměřil a moc jsem toho v životě zatím nezoptimalizoval, ale mám za to, že čím víc informací o struktuře mám, tím _efektivnější_ funkce nad ní _možná_ můžu napsat. Slovo "efektivnější" jsem v použil proto, protože si myslím, že je důležité zvážit, jak je daná instrukce implementována. Může třeba běžet pomaleji, ale používat méně prostředků CPU a ty zbylé mohou být využity třeba pro něco jiného (Třeba HyperThreading?).

Pokud budu třeba duplikovat řetězec, použiji instrukci s REP* a C string (ukončený nulou), tak se něco v procesoru musí koukat na každé načtené slovo(byte,znak) a zjišťovat, jestli aktuálně zpracovávaný znak již není sentinel (nula, konec), musí se také inkrementovat zdrojová adresa a cílová adresa. To vše může, ale nemusí dělat třeba ALU. V případě použití Pascal stringů (s daným počtem znaků) bych musel používat ALU k počítání kolik slov(bytů, znaků) ještě musím zpracovat, a také musím počítat adresy zdroje a cíle. Výsledek je tedy asi 3:3. C stringy mají oproti Pascal stringů ale výhodu v tom, že jsou nekonečné a že procesor snad dokáže REP* lépe zoptimalizovat, než by to mohl dokázal překladač.

.sig virus 3.2_cz: Prosím, okopírujte tento text do vaší patičky. GitHub
21.2.2009 18:12 Deleted [8409] | skóre: 14 | blog: darkblog
Rozbalit Rozbalit vše Re: Malý C/C++ quiz
Používání REP prefixů je deprecated. Pro moderní procesory je vždycky výhodnější použít rozvynutý nebo i obyčejný cyklus. U stringů můžete kopírovat data třeba po 8 bytech (zarovnaných) a tím docílíte mnohem vyššího výkonu než je možné pomocí REP prefixu. REP prefix na druhou stranu dělá výsledný kód kratší. Samozřejmě ještě záleží na cílovém procesoru - mezi Intel a AMD je hodně rozdílů.

Myslím, že pro duplikaci nulou ukončeného stringu ale stejně budete potřebovat průchody 2. První průchod zjistí délku (kterou většinou potřebujete ke kontrole proti přetečení cílového bufferu) a ve druhém budete kopírovat. V takovém případě už je podle mě zbytečné používat obdobu strcpy(), protože výhodnější bude obdoba memcpy() (tou obdobou myslím v našem případě obdobu v asm).

Samozřejmě záleží i na délce řetězce. Pro krátké (do 8 bytů) bude asi opravdu nejvýhodnější ten REP prefix.
21.2.2009 21:11 Miloslav Ponkrác | blog: miloslavponkrac
Rozbalit Rozbalit vše Re: Malý C/C++ quiz

Napsal jste to perfektně. Jen oprava: REP prefix bude efektivnější naopak pro hodně dlouhé stringy. REP je hodně pomalý, ale v některých případech dokáže být dost rychlý, pokud je hodně opakování. (Viz Agnerův optimalizační manuál – základní to bible všech assembleristů. Je to tam dokonce i všechno explicitně změřené a rozložené, kolik cyklů ta která instrukce stráví v jednotlivých jednotkách procesoru. Zároveň je to rozebráno pro řadu různých modelů procesoru.)

21.2.2009 17:56 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: Malý C/C++ quiz
Takže tak jako tak v praxi řešíte formát uložení znaků (který se nevejde dnes už do jednoho bajtu) do bajtů – a tím pádem Vám naplno vyvstává ta endianita, formát uložení znaků a další problémy.

Ne nutně. U UTF-8 endianitu řešit nepotřebujete.

21.2.2009 20:54 Miloslav Ponkrác | blog: miloslavponkrac
Rozbalit Rozbalit vše Re: Malý C/C++ quiz

UTF-8 je sice dobrý importní/exportní formát, ale to je tak asi všechno. Uvnitř programu není efektivní pracovat s UTF-8, a většinou se tak (s výjimkou některých zvěrstev, či případně některých uřžitečných aplikací) také nepracuje.

Pokud chcete argumentovat pomocí UTF-8, pak můžeme zapomenout na nějakou rychlost a efektivitu. Třeba vyhledání koncové nuly je marginální a nezajímavý program a nic oproti problémům, které člověka čekají při práci s UTF-8. UTF-8 se používá jako náhražka tam, kde lidé nebyli schopni stvořit Unicodové API a chtějí to hnát přes staré 8mi bitové API, pak se využívá jeho schopnost zmást „nepřítele“ – tedy jistá míra maskovat se za 8mi bitový string (v některých případech).

Takže UTF-8 si sice zrušíte problém s endianitou, abyste si vyrobili několik dalších.

21.2.2009 21:27 Martin Mareš
Rozbalit Rozbalit vše Re: Malý C/C++ quiz
Odpověď je kupodivu zase stejné, a to existence cache. Pro text v libovolném evropském jazyce je UTF-8 výrazně paměťově efektivnější než UCS-2 nebo UCS-4 a cena cache missu je na řádu stovek obyčejných instrukcí, což bohatě vyváží poměrně malé nesnáze při práci s UTF-8.

Navíc spousta operací s řetězci vůbec nepotřebuje rozebírat řetězec na znaky, nýbrž jenom lepit řetězce k sobě a někam je ukládat, takže i UTF-8 je prostě jen posloupnost bajtů ukončená nulou.

Většinou vychází daleko lépe jako hlavní formát pro řetězce používat UTF-8 a teprve když na nějakém místě v programu potřebujete string nějak složitěji zpracovávat po znacích, převést si ho na chvíli do UCS-4.
21.2.2009 20:46 Martin Mareš
Rozbalit Rozbalit vše Re: Malý C/C++ quiz

Já si matně nemůžu vzpomenout na jedinou výhodu řetězce zakončeného nulou. Pokud budu chtít pracovat se spoustou subřetězců z jednoho řetězce, pořád se dá pracovat s trojicí (řetězec, start_index, délka_subřetězce), která je velice efektivní.

Není, protože zabírá několikanásobně víc paměti, takže se často už nevejde do cache a sbohem, efektivito, bylo nám spolu pěkně. Co se UniCode a spol. týče, tak existenci UTF-8 Vám už připomněl kolega Kubeček ;-)
21.2.2009 20:55 Miloslav Ponkrác | blog: miloslavponkrac
Rozbalit Rozbalit vše Re: Malý C/C++ quiz

Mohl byste mi, prosím, říci, jak jste to myslel s tím nevejitím do cache?

Pokud budu mít subřetězec, a nebude sahat na paměť mimo ten subřetězec – jak by mělo být potřeba více cache, než když to bude samostatný řetězec?

21.2.2009 21:22 Martin Mareš
Rozbalit Rozbalit vše Re: Malý C/C++ quiz
Rozdíl je v tom, že místo jednoho pointeru na začátek podřetězce si musíte pamatovat i délky všech subřetězců, což je rázem dvojnásobek dat.
21.2.2009 14:50 Miloslav Ponkrác | blog: miloslavponkrac
Rozbalit Rozbalit vše Re: Malý C/C++ quiz

„Pokud píši program, u kterého mi na efektivitě nijak zvlášť nezáleží, nepoužiji std::string, nýbrž Haskell“

Jeden z velkých omylů, které dělá mnoho lidí je, že si myslí, že low_level = efektivita a high_level = neefektivita. Nic není více vzdáleno pravdě. C++ má high level konstrukce proto, aby mohl se slušným pohodlím generovat programy stejně rychlé jako zbytečně low level jazyk C. Takže pokud mi na efektivitě a rychlosti výsledného programu záleží, použiji C++ a klidně třídu ::std::string. Největší sranda je fakt, že operace s řetězci pomocí třídy ::std::string jsou rychlejší, než operace psané low level pomocí strlen, strcopy, strcat, a další strxxx hovadiny. Výsledné komplexní operace nad řetězci běží o dost rychleji.

Pokud píšu program, kde mi na efektivitě nezáleží, použiji většinou problémově orientovaný jazyk zaměřený na danou oblast. Haskell je ale skvělý v tom, že namísto programování řešíte rébusy. Navíc se jako jazyk moc nerozšířil, a užitečných programů v něm věru mnoho napsáno nebylo.

21.2.2009 17:57 Radek Miček | skóre: 23 | blog: radekm_blog
Rozbalit Rozbalit vše Re: Malý C/C++ quiz
Haskell je ale skvělý v tom, že namísto programování řešíte rébusy.

A proč to děláte?

21.2.2009 20:45 Martin Mareš
Rozbalit Rozbalit vše Re: Malý C/C++ quiz
Zkuste si někdy srovnat std::string se stringovými operacemi z LibUCW a pak mi řekněte :-)
Haskell je ale skvělý v tom, že namísto programování řešíte rébusy.
Pokud chcete, můžete. Já jsem se raději Haskell pořádně naučil ;-)
21.2.2009 20:58 JS
Rozbalit Rozbalit vše Re: Malý C/C++ quiz

 

Haskell je ale skvělý v tom, že namísto programování řešíte rébusy.
Pokud chcete, můžete. Já jsem se raději Haskell pořádně naučil ;-)

To by me zajimalo, Martine, napsal jsi nekdy v Haskellu nejaky vetsi program (myslim ne skolsky priklad)? Ja jsem cetl pres vanoce nejaky tutorial k Haskellu (tusim ten oficialni), a znechucene jej odlozil, protoze mi opravdu prislo, ze tam resi problemy, ktere uz jsou davno vyresene a bez funkcionalniho programovani by neexistovaly.

 

Pak jsem se koukal na prednasku / cetl knihu Practical Common Lisp, a prislo mi to daleko lepsi, z duvodu urcite pragmaticnosti tvurcu Lispu (coz je stejna vlastnost, pro kterou mam rad Python). Rad bych se tedy poucil, v cem je Haskell pro tebe tak zajimavy.

21.2.2009 21:34 Martin Mareš
Rozbalit Rozbalit vše Re: Malý C/C++ quiz
Opravdu velký program jsem v Haskellu nenapsal (to asi jenom v Céčku a v Perlu, v ostatních jazycích to byly spíš takové štěky na maximálně tisíce řádků), ale jenom triviality to také nebyly. Používám Haskell docela rád, když si potřebuji rychle napsat program, který mi něco spočítá. Na interaktivní věci je někdy trochu nepraktický, pomalu tíhnu spíš k OCAMLu.

Haskell má v sobě také spoustu elegance, asi i víc než většina LISPů. Většinu jeho složitosti tvoří spíš syntaktické zkratky, vytvořené proto, aby se v něm pohodlně programovalo a nebylo potřeba psát tak dlouhé špagety jako v LISPech.
21.2.2009 21:48 deda.jabko | skóre: 23 | blog: blog co se jmenuje "každý den jinak" | za new york city dvakrát doleva a pak už se doptáte
Rozbalit Rozbalit vše Re: Malý C/C++ quiz
Haskell má v sobě také spoustu elegance, asi i víc než většina LISPů.

muzes to rozvest? ja jsem se uz nekolikrat zkousel haskell naucit/pouzivat... a vzdycky jsem to zahodil, protoze jsem nenasel nic zasadniho v cem by byl haskell lepsi nez LISP/Scheme. ma to oproti temto jazykum nejakou killer feature?
Asi před rokem se dostali hackeři na servry Debianu a ukradli jim zdrojové kódy.
21.2.2009 21:52 Martin Mareš
Rozbalit Rozbalit vše Re: Malý C/C++ quiz
Moc pěkná featurka je třeba líné vyhodnocování.

Ale k eleganci podle mého názoru přispívá hlavně to, že nemá side-effecty.

Mně osobně je na Haskellu oproti LISPům rovněž milejší syntaxe, umím v něm psát daleko přehledněji.
21.2.2009 23:01 Radek Miček | skóre: 23 | blog: radekm_blog
Rozbalit Rozbalit vše Re: Malý C/C++ quiz
Moc pěkná featurka je třeba líné vyhodnocování.

Na druhou stranu věc, která se může z hlediska spotřeby paměti velice negativně projevit, když si nedáte pozor.

21.2.2009 21:34 Radek Miček | skóre: 23 | blog: radekm_blog
Rozbalit Rozbalit vše Re: Malý C/C++ quiz

Jen bych místo oficiálního tutoriálu doporučil knihu Real World Haskell.

21.2.2009 20:59 Miloslav Ponkrác | blog: miloslavponkrac
Rozbalit Rozbalit vše Re: Malý C/C++ quiz

Jasně, že lze udělat mnohem lepší třídu, než je ::std::string. Nikde jsem netvrdil, že je to nejlepší třída pro stringy na světě. Ale rozhodně je lepší, a dává rychlejší program, než při použití strxxx funkcí – což je to, s čím jsme srovnávali.

Ohledně Haskellu – pozor! Nabíháte mi na smeč. Já Vám snadno pak opáčím, abyste se pořádně naučil X, přičemž za X mohu dosadit cokoli, a asi bych začal C/C++.

21.2.2009 21:38 Martin Mareš
Rozbalit Rozbalit vše Re: Malý C/C++ quiz
Ohledně Haskellu – pozor! Nabíháte mi na smeč. Já Vám snadno pak opáčím, abyste se pořádně naučil X, přičemž za X mohu dosadit cokoli, a asi bych začal C/C++.
Ejhle, pan kolega mne asi chce vyzvat na souboj. Volím tedy z Vámi nabízených zbraní Céčko. Předveďte se :-)
2.3.2009 10:22 zde | skóre: 9 | blog: Linuch | Brno
Rozbalit Rozbalit vše Re: Malý C/C++ quiz

Jenže podle Ponkráce céčko neexistuje, jenom dohromady s lomítkem a ještě jedním céčkem s dvěma flusítkama. A pak vás umlátí nějakou obskurní templatovou knihovnou, přičemž za důkaz její kvality bude považovat to že nějaký zcestně nereálný případ kde bude všecko const to překladač vyoptimalizuje tak, že z hromady C++ zvratek vypadnou pouhé 3 instrukce :)

Táto, ty de byl? V práci, já debil.
21.2.2009 20:48 Martin Mareš
Rozbalit Rozbalit vše Re: Malý C/C++ quiz
Já bych naopak doporučil Thinking High Level
Já osobně bych tedy doporučil staré dobré přemýšlení na všech úrovních současně. Teprve tak pochopíte, co doopravdy děláte.

Jak praví staré přísloví: "To understand a program you must become both the machine and the program."
21.2.2009 20:53 Käyttäjä 11133 | skóre: 58 | blog: Ajattelee menneisyyttä
Rozbalit Rozbalit vše Re: Malý C/C++ quiz
Jak praví staré přísloví: "To understand a program you must become both the machine and the program."
Tohle je pěkné, to jsem neznal, díky... :-)
21.2.2009 21:00 Miloslav Ponkrác | blog: miloslavponkrac
Rozbalit Rozbalit vše Re: Malý C/C++ quiz

Souhlasím. Řekl jste to lépe, než já. Já jsem hlavně dělal protiváhu k převaze názorů, že low level úroveň je spasitel.

22.2.2009 15:17 Martin Böhm | skóre: 17 | blog: Martinův stánek | Je mi to MFFUK
Rozbalit Rozbalit vše Re: Malý C/C++ quiz
Na všech úrovních současně? A co my, kteří nemáme quad-brain(TM) hlavu? :o)

Obecně k tématu: myslet je důležité, ale občas se splést (a vymyslet trošku pomalejší kód) je lidské. Lidské je rovněž vysmívat se všelijakým chybám a Neználkům, ale tomu se, milé děti, raději vyvarujte.
5 z 0 přetečení bufferu doporučuje Korespondenční seminář z programování (pro středoškoláky programátory).
23.2.2009 22:58 Martin Mareš
Rozbalit Rozbalit vše Re: Malý C/C++ quiz
Na všech úrovních současně? A co my, kteří nemáme quad-brain(TM) hlavu? :o)
Tak nezbývá než simulovat paralelní běh přepínáním kontextu :-)
21.2.2009 21:22 JS
Rozbalit Rozbalit vše Re: Malý C/C++ quiz

Proc by strlen() nemohl prekladac optimalizovat? Ja toho o x86 prekladacich pravda moc nevim, ale vim, kompilator IBM C pro zSeries nahrazuje strlen() jedinou instrukci, kterou mainframove procesory za tim ucelem maji. :-) (Podobne nahrazuje i strncpy(), memset() a memcpy().)

23.2.2009 15:56 Sinuhet | skóre: 31
Rozbalit Rozbalit vše Re: Malý C/C++ quiz

Prosim vas, mohl byste si opravit "reseni" u sedmicky? Zbytecne tim matete neznale ctenare. S predavanim argumentu zprava nebo zleva to nema nic spolecneho, poradi vyhodnoceni argumentu funkce podle stadardu neni urcene, v kombinaci s hrabanim do jedne promenne to vytvari nedefinovane chovani, ten program muze udelat cokoliv (treba zpusobit implozi vesmiru) a bude to v souladu se standardem.

Bylo vam to v diskuzi nekolikrat vysvetleno.

Josef Kufner avatar 23.2.2009 16:52 Josef Kufner | skóre: 69
Rozbalit Rozbalit vše Re: Malý C/C++ quiz
Jop, ta 7 je blbě :) Správná odpověď není 3 2 1 0, ani žádná jiná posloupnost čísel, ale "nedefinováno".
Hello world ! Segmentation fault (core dumped)
23.2.2009 18:27 Deleted [8409] | skóre: 14 | blog: darkblog
Rozbalit Rozbalit vše Re: Malý C/C++ quiz
Sednička nemá řešení, proto je hned na začátku slovo "různé". To, že jsem zmínil, jak by to logicky mělo vypadat, není podle mě žádná chyba. V závěru je napsané, že je to lepší nepoužívat.

PS: Pokud to chcete napsat líp, tak mi pošlete opravu, to mi nic neudělá:)
Josef Kufner avatar 23.2.2009 19:33 Josef Kufner | skóre: 69
Rozbalit Rozbalit vše Re: Malý C/C++ quiz
Ale má řešení ;-) I odpověď, že to není definované je odpověď (a navíc i správná).

To "různé" by se hodilo spíš ke kódu printf("%d\n", 100 * rand()), kde to "různé" opravdu znamená "různé", ale přitom přesně definované chování.

Takže tam prostě napiš "Není definováno." a případně odůvodnění.

Nezapomínej, že ty nehledáš nějaké řešení, ale chceš odpověď. V tom je celkem podstatný rozdíl.
Hello world ! Segmentation fault (core dumped)
23.2.2009 21:03 Sinuhet | skóre: 31
Rozbalit Rozbalit vše Re: Malý C/C++ quiz

No, mozna by me nejaka dlouhonoha dobre stavena dvacitka s velkym vystrihem dokazala ukecat, ze nedefinovane chovani se da povazovat za "vypise ruzne veci", ale hacek je v tom, ze clovek, ktery o nedefinovanem chovani v c/c++ nic nevi, ze slova "ruzne" nema sanci tento pravy duvod zpetne vycist. Korunu tomu nasazujete filozofovanim o volacich konvencich, logice vyhodnocovani a jeji poruseni optimizerem... to by u me nezaretusovala ani ta dvacitka i kdyby mela jen fikovej list a v ruce flasku s lubrikantem.

Založit nové vláknoNahoru

ISSN 1214-1267   www.czech-server.cz
© 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.