• ú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: máš milion jiných případů, kdy prostě return z prostředku funkce neuděláš - prosim, ukaz mi jeden pripad z toho milionu. Bud tak hodny.

    ty ovšem neodpovídáš na ŽÁDNÉ otázky (či nereaguješ na podněty), ty jsi fakt o level výše, koukám... - wut? A co asi delam posledni dve hodiny? V linkovanem prispevku neni jedina otazka. Prosim, na kterou tvoji zasadni otazku jsem neodpovedel?
    XCHAOS
    XCHAOS --- ---
    REDGUY: k uvolňování paměti uprostřed funkce jen odkážu co jsem už psal:
    [ XCHAOS @ ANSI C/C99 (specifikace), GNU C (gcc, glibc), Tiny C (tcc) a POSIX - ne nutně C++,g++,libstdc++ nebo Win32 API ]

    máš milion jiných případů, kdy prostě return z prostředku funkce neuděláš - a pokud jsi normální, tak to nepořešíš tak, že nakopíruješ X řádků kódu před tím return doprostřed. prostě to neuděláš. (ale pochopitelně: na nepříjemné výtky tady musím reagovat jen já.. ty máš výsadu mlčení)

    já tu _jednou_ použil argument, že snad nemusím odpovídat na všechny otázky - ty ovšem neodpovídáš na ŽÁDNÉ otázky (či nereaguješ na podněty), ty jsi fakt o level výše, koukám...
    ISTEVE
    ISTEVE --- ---
    XCHAOS: Nesouhlasim. Na jedny strane mam pravidlo "Co naalokujes, to uvolnujes". Na druhy strane mam pravidlo "O pamet se starat nemusis, je to pohodlny, akorat se ti to posere kdyz udelas return z funkce pred jejim koncem a nekolik dalsich -- exotictejsich -- veci". To druhy ma podivuhodnejsi a prekvapivejsi vyjimky, predevsim vzhledem k tomu na jakym jazyku stavi.
    XCHAOS
    XCHAOS --- ---
    REDGUY: ... toto je ovšem už neřešitelné, pochopitelně... pokud použiješ flow control makra, musíš počítat s tím, že na ně působí break a continue.

    podívej, tobě se prostě od začátku myšlenka flow control maker nelíbí. já sám jsem si díky těm polemikám uvědomil, že jsou tady určité rezervy v té srouzmitelnosti - stejně jako u spousty jiných věcí - ale prostě někomu v C přijdou nesrozumitelné aritmetické operace s pointery na vícerozměrná pole, někomu zase flow control makra a jejich nástroji: nemůžeš jednoznačně říct, že konstrukce zmiňované v http://stevenkobes.com/ctest.html jsou zcela blbuvzdorné a bez rizika - ale zato, že moje flow control makra jsou od základu špatná, protože na ně má vliv break, continue, apod.: blbost.

    nechápu, jak v jazyce, který je v podstatě postaven na různých praseckých konstukcích a zkratkách, najednou může přijít s tím, že moje prasení je nějak zásadně horší, než prasení kohokoliv jiného: pokud se ti to nelíbí, nepoužívej to. ale nechápu, jak se to můžeš klasifikovat jako prasečtější, než jiné prasecké konstrukce...
    XCHAOS
    XCHAOS --- ---
    REDGUY: mě ale baví řešit low-level pitomosti. nebaví mi flamewar s trolly, kteří ve chvíli, kdy by normální diskutér po rozumným argumentu aspoň trochu ustoupil a řekl "no ok, tak je to tak nějak napůl, asi", tak prostě úplně obrátí list, a začnou flejmovat o něčem úplně jiném.

    to je fakt především úplně chorý přístup k té debatě: občas se trefí jeden, občas druhý, nikdo se nemůže úplně trvale mýlit. a věnovat takové množství času, jako věnuješ ty, abys všechny kolem přesvědčil, že někdo jiný v debatě se ZÁSADNĚ a VE VŠEM mýlí - to je postě fakt trochu psychopatické...
    XCHAOS
    XCHAOS --- ---
    ISTEVE: ... no, a když vyskočíš z funkce a zapomeneš uvolnit paměť, tak je ovšem po determinismu :-)
    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 ...
    ISTEVE
    ISTEVE --- ---
    Pro mne je v programovani podstatny to, aby dana featura byla jednoznacna. Pokud dana featura "je skvela, ale s podminkama X, Y, Z", pak tu featuru nebudu pouzivat, pac je volaka cudna. Ostatne, to je duvod proc se goto a setjmp() nepouzivaj on daily basis -- jsou to silny nastroje, ktery ovsem maj spoustu bocnich veci ktery si je treba pamatovat.

    Jinak receno, ja jsem old-fashioned, ja mam ten determinismus docela rad :)
    REDGUY
    REDGUY --- ---
    XCHAOS: id REDGUY má úplně pravdu - až na to, že nenavrhuje žádné alternativní řešen prvni pulku si prosim vytiskni velkym fontem na A3 a poves nad stul, usetri nam to spoustu casu. A co se druhe pulky tyce - chces reseni? Tady je:

    UZ ZE SAKRA NAUC NEJAKEJ MODERNI PROGRAMOVACI JAZYK, VE KTERYM NEMUSIS RESIT LOW-LEVEL PITOMOSTI JAKO V C.


    můj nápad s polo-automatickou správou paměti není geniální, je jenom "hezký" - má spíše estetickou hodnotu, - ne, neni hezky, nema estetickou hodnotu. YMMV, samozrejme, ale pro me v programovani je jedna zasadni podminka aby neco mohlo byt hezke a esteticke: musi to fungovat.

    jenže ejhle, když máš v té funkci paměť alokovanou klasicky pomocí malloc(), tak jsi na tom úplně stejně - není správné utéct, dokud ji nevrátíš ! takže pointa je, že mnou navrhované řešení není v žádném ohledu horší, než to kanonické. - prdlajs. Tvoje reseni je _horsi_, protoze _musis_ dojit az na konec funkce. Pokud pouziju malloc, tak muzu tu pamet uvolnit uprostred funkce a udelat potom return _nebo_ se propracovat az na konec a uvolnovat to tam.
    _BENNY
    _BENNY --- ---
    XCHAOS: aby ta metafora byla fakt presna, znela by "vzdej to, k cemu bude ostatnim lidem pro ktere to pry delas v zahradni sekacce letecky motor?" ;)
    REDGUY
    REDGUY --- ---
    A dalsi bizarnost:
    for(int i = 0; i<10; i++) {
      forget {
        if (condition) {
          break;
        }
      }
    }
    
    Clovek je zvyklej ze break ukoncuje smycku, ze jo? Smula, v tomhle pripade vyskoci z forget, leakne pamet a pusti dalsi iteraci. continue se chova stejne idiotsky, u nej si ale XChaos muze namlouvat jakz-takz pricetne vysvetleni ze to je feature pro predcasny odchot z kontextu. Pro break to ale neplati, ten proste ten kontext rozbije a leakne.
    XCHAOS
    XCHAOS --- ---
    _BENNY: sorry, ale tahle metafora je prostě špatná. C je spíš letecký motor - je složitý na seřízení a opravení apod. - jenže všichni kolem říkají "vzdej to, na co potřebuješ letecký motor - proč ti nestačí sekačka na trávu, jako všem okolo".
    XCHAOS
    XCHAOS --- ---
    ISTEVE: no pochopitelně, pokud před returnem není bambilon řádek nějakého "uklízecího kódu" (ruční dealokace paměti, např. ?), který by musel být před každým returnem, tak pochopitelně není důvod to takhle dělat.

    fakt je to tak těžké pochopit, jak to myslím ? id REDGUY má úplně pravdu - až na to, že nenavrhuje žádné alternativní řešení: můj nápad s polo-automatickou správou paměti není geniální, je jenom "hezký" - má spíše estetickou hodnotu, než že by byl nějak objektivně "správný" či "výkonný" nebo tak něco. má samozřejmě svoje vady, ano - jenže se tu zamlčuje ta podstatná část problému: a sice, že alternativní postupy jsou na tom úplně stejně !

    je jistě nehezké když nemůžeš kdykoliv "čistě" vyskočit z funkce - jenže ejhle, když máš v té funkci paměť alokovanou klasicky pomocí malloc(), tak jsi na tom úplně stejně - není správné utéct, dokud ji nevrátíš ! takže pointa je, že mnou navrhované řešení není v žádném ohledu horší, než to kanonické. jediná výhoda je prostě ta, že pokud máš 2 a více pointerů, tak je to v mé verzi méně řádek kódu.
    ISTEVE
    ISTEVE --- ---
    (err, ze vracim bool a definuju to jako void preskocme, je vecer :])
    ISTEVE
    ISTEVE --- ---
    Komparativni analyza:

    Kod #1:
    void foo() {
      if (failing condition #1) {
        return false;
      }
    
      if (failing condition #2) {
        return false;
      }
    
      if (failing condition #3) {
        return false;
      }
    
      do_magic();
    
      return true;
    }
    ...
    Kod #2:
    void foo() {
      bool failed_yet = false;
    
      if (failing condition #1) {
        failed_yet = true;
      }
    
      // podminka na failed_yet != true je pro preskoceni zbytecny evaluace
      // failing condition, ktera muze bejt pripadne draha
      if (!failed_yet && failing condition #2) {
        failed_yet = true;
      }
    
      if (!failed_yet && failing condition #3) {
        failed_yet = true;
      }
    
      do_magic();
      return failed_yet;
    }


    srsly?
    _BENNY
    _BENNY --- ---
    a to cele jen kvuli tomu, ze nekoho napadlo udelat ze zahradni sekacky formuli 1.

    XCHAOS, proc se proste nesmiris s tim, ze na tyhle blbiny tu jsou jazyky, ktere to maji cele poresene uz uvnitr, a to efektivne a elegantne? pokud ti vadi pomale servery, optimalizuj tam kde to skutecne brzdi, ne tam kde si myslis ze to brzdi.
    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.
    Kliknutím sem můžete změnit nastavení reklam