• ú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í
    JANFROG
    JANFROG --- ---
    DAVIDOWITCH: Ja vim ze to vis. Jen jsem chtel poukazat na to, ze v instrukcich je trosku nesmysl dneska pocitat.

    I kdyz, musim se priznat, ja to sam delam :-) Kdyz generuji / pisu kod, obvykle jen pocitam pocet taken-jumpu ve fast path + kouknu na efektivitu vyuziti cache. V mem konkretnim pripade je to docela dobra aproximace...
    DAVIDOWITCH
    DAVIDOWITCH --- ---
    JANFROG: Vim. Jen sem rozvadel napad ze [] v C je lepsi protoze trva jen instrukci. To ze mnohem vic zalezi na tom jestli mas to kam tim [] pristupujes v cache nebo ne nez na tom pres kolik instrukci spocitas presnou adresu je trochu soucasti pointy. (A ja bych asi vytahl ze spojaky jsou na ten pristup kor blby, protoze nepouzivaj datovou lokalitu.. ale to uz tu nekolikrat bylo)
    ANT_39
    ANT_39 --- ---
    WILD_A: Tak jestli se ten celek tvaril jako kontejner... IMHO je fakt jedno, jestli je to get, at, operator[] nebo co, stejne z nazvu tu cenu toho volani presne nepoznas, a profiler se zmast nenecha. Konzistence ma IMHO vetsi vahu, nez anotovat jmeno funkce podle toho, jak je implementovana.

    Jestli ten double lookup o kterym mluvis byl opravnenej je samozrejme uplne jina otazka. Mohl, nemusel.
    JANFROG
    JANFROG --- ---
    DAVIDOWITCH: Ono ani tak nejde o to kolik instrukci to ci ono trva, spis jde o to, kolik taktu to trva :-) Neni instrukce jako instrukce, ani na RISC :-)
    A nakonec ani nejde ani tak o to kolik taktu trva to ci ono, jako spis jak dlouho se bude cekat na pamet :-)
    DAVIDOWITCH
    DAVIDOWITCH --- ---
    WILD_A: Potrebujes par instrukci abys spocital adresu a pak udelal ten load. (A jo, myslim tim RISC instrukce, ze ma x86 zbesily instrukce co nejenze natahnout z pameti dany bazi a offsetem do registru, ale jeste ti vycistej boty.. to vim a neprijde mi to az tak zajimavy)
    WILD_A
    WILD_A --- ---
    DAVIDOWITCH: Nedokaze nacist data z pole do registru? nebo jsem te spatbne pochopil?
    WILD_A
    WILD_A --- ---
    ANT_39: No ono to brikule jsou, to mas pravdu, ale v dnesni dobe mne to neprekvapi, viz STL kontejnery, ja se tomu osobne vyhybam to delat takhle, ale realita kolem mne je jaka je. Nicmene konkretni brikule co jsem videl a resil bylo nejdrive vyhledani daneho prvku v jinem STL kontejneru, nacteni dalsiho indexu do jineho kontejneru a z nej vytazeni finalniho udaje ... jako bylo to cely spatne, to nerozporuju, ale vypadalo to na prvni pohled naprosto elegantni a optimalni kod :)
    ANT_39
    ANT_39 --- ---
    WILD_A: Prekvapuje me, ze pristup do hashe a do mapy nepovazujes za brikule. To je o rad horsi, z hlediska slozitosti kodu, nez prostej pristup do pole. Co se v tom pripade jako brikule kvalifikuje?
    DAVIDOWITCH
    DAVIDOWITCH --- ---
    XCHAOS: Jo, dela, precti si neco o SSA.

    Ale pokud mas vlevo treba prave tu indexaci, a prirazujes do toho z pameti a ne z aritmeticky jednotky, tak uz to nedas. Pokud jen mas nejakou matiku a do promennych ukladas mezivysledky, tak to je vesmes cely jen asignovani registru (ala to co dela procesor kvuli out-of-order exekuci, kde ma vyrazne vic fyzickejch nez logickejch registru a prejmenovava si je jak zrovna potrebuje)
    XCHAOS
    XCHAOS --- ---
    DAVIDOWITCH: no, pokud mu přiřazovaná hodnota zbyde v registru, tak podle mě dokáže. dokonce, pokud v rámci optimalizace je přiřazováno do proměnné uložené v registru (buď explicitně vyžádáno klíčovým slovem "register" nebo nějak zoptimalizováno) , tak výraz vpravo od rovnítka mohl compiler zpracovat tak, že následná operace přiřazení spotřebuje 0 instrukcí :-) (ale toto tvrdím bez jakékoliv záruky, že nějaký compiler skutečně takovou optimalizaci dělá, teda...)
    DAVIDOWITCH
    DAVIDOWITCH --- ---
    XCHAOS: Procesor vetsinou nedokaze prirazeni/indexovani jednou operaci na registrech ani v cistem C.

    XCHAOS: Na pole fixni velikosti zapomen :-D
    Jenak je to uplne burta, kdyz uz to mas na heapu (a na stack se to nevejde ani omylem), a druhak by to predpokladalo ze aplikace bezi v prave jednom rozliseni, coz nebezi.
    XCHAOS
    XCHAOS --- ---
    WILD_A: no, obávám se, že v éře, kdy myší už ani nemusíš klikat, aby nastal nějaký ten onMouseOver() event, budeme mít problém vysvětlil většině, proč se nám nelíbí, že věci jako přiřazení nebo indexování pole neměly dělat nic, co by procesor nedokázal provést jedinou instrukcí zpracovávající hodnoty v registrech...
    WILD_A
    WILD_A --- ---
    ANT_39: No pokud se tam dejou brikule, tak mi to na miste neprijde, jelikoz to budi dojem, ze to je jen index a ocekavam tam maximalne nejakej strom nebo hash a ono je to pak cely slozitejsi. Ja mam rad kdyz kod ukazuje co dela, takze pokud delam brikule tak dam kontejner.brikule(x) at je to videt.

    Ale je to jen muj postoj vzhledem ke zkusenostem, ktery jsem udelal, mluvim teda ted konkretne o C++.
    REDGUY
    REDGUY --- ---
    XCHAOS: Ne pro uspech, pro nesmysl, stejne jako minus na zprave na kterou ted odpovidam. To jsi moc nepochopil smysl minusu 8)
    XCHAOS
    XCHAOS --- ---
    (-1 od id REDGUY, pro velký úspěch...)

    ANT_39: ... to znamená, že má pocit, že se to děje magicky samo a nic to nestojí :-)
    ANT_39
    ANT_39 --- ---
    WILD_A: Zrovna pretezovani [] u kontejneru, * a -> u chytrejch ukazatelu, atp. dava taky dobrej smysl. Jestli se kvuli tomu musi delat brikule, tak holt musi. Stejne by se delaly, at to nazves at nebo operator[], akorat ted ma klient pristup do toho kontejneru pomoci intuitivni syntaxe.
    XCHAOS
    XCHAOS --- ---
    WILD_A: jenže ono nejde dát do jazyka nějakou feature jen k tomu, aby si matematici mohli definovat vektory a matice a doufat, že jí někdo nezneužije jinak...

    takže purismus a minimalismus C je svazující a omezující (pro mě je C ideální jazyk, kdybych zase někdy programoval panáčka, co běhá po místnostech se souřadnicemi x a y a sbírá konečný předem známý počet předmětů, apod. :-), jenže jakýkoliv jiný vyšší jazyk umožní, aby "cokoliv znamenalo cokoliv"

    + a += v Pythonu je lepší než drátem do oka. Sjednocení (řetězení) a aritmetické sčítání ale není to samé. stejně tak ale PHP/Perl tečka koliduje min. s desetinou tečkou a voláním metody objektu. konkatenace si zaslouží vlastní operátor, který matematici nemají

    (a jestli nebudu líný, tak vám předvedu brzo svoje řešení :-) sice trochu gcc only, ale elegantní :-)
    WILD_A
    WILD_A --- ---
    DAVIDOWITCH: No nekde mozna pretezovani dava smysl a je to peknej syntaktickej cukr, ale obecne je to spis k zlosti, sam uvadis priklad. Ja mam zase zkusenost s tim, ze kod co vypada super jednoduse a optimalne v realu dela za operatorem '=' a '[]' takovy brikule, ze jeden neveri ... takze mozna bych to za sebe shrnul, pretezovani u jednoznacnych matematickych operaci je ok, ale jinde bych se tomu vyhnul.
    XCHAOS
    XCHAOS --- ---
    DAVIDOWITCH: a tady jsme u otázky, jaká část programování dnes vlastně zahrnuje vyšší matematiku.

    spousta jsou jen "kupecké počty", nemluvě o rostoucím významu práce s textem (už SQL je plné textových operátorů, nejen LIKE, ale i MATCH AGAINST... a to pořád ještě nestačí pro specifika jazyků, které mísí diakritiku se zápisem bez diakritiky, apod.)

    programování 2D či 3D grafiky v nějakém konečném prostoru či rozlišení viewportu je přesně to, na co se hodí i pole fixní velikosti, apod... jenže tohle dneska není nejčastější abstrace, když člověk neprogramuje počítačové hry. dovedu si ale představit, že přetěžování je dobré pro tu matiku, problém je, že ne všichni programují jen matiku.

    při zpracování nějakých datových souborů je nejčastější operací iterování buď přes všechny prvky seznamu, nebo přes nějakou podmnožinu seznamu.

    pokud se +, += přetíží pro nějaké řetězení seznamů či přidávání prvků, tak mi prostě intuitivní nepřijde (i když je to elegantní C záznam)... (a podle mě to není intuitivní ani pro někoho, kdo tím chce sčítat ty vektory či matice)
    a=(1,)
    b=(2,)
    a+=b
    a
    (1, 2)
    DAVIDOWITCH
    DAVIDOWITCH --- ---
    Ja mam pretezovani operatoru rad, ted sem videl neco grafickyho psanyho v Jave, a to ze vektorovy operace (tj. secist bod a vektor) se musi delat po slozkach, nebo pres .Add() je hrozny.
    (Zato interne vedu mensi valku o tom ze pretezovat pro vektory 3 cisel < je spatnej napad, protoze neni jasny jestli to je "any lt" nebo "all lt" a melo by to bejt explicitne.. a clovek co zkusil udelat z ~ operator pro normalizaci vektoru to sel domu prepisovat)
    XCHAOS
    XCHAOS --- ---
    WILD_A: no hele, v tý debatě bylo, že C je vlastně subset asemblerů minipočítačů 60-tých let, na kterých pak vznikl Unix. většina původních C instrukcí se přepisovala přesně na jednu strojovou instrukci tehdejších procesorů (na pozdějším hardwaru se to taky implementovalo jednoduše, ale někdy už to vyšlo na víc strojových instrukcí)

    no a jde o to: nějaký subset základních abstrakcí, které jsou víc, než jen základní assembler, ale zase jsou k dispozici fakt všude a nevyžadují instalaci speciálních knihoven. a to je kámen úrazu: základní libc (téma tohohle klubu) v sobě neobsahuje nic zásadně použitelnýho. problém je, že základní kontejnerové typy jazyků jako javascript nebo python (nebo i to dementní PHP) se v C typicky rozepíší na 100 řádek kódu...
    Kliknutím sem můžete změnit nastavení reklam