• ú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 --- ---
    REDGUY: no podívej... asi takhle... pokud v normálním C stylu použiješ return před tím, než uvolníš paměť - tak se stane co ? máš alokovanou paměť - ale pointery na ní ti zmizely spolu se scope, který jsi opustil. jsi úplně stejně v pytli.

    tvoje "nesmíš skákat do jiného kontextu" je úplně bezpředmětné - nejhorší, co ti hrozí, je prostě neuvolnění paměti: je to stejné, jako obejít/vynechat několik příkazů free() - a u složitějšího kódu klidně HODNĚ příkazů free, popravdě.

    první příklad - totiž že ve chvíli alokace paměti často nevím, jak dlouho jí budu potřebovat - byl samozřejmě hodně dobrý. toto je velký problém, a kontexty/pooly to neřeší: je to stejné jako s polem - pole je skvělé, pokud "víme, kolik toho bude" a nepotřebujeme dodatečně vkládat náhodně položky na jeho začátek. no a s tímhle je to stejné: kontexty jsou fakt výkonné - kromě případu, že předem nevíš, co s tou pamětí budeš dělat. tam si měl pravdu - ale vycouval si, a teď vymýšlíš nesmysly.

    na nesmyslné protipříklady z dnešního večera už nebudu nijak reagovat - ale prozradím ti, že bych pokládal za užitečné moct individuální pointery buď vyčlenit z kontextu forget { } - a zařadit je do nadřazeného remember { } kontextu. jo, bude to mít určitou režii - ale pořád asi menší než fyzické kopírování bajt po bajtu (on totiž ten "kontext" je nakonec stejně jen spojový seznam pointerů na alokované bloky, co jiného...). (samozřejmě problém je v tom, že to jednoduše nejde - nebo ne bez obětování všech výkonnostních výhod memory poolu)

    prostě tvoje kritika je strašně samoúčelná, protože máš prostě strašně intenzivní nutkání mě kritizovat a to úplně za každou cenu: je jasný, že můj návrh není zcela univerzální: jenom je vhodný ve slušném počtu počtu případů, které se v "tradičním" C řeší zbytečně pracně. a nepřináší žádné nové problémy, které by ti nevznikaly úplně běžně i u většiny ostatních programátorských pokusů v C ...
    REDGUY
    REDGUY --- ---
    XCHAOS: máš tam místo toho třeba pět nějakých pointerů na nějaké struktury, pole stringy - prostě objekty vytváření "za pochodu", které tak či onak musíš alokovat a na které musíš na konci ručně volat free() Hele, je to sice tezky mezi slzama smichu, ale zkusim chvilku trochu vazne: myslel jsem ze celej smysl tohohle tvyho predstaveni je udelat system, kterej te zbavi nutnosti explicitne uvolnovat pamet. Aby sis proste mohl rict o pamet kdy ji potrebujes a ona se "sama", bez nejake tvoji akce, ve vhodnou chvili vratila systemu. Postupne jsem ti do toho nasekal diry, takze nakonec jsme se dostali do situace, kdy to sice funguje (udajne, protoze samozrejme implementace je hudbou budoucnosti), ALE:

    - nesmis pouzivat goto z jednoho kontextu do druheho
    - nesmis pouzivat setjmp/longjmp z jednoho kontextu do druheho
    - nesmis pouzivat return a _musis_ strukturovat kod odpovidajicim zpusobem.

    Oukej, jeste jakz-takz chapu ty prvni dva body, pro sudlani nejakejch blbinek to asi nevadi. Ale ta posledni v podstate eliminuje veskery vyhody ktery jsi ziska. Copak ti neni jasny, ze pokud musis strukturovat kod tak, aby vzdycky dosel na konec bloku funkce, tak sice usetris psani free, ale to ti bohate vynahradi slozitejsi kod?
    XCHAOS
    XCHAOS --- ---
    ISTEVE: no prý je na tohle několik názorů, kolik returnů by měla mít "hezká" funkce :-) je tam ale asi menší konsensus, než třeba ohledně používání/nepoužívání goto.

    + [ XCHAOS @ ANSI C/C99 (specifikace), GNU C (gcc, glibc), Tiny C (tcc) a POSIX - ne nutně C++,g++,libstdc++ nebo Win32 API ] .. je velká otázka, zda se v systému odchytávání vyjímek počítá třeba s tím, že funkce ještě budou vracet NULL nebo -1 při chybě ... pořád chápu potřebu nějakého větvení funkce a užitečnost více returnů, sám jsem takhle programoval léta - ale popravdě, pokud funkce na konci dealokuje třeba 10 dočasných objektů, které alokovala na začátku, tak si piš, že u ní každý příčetný coder použije jediný return (po všech těch ručních deinicializacích) - a nebude ty deinicializace copy+pastovat před každý return.

    jestli to tak dělá id REDGUY, to je jiná věc... a když jsme u toho... on se sice zatím nepřeklepl na numerické klávesnici, ale počtem správných odpovědí v tom testu se taky zatím nepochlubil :-)
    XCHAOS
    XCHAOS --- ---
    (nemluvě o tom, že při použití s try { } a odchytáváním vyjímek, což je pro mě hrozný nezvyk, ale dnes je to pokládané za hodně moderní přístup k návrhu aplikací, by asi v té funkci bylo několik úniků pomocí fail() (tedy v C++ throw, v Pythonu raise, apod.) - a jen jeden return - platné hodnoty, žádné "-1 = chyba" ... není to sice pravidlo, ale je to dnes opravdu častý přístup, jak mi tady jistě potvrdí fanoušci C++ ...)
    ISTEVE
    ISTEVE --- ---
    XCHAOS: "return se doporučuje používat na konci :)" ... ten smajlik mam brat jako vtip? Pac pokud ne, tak zas citation needed ;]
    XCHAOS
    XCHAOS --- ---
    REDGUY: return se doporučuje používat na konci :)

    mě to tak směšné nepřijde: máš tam místo toho třeba pět nějakých pointerů na nějaké struktury, pole stringy - prostě objekty vytváření "za pochodu", které tak či onak musíš alokovat a na které musíš na konci ručně volat free()

    fakticky nakopíruješ těch pět volání free() před každý return v té funkci ?

    mimochodem - z mého kontextu půjde předčasně escapnout pomocí instrukce continue; - a dealokace se pochopitelně provede - tedy design pattern je následující:

    rv=0;
    forget
    {

    if(redguy)
    {
    rv=-1;
    continue;
    }


    }
    return rv;

    toto opravdu není nic, co by bylo nějak nepoužívané, nesrozumitelné, a nedělalo se to hlavně i v případě, že potřebuješ uvolnit paměť JAKKOLIV JINAK, ukončit spojení, uzavřít soubory apod. - prostě funkce, které mají jediný return a ne padesát, jsou mezi programátory dlouhodobě pokládané za vcelku dobrý nápad, není to z mé hlavy.
    REDGUY
    REDGUY --- ---
    XCHAOS: takže si dobře rozmysli, který design pattern nese větší rizika čeho, než některý zatratíš... - takze memory leaky jsou pro tebe "design pattern"? HAHAHAHAHAHAHAHA. Takze je v poradku ze tvuj "alokator" zacne leakovat pamet na vsechny strany, jen co se do nej opre lehky vanek (treba return uprostred funkce), protoze je prece "design pattern" ze se program pro jistotu kazdejch pet minut restartuje a je to prece lepsi nez segfault? HAHAHAHAHAHA.
    REDGUY
    REDGUY --- ---
    XCHAOS: v dokumentaci bude tedy [...] zmíněná i nevhodnost použití returnu z funkce. - HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA. Proboha. Tebe bych si fakt nedokazal ani vymyslet.

    Hele, co na tohle rict. Snad jen ze opravdu urpimne obdivuju zarputilost, s jakou dokazes navzdory vsem argumentum proti hajit i tu nejvetsi pitomost, jen proto ze to je tvuj oblibeny projekt a nedovolis aby ti ho nekdo rozbil, obzvlast ten zlej redguy. Ale tohle uz je fakt hodne, hodne, hodne zly. "return se nedoporucuje pouzivat"... to ze "nedoporucuje" je eufemismus pro "kdyz to udelate, pravedpodobne vam to bude brutalne leakovat" je ten nejmensim problem 8)

    Ale mam pro tebe dobrou zpravu: existuje cesta z tohohle pruseru, nezarhnujici podobny idiotsky omezeni v dokumentaci. Sice neni moc elegantni, ale fungovalo by to (resp. resilo by to tenhle problem, mozna (skoro urcite) by to melo jiny potize plynouci z designu tveho bastlu). Schvalne jestli na to prijdes 8)
    XCHAOS
    XCHAOS --- ---
    XCHAOS
    XCHAOS --- ---
    REDGUY: v C se dostaneš do nekonzistentního stavu i spoustou jiných způsobů. chápu, že tě baví upozorňovat, že do lodi teče - ale to co vyvíjím já, je spíš takový vor: vor může mít díry a stejně do něj neteče.

    pro začátek si ujasni, co reálně vadí víc:
    - memory leaking (v C opravdu ČASTÁ chyba, přiznejme si to - i bez mých nápadů) nebo
    - přístup k již dealokované paměti ?

    memory leaks jsou tak častá chyba, že třeba i server Apache se pro jistotu po (konfigurovatelném) množství přístupů zrestartuje, aby uvolnil paměť. je to jeho normální činnost: neohrožuje to stabilitu, nic. jen to šetří resourcy systému.

    naproti tomu přístup k dealokované paměti znamená segfault.

    takže si dobře rozmysli, který design pattern nese větší rizika čeho, než některý zatratíš...
    XCHAOS
    XCHAOS --- ---
    REDGUY: mno. hmm. teď si fakt našel výrazně lepší protipříklad, než ty předchozí :-) tedy ne, že by return z funkcí z míst, kde si na konvenčně alokovanou paměť nezavolal free(), způsobil cokoliv jiného - ale budiž.

    gratuluju - v dokumentaci bude tedy kromě nekompatibility z goto a setjmp/longjmp tedy zmíněná i nevhodnost použití returnu z funkce.

    (víš, oni někteří hnidopichové se dokonce domnívají, že by funkce měly pokud možno mít jen jediný return na konci - a uvnitř by měly být normálně strukturované na cykly a podmínky a max. nastavovat návratovou hodnotu... ale já se přiznám, že to hodil za hlavu a neřešil, proč by to tak mělo být... zajímavé)
    REDGUY
    REDGUY --- ---
    XCHAOS: oznamenat, že pokud všechny pointery alokované uvnitř forget { } také DEKLARUJEŠ uvnitř toho scope (což je hezká vlastnost C - že v jakémkoliv scope můžeš deklarovat další lokální proměnné), tak že se nemůže stát, že bys na tu dealokovanou paměť přistupoval za koncem scope? - coze? Nerozumim. Tohle je podle tebe reseni toho problemu se setjmp/longjmp? Tam nejde o _pristup_ k te pameti, tam jde o to, ze longjmp te dostane z jednoho kontextoveho bloku do druheho aniz by si toho tvuj bastl vsiml a tim se dostanes do nekonzistetniho stavu.
    REDGUY
    REDGUY --- ---
    Hele, xchaosi, sice mam jen velmi mlhavou predstavu o tom, jak to budes implementovat (a neco mi rika ze ty taky), ale jen tak cvicne, predstav si tohle:
    char * foo(void) {
      forget {
        GET_MEMORY;
        remember {
          GET_MEMORY;
          forget {
            GET_MEMORY;
            remember {
              GET_MEMORY;
              return stuff;
            }
          }
        }
      }
    }
    


    Jakym zpusobem se uvolni pamet v tech dvou forget blocich? Jestli forget/remember jsou jen nejaky wrappery kolem for, tak ten return je zcela odignoruje a proste se vrati, bez nejakyho uklidu. Nebo mi neco unika?
    XCHAOS
    XCHAOS --- ---
    ISTEVE: jo, no tak samozřejmě :-) záložky v některý IRC klientech byly fakt zmatená věc, snadno se to pastlo do jiného okna...

    a v té době byl lamer taky ještě celkem underground, že jo :-)
    XCHAOS
    XCHAOS --- ---
    REDGUY: ve skutečnosti - unixové manuálové stránky k C knihovním funkcím jsou plné poznámek o různých kompatibilitách a nekompatibilitách.

    ano, našel si hrozivý příklad na možný memoryleak - v prostředí, kde i bez mých nápadů je leakování paměti tak jako tak jedna z nejčastějších chyb. gratuluju.

    ale co takhle poznamenat, že pokud všechny pointery alokované uvnitř forget { } také DEKLARUJEŠ uvnitř toho scope (což je hezká vlastnost C - že v jakémkoliv scope můžeš deklarovat další lokální proměnné), tak že se nemůže stát, že bys na tu dealokovanou paměť přistupoval za koncem scope? já vím, detail. něco takového vymýšlí hloupí estéti, překlepávající se na numerické klávesnici. chytrého matematika by ani nenapadlo, že by mohl udělat chybu - a tak ani nenavrhuje takový styl programování, který by umožňoval chybám předcházet....
    ISTEVE
    ISTEVE --- ---
    XCHAOS: ...nebo jako heslo na router :]
    XCHAOS
    XCHAOS --- ---
    REDGUY: je to duplicitní - první dvě zmínky byly vtipný, ale překlep na numerické klávesnici není vtipný donekonečna -není to tak vtipné jako to "vzrušování" na qwerty klávesnici, které bodovalo na lamerovi....
    XCHAOS
    XCHAOS --- ---
    ISTEVE: jinak ten test na jednom místě nahlas předpokládá, že velikost pointeru i intu je 2 a zmiňuje to - ale na dřívějším místě to předpokládá tiše, což mi celkem i zmátlo. test je dobrý a podle mě málokdo tady udělá všech 16 bodů - některé otázky jsou easy, ale je tam pár chytáků (hlavně ty vícerozměrný pole) a pár jsem vzdal rovnou.

    akorát bych do prvního odstavce dal že se předpokládají dvoubajtové inty i pointery (místo aby se to na jednom místě zamlčelo a na druhém uvedlo explicitně)
    REDGUY
    REDGUY --- ---
    XCHAOS: protože sizeof(int)=4, aspoň na dnes běžných architekturách (v MS-DOSu to bylo 5) - BUAHAHAHAHAHAHA. 16-bit MacOS, sizeof(int) == 5 na MSDOSu... Ty bejt stand-up komikem, rad si zaplatim za vstupny 8)

    XCHAOS: děkuji, že si mě nasměroval na budoucí znění dokumentace, kde bude výslovně doporučené používat to v kombinaci s try { fail() } except { } a ne s goto/setjmp/longjmp. - no konecne jsme se dostali k tomu ze posix neposix, setjmp je nekompatibilni s stvym bastlem (uplne stejne jako goto). Neni zac, az budes priste zase vykrikovat coze jsem dokazal ze si te dovolim kritizovat, podivej se do dokumentace na tuhle poznamku at si to pripomenes 8)


    XCHAOS
    XCHAOS --- ---
    _BENNY: no dobře, ale tak aspoň snad je jasný, že TAKHLE blbej nejsem ani já, ne ?
    XCHAOS
    XCHAOS --- ---
    ISTEVE:
    _BENNY: kurňa, tohle je fakt zákon schválnosti :-( test počítá se sizeof(int)=2, tak jsem chtěl podotknout, že to pamatuju, a debilně jsem se uklepl.

    ale konekonců, lepší se asi smát překlepu, než když někdo něco neví
    Kliknutím sem můžete změnit nastavení reklam