• ú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 --- ---
    XCHAOS: Každý string tam určitá vzniká nejspíš jako další obecně rozšířitelný meta-objekt...což musí nutně mít nějakou reži
    To jiste ma rezii, jako vsechno. Ta rezie je ale dost presne stejna jako v pripade tridnich systemu. Typicky se jedna o pointer bump + vyplneni hlavicky (obvykle 1/2 slova). Dopocujuji precist klasicky paper

    Craig Chambers, David Ungar, and Elgin Lee: An Efficient Implementation of SELF, a Dynamically-Typed Object-Oriented Language Based on Prototypes.

    u které vím, co se uvnitř ní děje
    Domnivam se, ze C toto nesplnuje. Jednoduchy priklad. Mejme nasledujici kod:
    #include <stdio.h>
    #define BOOLVAL(x) ((x) ? "true" : "false")
    #define COMPARE(type1, value1, type2, value2)           \
        {                                                   \
            type1 a = value1;                               \
            type2 b = value2;                               \
            printf("===\n"                                  \
                   "%s a = %s;\n"                           \
                   "%s b = %s;\n",                          \
                   #type1, #value1, #type2, #value2);       \
    	printf("   a == b // -> %s\n"                   \
                   "   a < b  // -> %s\n"                   \
                   "   a > b  // -> %s\n",                  \
                   BOOLVAL(a == b),                         \
                   BOOLVAL(a < b),                          \
                   BOOLVAL(a > b));                         \
        }
    int main() {
        COMPARE(long, -1, unsigned int, 1);
        COMPARE(unsigned int, 1, long,  1);
    }
    


    Co vypise?
    REDGUY
    REDGUY --- ---
    XCHAOS: JavaScriipt, obávám se, je s tou efektivitou přesně na obráceném konci spektra, než Perl. - Jezis, XChaosi, _cetl_ jsi aspon ty vysledky? Vsiml sis, ze V8 tam ma vysledek _rychlejsi_ nez c++ a python, ostatne, ze je na _tretim_ miste? Proboha, "obracenej konec spektra"... tys to ani necet a proste jen tak volne placas nesmysly.

    byla napsat pre-compiler z javascriptu do C (nebo teda případně do bytekódu) - jo, uzasnej napad. Akorat ze treba prave ta V8 uz davno funguje jako JIT a dela pri tom optimalizace, o kterej se tobe ani nezda. Ale jdi do toho, jsem zvedavej na vysledek 8))

    tedy mít nějakou platformu, která se chová předvídatelně a u které vím, co se uvnitř ní děje - wut? Jak tohle proboha souvisi s blbe napsanym a zbytecnym syntetickym nanobenchmarkem?
    XCHAOS
    XCHAOS --- ---
    REDGUY: JavaScriipt, obávám se, je s tou efektivitou přesně na obráceném konci spektra, než Perl. Každý string tam určitá vzniká nejspíš jako další obecně rozšířitelný meta-objekt (javascript stojí na prototypingu - vznik nových objektů kopírováním z nějaké šablony), což musí nutně mít nějakou reži a ten test to ukazuje.

    debata pod benchmarkem rozebírá, kde udělal autor chybu v Javové a C++ verzi (to nepřekvapí, že zrovna tohle si příslušné komunity hlídají, protože Java i C++ jsou velké trhy s dobře placenou programátorskou silou... a náznaky, že ty platformy jsou snad v něčem čemkoliv měřitelném nevhodné, jsou přímé ohrožení pro těžce pracující lid, co musí splácet svoje hypotéky a tak...). zajímavé je, že jsem tam asi nějak přehlídl zuřivou polemiku, že by snad ta javascriptová implementace byla špatně :-)

    jedna z věcí, nad kterými jsem ohledně svého dalšího směřování v programování fakt přemýšlel, byla napsat pre-compiler z javascriptu do C (nebo teda případně do bytekódu). javascript totiž má masivní uživatelskou základnu bastlířů... a i když se mi třeba nelíbí, tak vyjít z něj je lepší, než se snažit nějak bastardizovat syntaxi jazyků jako Python či Ruby... (tzn. nebýt vůbec přesně stejný ale tvářit se, že jsem hrozně podobný.. to je nakonec u programovacích jazyků nejhorší zlo...)

    (samozřejmě, ty nechápeš můj hlavní úmysl - tedy mít nějakou platformu, která se chová předvídatelně a u které vím, co se uvnitř ní děje, takže tobě se obecně spousta věcí špatně vysvětluje.... což sahá už k tomu, proč jsou "transparentní" Eiffelovka a příhradové železniční mosty celé té éry krásnější, než žižkovská věž či železobeton, ale ty prostě tyhle debaty a to co z nich filosoficky vyplývá nemáš rád a budeš je vždycky rozbíjet...)
    XCHAOS
    XCHAOS --- ---
    "edited 2012-03-22" ... tzn. rozhodně by to celé stálo za přeměření v dnešní době, s dnešními verzemi těch interpreterů, apod. ..

    na druhou stranu nesouhlasím s představou, že by na to mohly mít nějaký zásadně větší vliv optimalizace kompileru (no možná na efektivitu toho "realloc", ale stěží na efectivitu std string...). tohle je benchmark srovnávající efektivitu různých implementací stringových operací a jako takový smysl má (i kdyby ten konkrétní byl udělaný špatně).

    jinak dal jsem si práci přečíst ty komentáře, a nejvíc nasraný jsou Javisti, pochopitelně :-) problém je, že u nich je k dispozici výběr různých abstrakcí a člověk si musí vybrat tu správnou. na druhou stranu - člověk, který prošel fází programování v C, asi bude jediný pořádně chápat, jaký je mezi těmi různými abstrakcemi rozdíl (pro nově příchozí to bude prostě "zjevený magický trik" - HAHAHA String je pomalý, použijte StringBuilder.... akorát že mezi tím _naučit se_, okoukat od někoho, jak se to dělá, a _chápat_ proč něco nějak je a přijít na to sám je prostě diametrální rozdíl... je fakt, že lidi co některé věci chápou, bývají obtížně zaměstnatelní a říditelní, proto produkční prostředí zřejmě vítá využití mírně cvičených opic, hrajících si s prefabrikovanými vyššími levely abstrakce bez hlubšího pochopení...)

    jako vidět výkon interpretovaných jazyků srovnatelný s C++ je celkově pozoruhodné... a hlavně výkon toho Perlu. že má ta interpretace kódu tak malý overhead... C++ by teoreticky mělo mít obrovskou výhodu a dávat výsledek ekvivalentní C (pokud se použije správný nástroj... BTC z C i C++ jde samozřejmě regexpy volat taky, protože jsou POSIX a tedy standardní součást GNU libc... jak jinak by asi ty interpretery, napsané v C, ty regexpy volaly?).

    že Perl předhoní C++ kód je protě úlet: vypadá to, že interpreter si může vygenerovat bytekód, který bude jen zanedbatelně pomalejší, než nativní kód (bytekód, tvořený přímo pointery na volané rutiny, tzn. něco jako Just-in-time kompilace?) - a že v tomhle bodě není výhoda nativního binární kódu tak velká. C vede díky tomu, že nutí programátora zcela přesně popsat svůj záměr s jen minimem abstrakce. Ostatní jazyky nabízí superpohodlí, které může a nemusí být implementované úměrně řešemému problému ("dělo na vrabce", aneb když si na krátkou vyjížďku vyjedete s tankem místo na kole... což byl právě příklad té chybné implementace v Javě)

    v té debatě pod benchmarkem se ale nejvíc rozčilovali Javisti a strašně jim záleželo na tom ukázat, že nezaostávají za třídou Python/Perl/PHP (přitom ale v Pythonu jsou stringy immutable automaticky, takže stojí za zmínku, že test přesto ustojí). ale mě fakt daleko zajímavější přijde srovnávání C a C++ ...
    XCHAOS
    XCHAOS --- ---
    REDGUY: no to je skutečně blbost, kopírovat do 8 znakového bufferu 8 znaků + ukončující nulu, to sis všiml dobře.

    s tou Javou je možné, že to testovali někdy historicky.
    REDGUY
    REDGUY --- ---
    HAHAHAHAHAHAHAHAHA.

    A je to cim dal tim lepsi.

    Jsem si rekl, ze si pro srovnani pustim tu Ceckovou verzi. A dobre jsem udelal, protoze, jak se rika, hilarity ensued 8))

    V prvni rade, kod toho cloveka je plnej bugu. Zvlastni zes to nezminil, XChaosi, kdyz jsi psal jak se ti ten test libi, jak pouziva low-level funkce... cim to, zes nezminil pitomosti jako je tahle:
    char *str=malloc(8);
    strcpy(str,"abcdefgh");
    


    A to je jen jedna z nekolika. Pokud to nekde fungovalo, tak jen nahodou.

    Tak jsem to ofixoval, pustil... no, a bezi to DVAKRAT POMALEJC nez ta moje java.

    HAHAHAHAHAHAHAHAHA.

    Jak jsi to rikal, XChaosi? " zatímco Java a JavaScript jsou v tomhle směru totálně LOL. "? 8))))) No... "LOL" 8)
    REDGUY
    REDGUY --- ---
    REDGUY: LOL, jsem idiot, mel jsem tam bugu. Po jejim opraveni je javova verze JEDENACTKRAT rychlejsi nez verze toho trumbery co psal ten clanek.
    REDGUY
    REDGUY --- ---
    XCHAOS: samozřejmě obecné povědomí, že Java je pomalé monstrum, ale takovéhle srovnání a tedy i míra toho, jak je to v té Javě asi udělané špatně, stejně zovu překvapí... - ale prdlajs. Jestli neco prekvapi, tak to, ze porad jeste nekdo povazuje podobny nanobenchmarky za uzitecny. Jeste vic prekvapi, ze nekdo povazuje za uzitecny nanobenchmarky, ktery zjevne psal nekdo, kdo treba o ty Jave fakt moc netusi, protoze kdyz jsem ten kod opravil aby pouzival standardni StringBuffer misto String (fix na asi ctyri radky), tak to najednou bezelo trikrat rychlejc a zralo zlomecek pameti. Co ale neprekvapi je, ze XChaos, kterej o Jave vi kulovy, z takovejch nesmyslnejch nanobenchmarku vyvozuje hluboky zavery o tom, jak "je to v ni udelany spatne" 8))))
    XCHAOS
    XCHAOS --- ---
    KOJA: tak mě se to naopak hodně líbí. na práci se stringama je zajímavé to, že většina vyšších jazyků k tomu nabízí spoustu operací, u kterých předstírá, že jsou triviální - ale samozřejmě nejsou.

    KOJA: tak každý jazyk přece nabízí nějaké standardní způsoby práce se základními datovými typy/objekty, mezi které stringy zcela nepochybně patří. nepokládat implementaci stringové knihovny ve stdlib za základní feature jazyka je dost odvážné :-)

    C++ nedopadlo tak zle - ale je velká otázka, zda nějakou abstrakci nad stringy jde vůbec naprogramovat úplně čistě (asi jde, když ten Perl dopadá tak dobře, jak dopadá).

    jejich implementace v C trochu švindluje, protože právě pracuje se stringy jako s mutable a je to právě level, na kterém když se stringy pracují začátečníci, tak spolehlivě vyprodukují děravý kód (což je hlavní příčina všech bezpečnostních děr na bázi buffer overrunů, apod.).

    jinak v Pythonu i Perlu používají volání regulární výraz, zatímco v Céčku primitivnější strstr() a pak přímo přepisují string, což třeba zrovna v tom Pythonu s immutable stringy z pricnipu nejde.. takže je to vlastně demonstrace toho, že low-level práce se stringy je rychlejší, než většina vyšších abstrakcí, která musí stále znovu dokola alokovat prostor pro výsledek stringové operace. Samozřejmě je ale otázka, jestli lidi fakt vést k tomu, aby pro modifikace stringů používali memcpy().. jenže když budu chtít mít jistotu, že něco poběží fakt rychle, tak to sám udělám přesně takhle...

    Mě se ten test fakt líbí, ne proto, že C "porazilo" C++ (protože ta C implementace je až moc lowlevel a samozřejmě takhle nikdo nechceme programovat každodenní práci se stringy, zvlášť kdo to fakt nějaký čas z nějakého důvodu musel dělat) - ale spíš že C++, Perl, Python i PHP to víceméně dělají nějak "dobře", z hlediska rychlosti i spotřeby paměti, zatímco Java a JavaScript jsou v tomhle směru totálně LOL.

    Zajímavé je, jak málo lidí si tohle uvědomuje, existuje samozřejmě obecné povědomí, že Java je pomalé monstrum, ale takovéhle srovnání a tedy i míra toho, jak je to v té Javě asi udělané špatně, stejně zovu překvapí...
    KOJA
    KOJA --- ---
    GIOMIKY: Me tohle obecny porovnavani jazyku na jedny specificky uloze prijde nic nerikajici. Pominu, ze je to "velmi stary" benchmark (Intel Core2 Duo T7500 a kernel 2.6.32).

    Vhled mam velmi omezeny, nicmene z kodu kterym meri "vykon" toho g++ na mi prijde, ze to moc dobre nedela. V komentarich mu tam nekdo radi upravy, ja bych mel ke kodu poznamek i par dalsich (neflushovat ostream buffer napr.). Dale postradam treba i zpusob jakym ten kod preklada (optimalizace, vyjimky zapnute?), coz neni uplne zanedbatelne. Vzhledem k tomu co tam dela, tak konkretne pro c++ nemeri zadne zasadni vlastnosti jazyka ale rychlost implementace std::string, std::ostream (a defaultni alokator pameti) v libstdc++. Zrovna stringy a streamy jsou ale veci ktere se pro "performance critical" kod v c++ nepouzivaji moc casto (resp se pro souvisejici praci nesaha po c++ kvuli vykonu), takze interpretace srovnani je stran c++ trochu slozita.

    Celkem bych cekal, ze pokud jsou opominuty jemnejsi nuance c++, tak u ostatnich jazyku to bude podobne (lidi co maji v hlave detaily ohledne 10 ruznych jazyku zase tak moc po svete behat nebude) a porovnava vhodnost jablek a hrusek do knedlo vepro zela.
    GIOMIKY
    GIOMIKY --- ---
    Porovnani programovacich jazyku z pohledu rychlosti a vyuziti pameti
    http://raid6.com.au/~onlyjob/posts/arena/
    BURAN
    BURAN --- ---
    Asi embedded systemy.
    XCHAOS
    XCHAOS --- ---
    VITEX: .. zatímco obliba čistého assembleru roste, srsly? :-)
    VITEX
    VITEX --- ---
    Programovací jazyk C má nejnižší oblíbenost v TIOBE za posledních 15 let - Root.cz
    http://www.root.cz/zpravicky/programovaci-jazyk-c-ma-nejnizsi-skore-v-tiobe-za-poslednich-15-let/
    XCHAOS
    XCHAOS --- ---
    UETOYO
    UETOYO --- ---
    XCHAOS: :) Ok
    XCHAOS
    XCHAOS --- ---
    UETOYO: klid... v té debatě to právě dost zpochybňují/rozporují, někteří i celkem vtipně :-)
    XCHAOS
    XCHAOS --- ---
    JANFROG: on to ale není vtip, to je to nejhorší... mě to tu někdo do mého makrojazyka právě navrhoval, ať rekurzivní rebalancovací funkci posílám delta pointerů začátku a klíče jako integer... já to nejdřív nechápal, ale po letech se mi rozsvítilo.

    everything is integer (unless stream of bytes :-)
    JANFROG
    JANFROG --- ---
    XCHAOS: Ted jsem se fakt zasmal...ale ti, co to pak dostanou na talir se asi smat nebudou :-)
    XCHAOS
    XCHAOS --- ---
    Mohli bychom na youtube začít točit show "programujeme v C s Babicou"? :-) když nemáš pointer, vraž tam integer? :-)
    Kliknutím sem můžete změnit nastavení reklam