• ú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í
    REDGUY
    REDGUY --- ---
    XCHAOS: něco, co se použije místo malloc() když programátor uzná za vhodné - jen tak pro kontrolu, vis ze malloc sam o sobe je dost chytrej a jaksi kondenzuje zkusenosti a znalosti spousty programatoru? A cilem tveho pry na uziti jednodussiho alokatoru je tuhle chytrost zahodit a nechat na programatorovi at premejsli co pouzit? Chapu to spravne?
    DAVIDOWITCH
    DAVIDOWITCH --- ---
    XCHAOS: Ja chtel rict, ze i uplne obycejnej vanilla malloc co se provede kdyz proste vemes gcc a udelat malloc, je zatracene draha sranda.
    XCHAOS
    XCHAOS --- ---
    DAVIDOWITCH: tak minimálně je to obvykle ta funkce, která se nahrazuje, když místo běžného malloc() použiješ nějaký složitější, s nějakým sofistikovanějším GC... takže tady jsem neměl na mysli ten konkrétní standardní, ale mluvil jsem "co se děje na místě, kde se volá malloc()" - kde můžou být použité různé implementace správy paměti, které lze srovnávat, viz [ ANT_39 @ ANSI C/C99 (specifikace), GNU C (gcc, glibc), Tiny C (tcc) a POSIX - ne nutně C++,g++,libstdc++ nebo Win32 API ]

    když se použije místo standardní správy paměti nějaká sofistikovanější, tak se pak nahrazuje i volání toho malloc() voláním jiné knihovní funkce (ať už to řeší pomocí #define nebo prostě tak, že jen použiješ jiný header file a samotná funkce se jmenuje stejně... ).

    jinými slovy se chci dobrat k tomu, že "každý malloc() dělá něco jiného" - a můj projekt pak není v kategorii "1000+první náhrada za malloc() implementovaná jako diplomka" (které další diplomky mezi sebou co nejobjektivněji porovnávají", ale spíš v kategorii "něco, co se použije místo malloc() když programátor uzná za vhodné".
    XCHAOS
    XCHAOS --- ---
    ANT_39: resp. srovnáním jeho výkonu. no, u mě by ten výkon přeměřit dost dobře nešlo, protože je to určené jen na speciální použití...

    ANT_39: no já tak trochu předpokládám, že si načtu nějaký ten get_rlimit a vyjdu třeba z velikosti stacku jako základní jednotky pro alokaci...

    (taky je zajímavé zvolit vhodnou strategii pro tu formátovací alokaci ve stylu asprintf - viz man sprintf - dělá se to pomocí jakéhosi vsnprintf a víceméně se zkusmo testuje, jestli se do řetězce dané délky vejde...)
    ANT_39
    ANT_39 --- ---
    XCHAOS: Ta diplomka se nezabyva garbage kolekci, ale klasickyma alokatorama.
    ANT_39
    ANT_39 --- ---
    XCHAOS: Tak mohl bys povolit realloc vrchniho chunku, ale zalezi, jestli tam bude operace free pro jednotlive chunky (musel by sis nekde drzet delku tech jednotlivych bloku).
    JANFROG
    JANFROG --- ---
    REDGUY: :-) OSX (resp. ObjC runtime) nemuze pouzit nic lepsiho nebot nezna strukturu dat. Navic, co neresi cyklicke reference nepovazuji za GC.

    Dalsi problem pocitani referenci co si malo lidi uvedomuje je ze vicevlaknovych aplikacich je treba zvusit counter pri kazdem predani parametru funkci a snizit kdyz volani skonci.
    To to take dost prodrazi...
    REDGUY
    REDGUY --- ---
    XCHAOS: Nevim jestli to chapu spravne, ale ty planujes mit jednu alokacni funkci, ktera na zaklade nejakeho globalniho stavu bude delat dve nebo tri zasadne ruzne veci? To je imho velmi spatne.
    DAVIDOWITCH
    DAVIDOWITCH --- ---
    XCHAOS: Aha, tak to asi nema smysl se o cemkoliv bavit, pokud nemas alespon ramcovou predstavu co vlastne dela malloc.
    XCHAOS
    XCHAOS --- ---
    REDGUY: je to trochu jinak.. právě proto jsem chtěl to flow-control makro forget{ } (jak si zašal prudit, že uvnitř toho není definovaný chování continue a break :-)

    v podstatě jsem si představoval, že ty režimy jsou dva - ale spíše jsou tři, a jen jeden z nich je standardní malloc

    představ si tyhle vnoření

    main { /*alloc=malloc*/ forget { /*alloc=xalloc*/ remember { /*alloc=malloc*/ } } }

    vs.

    main { /*alloc=malloc*/ forget { /*alloc=xalloc0*/ forget { /*alloc=xalloc1*/ remember { /*alloc=xalloc0 */ } } } }

    v podstatě moje myšlenka na promísení forget{ } a remember{ } maker vede ke třem možným stavům (pokud ten top-level očekávaný stav má být malloc) ... a ještě bych to doplnil o nějaké allocate{ } flow control makro, ve kterém by alloc byl vždy malloc().

    tím, že nepřepínám kontexty, ale tvrdě hlídám začátek a konec scope je to zejména vhodné ke strukturám typu

    forget {void *tmp1r=get_něco(), *tmp1r=get_něco() }

    protože se ti naalokovaná paměť na konci místní scope uvolní spolu s definicema těch proměnných, co na ní odkazují. já takto víceméně jednak programovat chci, jednak už vím, jak toho dosáhnu, ovšem jak už jsem citoval Henryho Forda jinde - stěží si vybuduju reputaci na tom, že se to chystám udělat - budu muset jít a udělat to :-) důvod proč jsem to neudělal je prostě ten, že mi některé kombinace nebyly jasné, a že jsem pořád dost tvrdě ignoroval, že jeden z režimů ve kterých se budu chtít pohybovat, by měl natvrdo být "fallback na malloc()" - tedy ta samá moje funkce (postavená na toolkitu) použije malloc() když jí zavolám jen tak z main() bez uvedení další speficikace, ale že naopak použije bleskové memory pooly, když jí zavolám uvnitř svého forget { } scope.

    takže zadání pro sebe mám jasné - nepíšu univerzální náhradu malloc(), ale píšu jakési svoje "get_cosi(...)" či "get(cosi,...), které má jako jeden z režimů malloc(): na uvolňované pointery se může free() v případě, že volající ví, co dělá - typicky se free zavolá na nějaké více "vnější" vrstvě programu.

    další možnost je definovat dispose(), které si zkontroluje, zda pointer neukazuje dovnitř aktuálního memory poolu - a teprve pokud ne, tak na to zavolat free a pokud ano, tak snižovat nějaký vnitřní counter memory poolu až do té míry, že by např. stránka memory poolu obsahující právě jeden záznam byla ozačená jako volná...

    lze si to představit jako trochu sofistikovanější přepínání mezi malloc() a alloca() - s tím, že alloca() není omezené na velikost stacku.

    víceméně vám tohle může připadat jako dlouhé a jako blábol - ale pro mě je to naopak zdůvodnění toho, proč se o tom s někým radím online (a musím přetrpět všechen výsměch a flamewary) - protože se víceméně pořád držím své původní koncepce, ale zahrnul jsem do ní některé docela chytré přípomínky, které tu zazněly. a teď bych asi fakt měl sednout a naprogramovat to :-)
    XCHAOS
    XCHAOS --- ---
    DAVIDOWITCH: mě přijde, že ten malloc() je docela rychlej, ale to může záležet na implementaci ... v některý implementaci malloc() může být klidně schovaný volání garbabge collectoru, který hledá volné místo...
    XCHAOS
    XCHAOS --- ---
    ANT_39: to je zajímavý odkaz, ale upozorňuju, že moje (rozpracované) memory pooly nejsou plnohodnotná náhrada obecného alokátoru zahrnujícího zcela obecnou garbage collection... od začátku počítám s tím, že je tam nějaký tradeoff, tedy že něco bude rychlejší - a na oplátku to něco jiného nebude umět vůbec
    REDGUY
    REDGUY --- ---
    XCHAOS: a proc nemuzes kratke stringy a docasne veci drzet na stacku?
    XCHAOS
    XCHAOS --- ---
    ANT_39: no tak s tím reallocem právě moc nepočítám - resp. neumím si to představit. pokud si budeš chtít pole reallocovat, mělo by to být pole alokované v první řadě normálním allocem().

    mám to myšlené hlavně na krátké stringy a různé dočasné obsahy textových souborů či HTTP requestů načtené do paměti... jinak moje oblíbená struktura spojový seznam je s touto metodou alokace kompatibilnější, než právě třeba pole náhodné délky :-) vlastně jste mě moje vize nejvíc rozbili tím, jak jste mě upozornili, že díky cacheování paměti přímo v jádře CPU už nejsou spojové seznamy až tak efektivní, jako byly např. v éře před 15ti lety (kdy se _už_ nedělalo onboard cacheování RAM, ale současně se _ještě_ nedělalo onchip cacheování...)
    REDGUY
    REDGUY --- ---
    JANFROG: ehm. OSX neni slusny system?
    JANFROG
    JANFROG --- ---
    JACHYMKO: Budes se divit, ale je. Protoze pri pocitani referenci, overhead prirazeni je
    - fetch, decrement, store
    - fetch, increment, store

    To je duvod - krom cyklickych referenci - proc se pocitani referenci nepouziva jako garbage collector (ve slusnych systemech)


    REDGUY
    REDGUY --- ---
    kolikrát by si se zdržoval počítáním referencí i ve chvíli, kdy ti je jasné, že paměť o pět řádků dál zase zahodíš - nerozumim. Jak, zdrzoval? Reknu si o pamet, o pet radku dal reknu at se zmensi pocet referenci a pamet se uvolni. Kde je zdrzovani? Mozna bys mel ukazat nejake konrektni use-case kde si myslis ze bude tvuj pristup lepsi, ne?
    DAVIDOWITCH
    DAVIDOWITCH --- ---
    Skoro vubec? Alokovat pamet na pet trivialnich radku je samo o sobe podezrely, na pet komplexnich radku te to nezdrzi a tech pet komplexnich radku muze delat veci volnejc.
    XCHAOS
    XCHAOS --- ---
    REDGUY: no ano, já dokonce chvíli vymýšlel, že kdyby se místo = použilo nějaké makro - třeba let( ) - tak by to šlo poloautomatizovat. ale fakt je, že na to prostě kašlu - vezmi si jen, kolikrát by si se zdržoval počítáním referencí i ve chvíli, kdy ti je jasné, že paměť o pět řádků dál zase zahodíš...
    REDGUY
    REDGUY --- ---
    XCHAOS: počítaný reference jsou v C vyloučený, v podstatě. - ale kdeze. Kdyz uz, tak _automaticky_ pocitany reference jsou vylouceny. Normalni pocitani referenci delat muzes zcela bez problemu, akorat se o to musis starat (uplne stejne jako se budes aspon castecne muset starat o alokaci pameti v tvem systemu).
    DAVIDOWITCH
    DAVIDOWITCH --- ---
    XCHAOS: Nebyla tu uz debata o pocitanejch referencich?
    Shrnu co si pamatuju: Ne, nejsou vylouceny. Ne, nepotrebujes pretizeny operatory. Ano, musis pak delat add/remove manualne. Koukni se na ObjectiveC jak to dela.
    (netreba se o tom hadat, ja svoji pozici nezmenim, ty svoji pozici nezmenis, jen sem to chtel pripomenout).

    To co tu resis je uplne klasickej mempool. Ma to spoustu vyhod (rychla alokace, rychla dealokace), ale jakmile to jednou alokujes, nemuzes to uvolnit jinak nez vsechno najednou. Obal si necim mallocy a zjisti jaky mas bezny access patterns pro svoje planovany pouziti.
    XCHAOS
    XCHAOS --- ---
    DAVIDOWITCH: počítaný reference jsou v C vyloučený, v podstatě.

    uvažuju "ukusovat" malé kousky paměti z větších bloků a hlídat jen "kolik ještě zbývá"... a pak zahazovat ty větší bloky najednou.

    spíš nevím, jestli to dělit na "malloc/krátkodobé" nebo "malloc/střednědobé/krátkodobé".
    Kliknutím sem můžete změnit nastavení reklam