• ú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: ... ale v tomto klubu je "vysoký obsah syntaktického cukru" zmíněný přímo v záhlaví :-)
    DAVIDOWITCH
    DAVIDOWITCH --- ---
    1 odpověď+1
    XCHAOS: Nevim, taky sem zagooglil:
    Hash Tables
    http://developer.gnome.org/glib/stable/glib-Hash-Tables.html
    Asociativni pole je uvnitr bud hashmap, nebo nejakej strom (STLkovej map je Red-Black tree), pristup pres ["key"] je jen syntactic sugar.
    (Co je asociativni pole v PHPku je black magic, a evidentne to ma vic reprezentaci mezi kterejma to vybira.. vcetne linearniho pole jako mas ty, ktery se pak vyznacuje zoufale pomalym pristupem)
    XCHAOS
    XCHAOS --- ---
    -1
    DAVIDOWITCH: ok, ale nemohli bychom zůstat u toho, že průměrný C programátor toto ví, a je s tím smířen - stejně jako s otázkami týkajícími se možnosti posmrtného života, praktičnosti pohřebu žehem, apod.?
    XCHAOS
    XCHAOS --- ---
    1 odpověď
    DAVIDOWITCH: "běžná céčková knihovna".. to je něco jako "běžný prací prášek"? nevím... zagooglím..
    bud šílenosti jako http://rosettacode.org/wiki/Associative_arrays/Creation/C
    nebo ještě spíš http://cboard.cprogramming.com/c-programming/72160-how-use-associative-arrays-c.html - No. There are no associative arrays in C. Your best bet is to simulate them using structures with whatever key or name you wish to associate with them.

    můj makro-toolkit (zcela nezávisle na tomhle a jiných tutorialech) směřuje k tomu poskytnout pokud možno intuitivní framework pro deklaraci a práci s jednoduchými strukturami, které mají klíč ... princip hashování znám, ale nějak mi neimponuje (Vernamovu šifru na všechny MD5 podepisovače :-)
    DAVIDOWITCH
    DAVIDOWITCH --- ---
    1 odpověď
    XCHAOS: Ono GCC taky meni generovanej kod s kazdou verzi (proto sem, mmj, chtel ten vypis ASM po tobe.. protoze ty verze se lisej obcas dost drasticky)
    DAVIDOWITCH
    DAVIDOWITCH --- ---
    1 odpověď
    XCHAOS: To nema zadna z beznejch Cckovejch knihoven hashmap?
    XCHAOS
    XCHAOS --- ---
    2 odpovědi-1
    JANFROG: jinak k tomu " kazdy C prekladac s kazdou verzi s kazdym jednotlivym prepinacem generuje jiny kod" .... no, tady bych argumentoval tím, že jsem se rozhodl, že mě bude zajímat prostě jen gcc (a holt pokud se časem gcc změní, budu možná muset změnit i moje optimalizace).

    chápu, že se vám moje cíle zdají nízké.. ale jde zhruba o to, že ve většině případů může můj precompiler dosáhnout třeba 5x větší rychlosti, než typické interpretery (Python, PHP) - a holt jsem takový máslo, že to nebude 10x větší rychlost (jak by mohla být, kdybych měl vychytaný všechny ty C optimalizace). (až na to, že já zatím precompiler vůbec nepíšu - píšu si jen normální toolkit, v podstatě pro zlepšení čitelnosti a inutitivnosti nativního C zdrojáku...tím výkon nezvyšuju už vůbec, je to spíš anti-optimalizace - zlepšení srozumitelnosti kodu na úkor efektivity)
    XCHAOS
    XCHAOS --- ---
    JANFROG: počkej... " vyssi programovaci jazyk preklada do C," ... tomu já říkám prekompilace :-)

    každopádně já Javu prostě nerad - co k tomu mám dodat? V tomto klubu to snad není offtopic říct :-)
    JANFROG
    JANFROG --- ---
    2 odpovědi
    XCHAOS: Prekompilace...slepa vetev. Nas system se bootstrapuje tim ze vyssi programovaci jazyk preklada do C, ktere se pozdeji prelozi pomoci GCC/BCC/MSVC. Super technologie pred 25 lety. Dnes uz bych do toho nesel a to i za cenu toho, ze jinak bych musel opustit jednu z mych oblibenych featur soucasneho systemu (inline-C). Dnes bych vse nechal na JITu a pro bootstrap minimalniho systemu bych pouzil interpret AST, jedno jak pomalej.

    Duvody jsou dva:
    (i) stejne musis mit JIT pro rozumny vykon a inkrementalni vyvoj (pro me co nedovoluje vyvijet inkrementalne je nepouzitelne, jsem narocny :-)
    (ii) pokud chces rychlost + GC + nejake pokrocile featurky jako reifikovatelny stack, kontinuace apod, tvrde narazis na to, ze kazdy C prekladac s kazdou verzi s kazdym jednotlivym prepinacem generuje jiny kod, nekdy invalidni, nekdy proste jen ignoruje/ruzne si vyklada volatile, inline apod. Nikdy nemas kontrolu nad tim, jak presne vypada frame na stacku, co v nem presne je, nikdy nevis co presne je v registrech a co v pameti. Tahle nejistota je zabijak...

    Takze pokud prekompilovat, tak jedine do ASM a vypnout vsechny jeho "optimalizace" jako automaticke plneni delayslotu podobne legracky. Kompilovat do C je o neco snadnejsi na zacatku a obrovsky problem na konci. Takze tudy ne, alespon ne pro HLL.


    DAVIDOWITCH: Tak u vsech modernich VM je se zasobnikovy bytekod pouziva spis proto, ze do nej pohodlne preklada a ze to je tradice. Stejne prvni co udelas je ze to dekompilujes zpet do AST a prelozis do strojaku...


    PIGSTER: My jsme tam doiterovali a delame si vsechno sami (VM, knihovny, GUI, IDE, krom operacniho systemu :-) a ma to sve vyhody...
    XCHAOS
    XCHAOS --- ---
    1 odpověď-1
    PIGSTER: no jo... v C určité úrovně abstrakce ale prostě chybí a to klade vyšší nároky na programátora (já zrovna patřím k těm lidem, co by tento problém rádi vyřešili použitím nějakého elegantního toolkitu).

    třeba asociativní pole jsou dost nezbytnost u programování čeho webového/databázového - protože vše, co nějak dostaneš od okolního světa, se nějak jmenuje. přesto třeba když na toto použiješ PHP, tak se můžeš připravit, že ta PHP aplikace sežere v rámci toho procesu nejvíc paměti i času CPU a bude úzkým hrdlem, co se týče počtu přístupů, apod. .. takže třeba toolkit, který by co nejelegantněji a nejjednodušeji suploval asociativní pole v C, mě docela zajímá (já pro svoje vlastní účely zatím používám spojové seznamy normální datových struktur, protože se mi s tím dobře dělá...)
    DAVIDOWITCH
    DAVIDOWITCH --- ---
    PIGSTER: asi preklad, "to delaji proto, ze neumeji"?
    PIGSTER
    PIGSTER --- ---
    3 odpovědi
    XCHAOS: hmm, rekl bych, ze lidi, co pouzivaji nejaky interpretovany jazyk (ruby treba) nebo nejaky GC VM jazyk (c# nebo java treba) to delaji pro to, ze neumeji programovat v C - dokonce bych si dovolil tvrdit, ze nekteri z nich jsou velmi dobre schopni vytvorit infrastrukturu, kterou pouzivaji, kdyby to bylo nutne - ale proc by to nekdo delal? Proc psat framework kdyz uz jich tu je cela rada velmi dobrych (zamerna paralela se soucasnou ceskou PHP komunitou)? Proc ztracet cas vymyslenim hranateho kola, kdyz ho je mozne vyuzit vyvojem automobilu (ktery pouziva jiz existujici kulata kola a evidentne je to plne vyhovujici reseni)?
    Mimochodem, kdyby se to iterovalo o kousek dal, skoncis u psani nastroju, ktere vyviji firmy jako Cadence nebo Synopsys - abys to mel echt sobestacne :)
    DAVIDOWITCH
    DAVIDOWITCH --- ---
    1 odpověď
    JANFROG: Mne se na cely tyhle veci stejne nejvic libi, ze VM jsou misto kde se fakt realne stale porad pouziva zasobnikovej (stack based) ASM. Protoze se to dekoduje rychlejc. (I kdyz, predpokladam ze v momente kdy nejak dopredu JITujes, tak to neni az tak podstatny jako kdyz se chroupaj instrukce po instrukci).
    XCHAOS
    XCHAOS --- ---
    1 odpověď
    JANFROG: no, podle mě má smysl to, co člověk vymyslí, prohnat různými benchmarky. s tím, že já si rád nechám poradit, jaké benchmarky smysl mají a jaké ne.

    ...ale třeba jen benchamrky na měření zdánlivých banalit jako rychlost řetězení stringů nebo výkon asociativních polí si lze vycucat z prstu snadno... a lze srovnat něco s něčím (tedy stejný kód v různých jazycích, navíc běžících pod různými interpretery...)

    Ruby je pěkná hračka :-) ale prakticky používat bych to nechtěl. Ale jeden z vedlejších myšlenkových proudů se u mě týká pre-compileru nějakého vyššího objektového jazyka do C (skrze polymorfní ANSI-C objekty). Kdybych do toho šel, tak se asi volně inspiruji u Pythonu i Ruby - hlavně se mi líbí myšlenka, že IF i OR jsou jen operátory, jejichž parametry z jedné i druhé strany jsou volitelné, a liší se jen směrem vyhodnocování svých argumentů :-)

    Interpretace mě tolik nebere - možná je to ambiciózní intelektuální výzva... zvlášť existující interpretery Ruby neoplývají rychlostí... ale prostě já osobně sázím na pre-kompilaci (nevím proč, prostě mi to nějak sedne). Spousta toho, co jsem v posledních letech napsal, jsou tak jako tak různé parsery a pre-compilery různých jiných formátů - ať už HTML nebo iptables nebo čehokoliv. V programu, který sám píše jiný program, je cosi kosmologicky mystického :-)
    JANFROG
    JANFROG --- ---
    2 odpovědi
    XCHAOS: No shodou okolnosti se vyvojem virtualnich stroju pro vyssi programovaci jazyky jiz nejakou dobu zabyvam (v zasade je to zdroj me obzivy)
    a muzu Ti rici, ze bez zakladnich znalosti procesoru a ASM to nejde. A to C ktere se pouziva je take o dost jine nez kdyz pises "normalni" programy (napriklad if je zabijak vykonu, pouzivat goto a podobne perly).

    Premyslet jak jsou napsane nema smysl, muzes se na to podivat. Pokud chces pochopit, jak to funguje, pak 1) nejakou VM si napis a __pouzivej__ a 2) podivaj se, jak to delaji jini. Pro zacatek doporucuji kurz a knihu "Structure and Interpretation of Computer Programs".
    Cokoliv jineho je ztrata casu/mentalni rozcvicka, nic vic. Ver mi, tohle uz mam za sebou :-)

    Opet ciste nahodou jsem delal/delam na prekladaci Ruby a ted delam na vlastni implementaci JVM a muzu Ti rici, ze ja osobne to povazuji za velmi, velmi ambiciozni
    (i kdyz...mozna si jen fandim, mozna je to trivka kdyz se to dari i diletantum jako jsem ja a mi kolegove :-) Udelat rychlou VM je celkem umeni...
    XCHAOS
    XCHAOS --- ---
    2 odpovědi-1
    JANFROG: no tak víceméně... zatímco všichni kolem mě používají interpretery vyšších programovacích jazyků (Bash, PHP, Python, Perl, Ruby a vlastně i ta Java), tak já se snažím být profesionál - a přemýšlet, jak jsou asi ty interpretery napsané (v C).

    souhlasím, že kdybych se hodně dlouho specializoval na C, tak bych se měl zajímat i o ASM. ale u mě je to spíš přístup "mezi slepými jednooký králem" - tedy umět napsat interpret něčeho takového, jako používají všichni kolem mě.

    (Nekladu si až tak vysoké cíle, jak mi tady někteří asi podsouvají...)
    XCHAOS
    XCHAOS --- ---
    -1
    REDGUY: tak je to vcelku konzistentní s tím, že moje největší hrůza při programování vždy spočívala v tom, že dojde RAM a program začne swapovat na HDD :-)
    JANFROG
    JANFROG --- ---
    DAVIDOWITCH: To me minulo. Ach jo, tak to pridam na seznam neprectenych veci, poradove cislo 332432 :-(
    REDGUY
    REDGUY --- ---
    1 odpověď+2
    DAVIDOWITCH: Obdobne https://gist.github.com/2841832
    Pripadne v obrazkove forme https://gist.github.com/2843375 :
    DAVIDOWITCH
    DAVIDOWITCH --- ---
    2 odpovědi
    JANFROG: Tohle uz tu prolitlo, ale kdyby te to nahodou minulo:
    www.akkadia.org/drepper/cpumemory.pdf
    JANFROG
    JANFROG --- ---
    2 odpovědi+6
    XCHAOS: No, ja razim myslenku (a nekteri mi studenti budou jiste tvrdit ze ne zrovna mirovou cestou :-), ze profesional by mel znat minimalne jednu uroven pod tim, co dela. Delas-li v C (coz se dela dnes jen proto, aby to bylo "rychle" + legacy, jiny duvod si neumim predstavit) mel bys znat ASM vcetne tech veci co se tu resi.
    Tim se lisi "pojidac kolacu" od "skutecneho programatora".
    Kliknutím sem můžete změnit nastavení reklam