• úvod
  • témata
  • události
  • tržiště
  • diskuze
  • nástěnka
  • přihlásit
    registrace
    ztracené heslo?
    XCHAOSANSI C/C99 (specifikace), GNU C (gcc, glibc), Tiny C (tcc) a POSIX - ne nutně C++,g++,libstdc++ nebo Win32 API
    /* Toto je klub především pro lidi, pro které je programování jednou z mnoha massive multiplayer online počítačových her, které lze hrát.
        V tomto klubu hrozí sémantická hereze a nezdravě vysoký obsah syntaktického cukru. Nevhodné pro algoritmické diabetiky.
        Od účastníků debaty se předpokládá automaticky přístup k instalovanému GNU C: sudo apt-get install build-essential
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    C (programovací jazyk)#C99 Heslo na české Wikipedii
    Jazyk C - Základy praktického programování V Praze 2oo7 pro SSPŠ Tomáš Harvie Mudruňka a kolektiv - jak si programování v C představuje většina lidí
    http://stevenkobes.com/ctest.html C Programming Puzzlers - nepouštějte se do flamewars v tomhle klubu, pokud neuhodnete aspoň polovinu správně!
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    http://en.wikipedia.org/wiki/C99 C99 is a modern dialect of the C programming language.
    http://cprogramminglanguage.net/ C programming language
    http://cprogramminglanguage.net/c-programming-language-tutorial.aspx C programming language - úvod
    http://en.wikipedia.org/wiki/Criticism_of_the_C_programming_language C makes it easy to shoot yourself in the foot. (ještě že ne do hlavy...)
    http://en.wikipedia.org/wiki/C_preprocessor
    http://gcc.gnu.org/onlinedocs/gcc/Variadic-Macros.html C99 makra s proměnným počtem argumentů - __VA_ARGS__
    http://gcc.gnu.org/onlinedocs/gcc/ GNU C Compiler
    http://gcc.gnu.org/onlinedocs/gcc-4.2.2/gcc/Optimize-Options.html
    http://bellard.org/tcc/ Tiny C Compiler - prý C99 compliant (min. umí __VA_ARGS__) - vhodný pro skriptování v C - umí #!/usr/bin/tcc -run
    http://en.wikipedia.org/wiki/International_Obfuscated_C_Code_Contest - pokud jste neviděli tohle, tak jste ještě neviděli opravdu nečitelný C zdroják
    http://bellard.org/otcc/ Obfuscated Tiny C Compiler - z tohohle vtípku vznikl Tiny C compiler
    http://en.wikipedia.org/wiki/ANSI_C Jak se střelit do nohy standardizovaným způsobem.
    http://eli-project.sourceforge.net/c_html/c.html ANSI C Specification
    http://www.lysator.liu.se/c/ Různý ANSI C bordel
    http://www.cs.rit.edu/~ats/books/ooc.pdf Object Oriented Programming with ANSI-C - a pak že to nejde
    http://en.wikipedia.org/wiki/Longjmp co jsou to setjmp()/longjmp() knihovní funkce (pro všechny, podle kterých to bez C++ try { } catch() ... nejde)
    http://groups.google.com/group/comp.lang.c++.moderated/browse_thread/thread/dcdc710c27f47c72 C neumí správně počítat (?)
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    http://www.fastcgi.com/ FastCGI is simple because it is actually CGI with only a few extensions.
    http://www.metalshell.com/source_code/18/Mysql_Select.html How to do a simple connection and select with mysql
    http://xmlsoft.org/ The XML C parser and toolkit of Gnome
    http://curl.haxx.se/libcurl/ libcurl - the multiprotocol file transfer library
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    https://dev.arachne.cz/svn/cll1h SVN/Trac jazyka C<<1 (user-friendly nadstavba nad ANSI C99 - ve stylu JQuery vs. JavaScript)
    Benchmark iterace a serializace stringů v různých jazycích vs. v C
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
        moderátor se velice zhruba řídí zvyklostmi moderace, která kdysi platila v řadě konferencí sítě FidoNet ... C != 0xdead */
    rozbalit záhlaví
    XCHAOS
    XCHAOS --- ---
    XCHAOS: tedy dvě jediné abstrakce, chci říct :-)
    XCHAOS
    XCHAOS --- ---
    jako jo, s polem pointerů na objekty (indexem) se dají dělat téměř stejně pěkné věci, jako se spojovým seznam. myslím, že nejlepší protipříklad, který jsem uvedl, je vložení nového prvku poblíž začátku setříděného seznamu (a naopak u jednosměrného setříděného spojového seznamu má podobně brutální režii vložení prvku poblíž konce)

    odtud se dobereme k tomu, že vyšší jazyky typu Python, které nabídnou uživatelům jednu jedinou abstrakci dynamického kontejneru (pole proměnné délky a "slovník"), asi nebudou na některé věci úplně ideální: resp. bude dobré si u nich změřit, jak rychlé je přidávání prvku na začátek vs. na konec dlouhého pole, apod.

    a zejména zajímavé téma je otázka správy paměti pomocí reference counterů použitého u spojového seznamu objektů... z toho by mohl myslím být docela dobrý nový flejm :-)
    REDGUY
    REDGUY --- ---
    XCHAOS: ale nějak si mě pořád nepřesvědčil, že spojový seznam není výhodný nikdy, za žádných okolností. - to myslim uzce souvisi s tim, ze jsem se nikdy o nic podobneho nesnazil, protoze to je pitomost.

    typicky jsme opět u toho, že když víš kolik toho bude, tak je pole docela výhodná struktura. - uhm. To neni pravda. Ve spouste pripadu predem vim "kolik toho bude" a presto je pole spatna struktura a naopak, ve spouste pripadu nevim kolik toho bude a pole je dobra struktura.

    abstrakce kterou nabízí spojové seznamy může mít nezanedbatelné výhody - ano, muze.
    DAVIDOWITCH
    DAVIDOWITCH --- ---
    XCHAOS: Ja musim do prace, ale kdyz si vygooglis OpenGL transformations, tak urcite najdes pekny vysvetleni.
    Pripadne koukni do moderni pocitacove grafiky 2, tam je v zadu appendix o matice v grafice
    XCHAOS
    XCHAOS --- ---
    DAVIDOWITCH: naopak... když už si zmínil to vynásobení matic, tak bych právě hrozně rád viděl nějaký kus kódu/algoritmus, který to reálně používá a je k něčemu užitečný...
    XCHAOS
    XCHAOS --- ---
    REDGUY: typicky jsme opět u toho, že když víš kolik toho bude, tak je pole docela výhodná struktura. ale nějak si mě pořád nepřesvědčil, že spojový seznam není výhodný nikdy, za žádných okolností.

    většina algoritmů, se kterými pracuji, se točí kolem dvou hlavní požadavků na přístup k datům: 1) nalézt prvek splňující určitá kritéria 2) procházet všechny prvky. víceméně neuvažuju tak, že bych měl datové struktury navržené tak, že vyžaduju přístup k n-tému prvku: a pokud seznam obsahuje odkaz do jiného seznamu, tak zase spíš použiju přímo pointer na prvek seznamu než index (mj. mi to umožňuje udržet integritu dat i při setřídění kteréhokoliv z těch seznamů podle libovolných kritérií).

    Výkonnostní výhody polí v prostředí kdy CPU nabízí onchip cache chápu... ale současně trvám na tom, že abstrakce kterou nabízí spojové seznamy může mít nezanedbatelné výhody zvlášť pokud máme více složitějších, vzájemně provázaných datových struktur.
    DAVIDOWITCH
    DAVIDOWITCH --- ---
    XCHAOS: No, tak to asi ne. V tom pripade bych to pouzil jako jasnou ilustraci toho, ze to ze nejaka vec co te v matice ucej neni okamzite a jasne patrna jeste neznamena ze to za 2-3 roky nebude superdulezitej kus pocitacovejch ved. (disclaimer: jakozto hardwarar + grafik muzu mit na tohle nestandardni nazor)
    XCHAOS
    XCHAOS --- ---
    DAVIDOWITCH: kdybych tam vydržel hned po gymplu, psal by se rok 1994 (resp. 1995, kdybych býval opakoval první ročník, což se mi nechtělo ale možná bych to i dal, těžko říct). popravdě, myslíš že v roce 1994 by mě učili OpenGL? (možné to je, těžko říct)
    DAVIDOWITCH
    DAVIDOWITCH --- ---
    XCHAOS: No, kdybys treba na tom FELu vydrzel do ctvrtyho semestru, byl pomerne peknej predmet o OpenGL.
    REDGUY
    REDGUY --- ---
    XCHAOS: A uz jsme si taky vysvetlili, ze realloc se provadi pomoci prehozeni stranek pameti jen nekdy, typicky kdyz mas ty pameti fakt velky kusy. A co se rezie tyce... no, to dost zalezi na konkretnim problemu, nez aby bylo mozne rict co ma podstatne vetsi rezii, ze.
    XCHAOS
    XCHAOS --- ---
    REDGUY: no... já jsem začínal s programováním v éře, kdy CPU neměly (AFAIK) prakticky žádnou onchip cache - ale naopak alokování tak velkého pole, kvůli kterému se část RAM odswapovala na disk, mohla program spolehlivě zabít a uvrhnout celý systém do mnohaminutového chroustání.

    už jsem si myslím vysvětlili, že realloc() provedený pouze pomocí přehození pořadí stránek paměti pokládám za vcelku elegantní řešení. (pokud jsem realokaci pole prováděl já "ručně", tak to znamenalo kopírovat poměrně velké kusy paměti, což tedy mělo podstatně větší režii, než nějaký rozdíl mezi rychlou/pomalou pamětí)
    XCHAOS
    XCHAOS --- ---
    DAVIDOWITCH: jo... asi mě někdo zapomněl naučit, jak se dělá 3D grafika pomocí násobení matic :-) (nebo jinak: ačkoliv jsem v tom věku běžně programoval v C, tak se kladl velký důraz na to, naučit mě násobit matice tužkou na papíře - ale menší důraz na to ukázat, k čemu je to dobré - pokud tenhle klub ten deficit napraví, nebudu se vůbec zlobit)
    REDGUY
    REDGUY --- ---
    XCHAOS: Nasobeni matic neni zdaleka jedina vec, kde ti spatna prace s pameti muze zabit vykon. (*cough* pouzivani spojovejch seznamu misto poli *cough*)
    DAVIDOWITCH
    DAVIDOWITCH --- ---
    XCHAOS: O grafice si nekdy slysel? Veskery transformace v OpenGL/DX (tj. uplne v cemkoliv co se pouziva) jsou skrze nasobeni matic.
    ANT_39
    ANT_39 --- ---
    XCHAOS: Asi tak tri roky zpatky tu ALMAD poprve posilal link na drepperuv paper o cachich. (Potom to tu probehlo jeste tak trikrat.) Porad jeste to stoji za precteni.
    XCHAOS
    XCHAOS --- ---
    ISTEVE: jj, chápu. akorát že pro mě je častější zadání "pracuju s něčím, čeho nevím při startu programu, kolik toho přesně bude", než že bych násobil matice (popravdě, toto je přesně věc, kterou mi ve VŠ matice nikdy nenaučili: do zblbnutí mě pokaždé v nižších ročnících nutili násobit matice nebo - jinak s nimi operovat - samozřejmě ručně, co na tom, že jsem takový program uměl napsat už div ne na základní škole, který by to dělal - ale nikdy mi nevysvětlili, k čemu je to dobré v praxi :-)
    ISTEVE
    ISTEVE --- ---
    XCHAOS: Zkus si nasobeni matic (takovy to "radek krat sloupec"). Pak si zkus nasobeni matic s tim, ze si tu matici kterou bych prochazel po sloupcich transponujes. Zmer rozdil.
    XCHAOS
    XCHAOS --- ---
    Tenhle klub jsem právě zakládal proto, aby člověk co se cítí doma v C (tedy je třeba si sám ochoten řešit správu paměti, nebo aspoň přemýšlení o ní - a tedy řeší např. co se mu doopravdy vejde do paměti a u čeho naopak hrozí, že mu to na slabším stroji (nebo při větším množství paralelně spuštěných procesů) vyswapuje na disk, mohl nahlédnout odbočky na nižší i vyšší level: nižší level znamená zrovna třeba přihlédnout k propustnosti sběrnice a optimalizovat směrem na cacheování uvnitř CPU - a ten vyšší level je zase poohlédnout se po sofistikovanějších abstrakcích, které nabízí různé vyšší jazyky a ukázat, jak by se srovnatelná funkce dala implementovat v C.
    XCHAOS
    XCHAOS --- ---
    JACHYMKO: jako právě tohle je level optimalizací, na který já jako "čistý céčkař" (ale ne assemblerista) už běžně nedohlédnu (stejně jako uživatel vyššího jazyka nedovede posoudit, jak mu ten jazyk zvyšuje režii oproti třeba právě C)
    XCHAOS
    XCHAOS --- ---
    (jinak souhlasím s id JACHYMKO, že matici je asi moudré v C reprezentovat jako vícerozměrné pole, protože ta architektura je rovnou navržená aby to bylo stejně efektivní, jako vypočítat si ze souřadnic index v nějakém jednorozměrném bufferu.... u vyšších jazyků to z různých důvodů nemusí být pravda - např. by tam mohl dvakrát volaný nějaký kód pro kontrolu zda indexy nepřekračují hranici pole, apod. - nechci rozpoutat flejm, jak to na které architektuře je jak moc optimalizované... ale zrovna nad implementací vícerozměrných polí v jazycích připouštějících re-alokaci pole za chodu a /nebo kde je dvourozměrné pole implementované jako kontejnerový objekt obsahující jiné kontejnerové objekty bych se klidně s chutí zasmál :-))
    Kliknutím sem můžete změnit nastavení reklam