• ú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 --- ---
    DAVIDOWITCH: kontexty BTW uměj zrušit spoják, na který zahodíš pointer. od toho jsem je dělal.

    jinak to co si posílal, byla implementace konzervativní garbage collection http://en.wikipedia.org/wiki/Garbage_collection_%28computer_science%29#Precise_vs._conservative_and_internal_pointers

    uvedu jako protipříklad zrovna "moje" pole, o kterých uvažuju, že by get(array,typ,počet) vrátil pointer až o kus dál, než je začátek alokované paměti - a na té počáteční pozici by byly servisní údaje (např. max. alokovaná délka, aktuální délka, apod.)
    DAVIDOWITCH
    DAVIDOWITCH --- ---
    XCHAOS: Pockej, co ti prijde na Cckovym GC krajne neprakticke? Mark-sweep neni spatnej algoritmus. Neni to tak chytry jako java (kde ti to treba new ve smycce "vyhodi" pred smycku), ale narozdil od tvejch kontextu to umi treba zabit spojak na kterej ztratis pointer.
    ISTEVE
    ISTEVE --- ---
    ANT_39: Presne tak. Ten samej kus kodu, co bude volat ukladani jump bufferu, bude taky volat odblokovani signalu, s tim ze se do nejaky globalni nebo thread-local promenny ulozi oldset (viz man sigprocmask).

    XCHAOS: Je, samozrejme, ostatne stary linuxovy thready se implementovaly pres signaly -- tusim ze to bylo neco jako ze signal handler byl vicemene scheduler yield + context switch.
    REDGUY
    REDGUY --- ---
    XCHAOS: Az na to, ze "jednodussi" samozrejme take neni - uz proto, ze porad musis v urcitych situacich pouzivat malloc/free. Cili i kdyby kontexty byly super jednoduche (coz nejsou), porad znamenaji pridanou slozitost nad free/malloc. Docela bizarni, v jazyce urcenem pro zacatecniky.

    Btw, kdyz napisu tohle:
    while (foo()) {
        blabla();
        if (bar()) {
            remember {
                allocate_memory_and_do_stuff()       
                if (baz1()) {
                    break;  // chci ukoncit cyklus while
                }
                if (baz2()) {
                    continue; // chci spusti dalsi iteraci while
                }
            }
        }
    }
    


    Bude to fungovat? Nebude? Co budu muset napsat aby to fungovalo? Vzhledem k tomu jaky bastl predpokladam ze ke remember mam urcitou teorii, ale rad si to poslechnu od tebe 8)
    ALMAD
    ALMAD --- ---
    XCHAOS: Jestli se ti nezda nespecificky except kvůli Ctrl+C, tak doporučuju vyrazit směrem SyntaxError ;-)
    XCHAOS
    XCHAOS --- ---
    DAVIDOWITCH: tohle už tu probehlo aspoň 2x .. princip chápu, ale pro množství paměti, které dnes může být alokováno, mi to přijde už krajně nepraktické.. nemluvě o vyswapovaných programech, apod.
    XCHAOS
    XCHAOS --- ---
    REDGUY: já bych zůstal u toho "jednodušší" , do bezpečnostních debat bych se nerad pouštěl (zvlášť ne v tomhle klubu / při použití C)

    víceméně, pokud runtime aspoň občas něco dealokuje, aniž by ses o to musel sám zasloužit - tak to podle mě jednodušší je.
    REDGUY
    REDGUY --- ---
    ANT_39: Pocinaje tusim 10.5 je v OSX Objective-C s garbage collectorem, ale vzdycky jsem myslel ze GC se tyka jen Objective-C objektu. Ale na druhou stranu tomu houby rozumim protoze ObjCuju jen na iPhone a tam GC jeste neni.
    ANT_39
    ANT_39 --- ---
    DAVIDOWITCH: Ja si vlastne vybavuju ze ObjC jde kompilovat s garbage collectorem (misto toho retain/release a releasepoolu z GNUStep). Tak mozna to jde zapojit i do normanich appek...
    DAVIDOWITCH
    DAVIDOWITCH --- ---
    ANT_39: No ja mam prave dojem, ze nabizi nejakou GC podporu i kompilovany aplikaci (pamatuju si to z nejakejch zprav ze tim resej firefoxi memory leaky na linuxu). Ale jistej si tim nejsem, not that kind of engineer :-)
    REDGUY
    REDGUY --- ---
    XCHAOS: protože prostě nedokážeš vyvrátit výrok, že "v C lze snadno napsat potenciálně nebezpečný či chybný kód, který se bez varování přeloží" - ano, to nedokazu, proto se o to ani nesnazim. Na druhe strane, vyrok "XChoas se uspesne snazi navrhnout system, ktery alokaci pameti v C zjednodussi a ucini ji bezpecnejsi" lze vyvratit zcela trivialne, poukazem na jednu z mnoha chyb v designu jeho systemu.
    ANT_39
    ANT_39 --- ---
    ISTEVE: Otazka zni, jak ty signaly po longjmpu odblokujes? V tu dobu uz jsi jinde... Hmm, hadam, ze kdyz to bude maskovany v tech makrech, tak by to za tebe mohlo expandovat makro za kazdym try { a catch {.

    DAVIDOWITCH: Tak tomuhle nejak nerozumim. GCC ma preci GC pri kompilaci, jak to pomuze?
    DAVIDOWITCH
    DAVIDOWITCH --- ---
    http://www.hpl.hp.com/personal/Hans_Boehm/gc/
    (asi najdes lepsi zdroje, ale tohle vypada jako slusnej zacatek)
    XCHAOS
    XCHAOS --- ---
    DAVIDOWITCH: no tak o tomhle toho moc nevím, nahoď odkaz
    DAVIDOWITCH
    DAVIDOWITCH --- ---
    Tak muzes do gcc pridat nejaky hooky, ted uz to zvlada jakous takous garbage collection, tak treba se prilipnout k tomu...
    XCHAOS
    XCHAOS --- ---
    ISTEVE: no, já bych skoro řekl, že signal-safety je dost podobné téma, jako thread safety... dost problémy stejného druhu, hlavně s globálními proměnnými.

    (kdysi jsem krátce spolupracoval s jednou firmou, jejíž hlavní starost byla, abych ze svého zdrojáku vyházel všechny globální proměnné ... víceméně, bylo to dost poučné, no...)
    XCHAOS
    XCHAOS --- ---
    ISTEVE: tak já se především o odchytávání signálů zatím nikdy nepokusil... zatím jsem nepsal nic takového, co by to potřebovalo. (nejčastější mi přijde znovunačtení konfigurace po odchycení HUP - hangup ... a možná nějaké korektní ukončení při odchycení TERM ... ale já to zatím nikdy nedělal)
    XCHAOS
    XCHAOS --- ---
    nebo ještě jinak - z předchozího příkladu v Pythonu nevyplývalo jasně tohle:
    >>> a=[1,2]
    >>> b=a
    >>> b[1]=3
    >>> a
    [1, 3]

    víceméně - podle mě každý začátečník, který se dostane v Pythonu takhle daleko, je velmi zhruba zralý přejít na můj dialekt C<<1. zatímco aby přešel na tradiční "liturgické C", které obajuje id REDGUY, tak by toho musel chápat výrazně víc.
    XCHAOS
    XCHAOS --- ---
    DAVIDOWITCH: mno, víceméně... jak říkám, Python dělá něco podobného: rovnítko vytváří referenci na objekt, zatímco + alokuje nový objekt pro kopii toho původního:

    Python 2.7.1+ (r271:86832, Apr 11 2011, 18:05:24)
    [GCC 4.5.2] on linux2
    Type "help", "copyright", "credits" or "license" for more information.
    >>> a=(1,2)
    >>> b=a
    >>> b
    (1, 2)
    >>> a=a+b
    >>> a
    (1, 2, 1, 2)
    >>> b
    (1, 2)
    >>> b
    (1, 2)

    tedy... víceméně, mě se + jako operátor konkatenace moc nelíbí, protože
    mojí základní myšlenkou pro C<<1 je jednotný alokátor, který by ideálně měl stejnou syntaxi pro alokaci jednoho objektu i pro concatenaci.

    např. str s=get(str,"text") je téměř identické s str s="text" - takový zápis je nesmysl. ale pro zřetězení, např. tr s=get(str, a," ", b) už to smysl dává.

    víceméně, kde jsem se zasekl je, že dnes jsou v módě nejen iterátory přes kontejnery, ale i generátory - např. v pythonu takové to pole=[prvek for prvek in ...] ... a udělat nejen univerzální iterační, ale i univerzální generační makro - tzn. takové, které by výsledek operace ve scope na konci PŘIDALO do kontejneru - na tom jsem se zasekl, to už v C vymyslet nedovedu :-)
    ISTEVE
    ISTEVE --- ---
    XCHAOS: Samozrejme, ze muze prijit v prubehu volani. Z toho jsou hilarious chyby.

    A pokud jsi nevedel tohle, pak dalsi interesting fact: Spousta funkci standardni knihovny je implementovana tak, ze pouziva nejakej buffer jako globalni promennou. Takze, kdyz udelam trivialni priklad:

    void le_sighandler(int signum) {
      printf("Yo dawg, I herd you like printf, so I put some printf in your printf."); // printf_sighandler
    }
    
    foo() {
      signal(SIGWHATEVER, &le_sighandler);
    
      printf("printfing %s", "like a boss"); // printf_foo
    }


    ...
    pak muze probihat exekuce tak, ze:
    1) vleze se do printf_foo
    2) printf_foo neco malo dela, a uklada si to do onoho globalniho bufferu -- jeste ale neskoncil
    3) prijde signal SIGWHATEVER, a spusti se le_sighandler
    4) printf_sighandler vyhodi do bufferu to co ma, flushne ho na stdout, a sighandler skonci
    5) onen globalni buffer nyni neobsahuje to co obsahoval v bode 2, ale nejakej podezrelej bordel (jako treba prazdnej string)
    6) printf_foo vesele pokracuje
    7) ???
    8) PROFIT

    ...tohle je samozrejme vseobecne platnej princip, ale printf priklad je takovej hezkej
    XCHAOS
    XCHAOS --- ---
    ISTEVE: no jo no... Pascal :-) jako v Pascalu to bylo tak nějak mlhavé ... a používalo se to hlavně na spojové seznamy... třeba místo předávání odkazů na hodnoty funkci tam byly řešené jakési "vstupní a výstupní" parametry funkce (o kolik elegantnější je v Pythonu jednoduše možnost aby funkce vrátila více hodnot (stub) - a aby nalevo od příkazu přiřazení byl prostě stub s názvy referencí ! popravdě - je to právě elegance Pythonu, kvůli které se jakéhokoliv zabředání do C++ dost štítím...)

    víceméně - já se snažím obejít celou záležitost se spojovými seznamy tím, že na ně bude poskytnutý nějaký framework. dnešní vyšší jazyky toto obvykle obchází, a tváří se, že si kontejnerové typy pořeší samy: Python i PHP přichází s dynamicky nafukovacími klasickými i asociativními polemi, a tváří se, že je implementují dostatečně dobře. Tedy: od žádného Python/PHP codera se v podstatě nečeká, že bude sám řešit nějaké dynamické spojové seznamy, jako se to očekávalo od programátorů v Pascalu.

    můj přístup je kompromisní: chci lidem dodat hotová makra pro manipulaci s několika různými základními kontejnery, včetně spojového seznamu. v kombinaci s immutable stringy po vzoru Pythonu.

    Python nemodifikovatelností stringu před "prostým uživatelem" tak trochu maskuje, že "všechno je je jen reference" - prostý uživatel na to překvapeně narazí až ve chvíli, kdy udělá referenci na kontejnerový typ, a zjistí, že se odkazuje pořád na tu stejnou kopii v paměti - ale po zralé úvaze, kdy mi to nejdřív dost zvedlo ze židle, se nyní domnívám, že právě toto je ten správný "lék", který by mohl učinit C přístupnější "masám" - víceméně: C s immutable stringy a s několika rozumnými makry na manageování předdefinovaných kontejnerových typů zabíjí více much několika ranami: jednou takovou mouchou je práce s utf-8 stringy (v takovém případě zapomeňte na indexování stringu integerem!), jinou mouchou je právě pointerová gymnastika, kterou je možné "decentně zakrýt".

    víceméně - můj dialekt by mohl lidi dovést k tomu, aby používali C, aniž by mu rozumněli, což z něj právě dělá "kreolštinu" mezi programovacími jazyky. je to taková "turistická verze" Céčka :-) bude dobrá k tomu, abyste si na baru mohli objednat panáka a tak :-)
    Kliknutím sem můžete změnit nastavení reklam