• ú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 --- ---
    REDGUY: no pravděpodobně jí měl jak říká [ DAVIDOWITCH @ ANSI C/C99 (specifikace), GNU C (gcc, glibc), Tiny C (tcc) a POSIX - ne nutně C++,g++,libstdc++ nebo Win32 API ] - skrze kopírování paměti jinam. tedy alespoň v reálném módu. zase tý kopírovaný paměti nemohlo být ani tolik :-)

    jsem přesvědčený, že programy vyvíjené pro win32 nebo pro DOS extendér DOS4GW měly už v půlce 90tých let k dispozici v podstatě stejné možnosti, jako dnes. Ale Borland C byl nižší level. určitě to měli implementované divně.
    REDGUY
    REDGUY --- ---
    XCHAOS: Btw: Borland C libc v dřevních dobách DOSu jí podle mě neměla, a z toho vyplynula moje averze k polím a preference spojových seznamů Hmm. Dokumentace rika neco jineho: http://bitsavers.org/pdf/borland/Turbo_C_Reference_Guide_1987.pdf , strana 214 a 173 (cislovani pdfka, ne knihy). Mozna kdyby sis to poradne nastudoval uz tenkrat, usetril sis dvacet let zbytecne averze 8))
    DAVIDOWITCH
    DAVIDOWITCH --- ---
    XCHAOS: Ne, nemuzes se spolehnout na to jak to bude implementovany na konkretni architekture. Jediny na co se muzes spolehnout je, ze to bude na venek delat co pisou ze to bude delat. A ze pokud nejakej kokot napsal dementni implementaci, tak mu nejspis nekdo urval hlavu a uz davno to prepsal efektivne. Ale realloc funguje i na procesorech co proste nemaj virtualni pamet, tam se tezko neco precisluje. (A taky ma potize na 32b OS, kdyz chces velky flaky pameti a mas moc fragmentovanou pamet, a tak vubec)
    XCHAOS
    XCHAOS --- ---
    ...These functions allow glibc-specific interaction with the dynamic memory allocation routines.

    malloc_stats()

    vida. myslím, že právě kvůli podobné sw-archeologii jsem tenhle klub zakládal.
    XCHAOS
    XCHAOS --- ---
    REDGUY:
    ANT_39: přesně pochopit, co malloc() - resp. jeho typické dnešní implementace pro typické dnešní architektury dělá - by mi určitě pomohlo "nejít proti srsti". že z větších bloků ukusuje "po částech", to jsem tušil... a právě proto bych předpokládal, že když udělám realloc() z 3prvkového pole třena na 300 000, tak dojde spíš k fyzickému kopírování ?

    Normally, malloc() allocates memory from the heap, and adjusts the size of the heap as required, using sbrk(2). When allocating blocks of memory larger than MMAP_THRESHOLD bytes, the glibc malloc() implementation allocates the memory as a private anonymous mapping using mmap(2). MMAP_THRESHOLD is 128 kB by default, but is adjustable using mallopt(3).

    vida vida... RTFM... konečně se někam posouváme :-)
    REDGUY
    REDGUY --- ---
    XCHAOS: LOL. No, vzhledem k tomu ze jsi nedokazal ze sebe vysypat aspon vzdalene pouzitelnou definici jak by to melo fungovat a k cemu presne by to bylo uzitecne, je to v podstate irelevantni 8)
    ANT_39
    ANT_39 --- ---
    XCHAOS: U malych pametovych bloku asi tezko, protoze ty se nemapuji separatne. man malloc o tom ma nejake relevantni povidani.
    XCHAOS
    XCHAOS --- ---
    REDGUY: Co ma locale spolecneho s tim, jak presne funguje podobnost objekty ruznych typu?

    Hodně.
    REDGUY
    REDGUY --- ---
    XCHAOS: co se mé hypotetické funkce týče, tak já bych jí viděl právě třeba jako rozšíření POSIXu - které by se řídilo třeba aktuálním locale. - wtf? Co ma locale spolecneho s tim, jak presne funguje podobnost objekty ruznych typu? A proc by to mel byt globalni setting? Bude si kazda aplikace, vyzadujici jine chovani, muset nastavit vlastni locale? A co kdyz v ruznych castech aplikace (treba v 3rdparty knihovnach) budu potrebovat jine chovani?

    Kazdopadne, napises nejaky konkretni navrh jak by to melo fungovat a k cemu presne by to melo slouzit nebo zustanes u "eee.. nejaky ascii string..."?

    A porad by me zajimala odpoved na prvni otazku [ REDGUY @ ANSI C/C99 (specifikace), GNU C (gcc, glibc), Tiny C (tcc) a POSIX - ne nutně C++,g++,libstdc++ nebo Win32 API ] .

    XCHAOS: Divas se na to blbe. realloc neni (typicky) zadna magie se strankovanim, na to zapomen. Proste si to predstav ze reknes libc "Hele, vim ze pamet pro malloc beres z nejakyho vetsiho kusu. Bud tak hodna, jestli za timhle kouskem pameti cos mi pred chvili dala je jeste dalsi volny nepouzity misto, tak ten muj kousek zvets na tolikhle bytu, jinak by normalnim postupem pridel novej kus pameti a na jeho zacatek prekopiruj tohle, at se s tim nemusim delat sam. Diky." Jestli chces, muzu ti to namalovat 8)

    XCHAOS
    XCHAOS --- ---
    DAVIDOWITCH: ano, tohle jsem zhruba potřeboval vědět... to mi ušetří spoustu času.

    ...a můžu se tedy spolehnout, že všechny běžné architektury, na které je libc portovatelné, to budou řešit tím přečíslováním stránek - a ne kopírováním paměti bajt po bajtu ? protože ono je to dost podstatné... přivedlo mi to na myšlenku zacházet s alokací polí výrazně jinak, než s alokací stringů (přeci jen jsem nevzdal myšlenky na ten vlastní alokátor paměti, že...)
    XCHAOS
    XCHAOS --- ---
    _BENNY: já jsem handles používal v 16bit DOSu ... později jsem se dočetl, že stejnou fintu používal původní 16ti bitový MAC OS. (před každým přístupem k pointeru se musela volat mapující funkce, která znovu konvertovala handler na pointer: občas naštěstí ani nebylo nutné skutečně něco fyzicky přesouvat odjinud, protože ten správný blok paměti byl čirou náhodou zrovna namapovaný...)

    moje handlery byly 16tibitové, ale uměly adresovat až 4 GB XMS/EMS/hdd swap :-)
    XCHAOS
    XCHAOS --- ---
    ANT_39: no mě jde spíš o to, že přetěžovat operátory jako + nebo == mě přijde poněkud... víš co. (třeba proč by řetězení stringů mělo mít paralelu k aritmetickému sčítání ? co se mi líbí na C a PHP - a třeba i Bashi - je to, že + prostě není na stringy ... natož jiné kontejnery). (Sakra... na to, jak moc na to PHP jinak nadávám, tak musím uznat, že řetězní stringů má relativně dobrý .. aspoň syntakticky)

    spíš jsem ten operátor =~ nebo ~~ myslel tak, že by měl být asi jediný "přetížitelný": právě když už operátor, od kterého nevím, co mám čekat - tak ať se aspoň odlišuje od matematických.

    ale jinak operátorů už nechme. (C je stejně neumí přetěžovat, tak to max. bude funkce ... :-)
    DAVIDOWITCH
    DAVIDOWITCH --- ---
    XCHAOS: Pockej, to ze se zmeni strankovani jen znamena, ze se nebude fyzicky kopirovat mezi mistama pameti. Logicka adresa (to co vidis v programu) se zmeni tak jako tak. Protoze proste duvod proc to presouva (nejak jakkoliv) je, ze v logickym adresnim prostoru za tim flakem pameti neni dost mista aby ti vyrostl pozadovanym zpusobem, a tak se musi hodit na jiny logicky adresy. Jestli to znamena nebo neznamena ze se bude i neco fyzicky kopirovat je zajimavy z hlediska rychlosti, ale ne funkcnosti.
    ANT_39
    ANT_39 --- ---
    XCHAOS: a naopak se okázale vysmívají lidem, kteří požadují abstrakci, kterou není jednoduché implementovat
    Kdyz ji dobre definujes, tak to pujde implementovat a udelat z toho abstrakci (modulo limity vypocetni uplnosti atp). Debata jde o tom, ze prijit s dobre definovanym ~~ moc nejde.

    a teď bych už možná obrátil list, s dovolením.
    No, uz by to chtelo :)
    _BENNY
    _BENNY --- ---
    XCHAOS: nebo je jeste reseni nepouzivat milion pointeru na jednu strukturu ale milion pointeru na jeden pointer na jednu strukturu, aneb vitej mezi handles.
    XCHAOS
    XCHAOS --- ---
    DAVIDOWITCH: no nasměroval mi tímhle směrem někdo v tomhle klubu, už před delším časem... a hlavně mi tvrdil, že to realloc() pouze změní nějaké pořadí stránkování paměti a ty pointery nerozhodí. jenže evidentně - to je zřejmě možné pouze někdy, ne vždycky - a min někdy ke kopírování obsahu paměti nedojde. a nebo to znamená ještě něco jiného (já tedy v adresování na 32bit a 64bit strojích nejsem vůbec zběhlý) - třeba, že k fyzickému kopírování paměti sice nedojde - ale že adresa jejího umístění se kvůli odlišnému řazení stránek změní ?

    k bezpečnému využití realloc() by tedy mohla stačit zásada, že výsledky operací pointerové aritmetiky se nemají nikdy "ukládat na později" ? (tedy třeba že odkaz na prvek pole se nemá ukládat do pointeru, apod.) hmm...
    DAVIDOWITCH
    DAVIDOWITCH --- ---
    XCHAOS: Gratuluju, objevils novy kontinent.
    A ano, muze se ti stat, ze si zneplatnis vsechny pointery, proto se tim typicky realokujou veci do kterejch indexujes.
    XCHAOS
    XCHAOS --- ---
    realloc() changes the size of the memory block pointed to by ptr to size bytes. The contents will be unchanged to the minimum of the old and new sizes; newly allocated memory will be uninitialized. If ptr is NULL, then the call is equivalent to malloc(size), for all values of size; if size is equal to zero, and ptr is not NULL, then the call is equivalent to free(ptr). Unless ptr is NULL, it must have been returned by an earlier call to malloc(),
    calloc() or realloc(). If the area pointed to was moved, a free(ptr) is done.

    .. tak, a teď babo raď: tohle je skvělá věc (Borland C libc v dřevních dobách DOSu jí podle mě neměla, a z toho vyplynula moje averze k polím a preference spojových seznamů) - ale co o tom realloc() doopravdy kdo víme ? pravděpodobně bude docela platform-dependet: tam, kde lze provést přemapování stránek paměti, aby se alokovaný prostor rozšířil, tam to zřemě bude docela ďábelsky rychlé - ale zřejmě ne každá architektura takové přemapování podporuje - viz ta zmínka If the area pointed to was moved.... ovšem zase pokud realloc() skutečně změní umístění alokovaného bloku, tak tím ovšem zneplatní všechny pointery, které ukazovaly do toho původního bloku - je to tak ? To by znamenalo použít tuto fintu v podstatě jen v kombinace se zcela specifickými programátorskými praktikami (a to vůbec nemluvím o takové thread-safety...)

    máte s tímto někdo zkušenost ? chystám se udělat si pár testů a možná i benchmarků, jak se to chová pro různé velikosti bloků paměti před a po realokaci... ale nerad bych znovuobjevoval Ameriku.. takže uvítám pokud se někdo podělí se svými zkušenostmi.
    XCHAOS
    XCHAOS --- ---
    ANT_39: mě šlo zhruba o to předvést, že programovací jazyky se často holedbají abstrakcí, kterou není těžké definovat a implementovat... a naopak se okázale vysmívají lidem, kteří požadují abstrakci, kterou není jednoduché implementovat.

    prostě se vrátím k základnímu pocitu: ať je MySQL jakékoliv, tak nám na serverech žere zlomek resourců, oproti tomu, kolik toho žerou PHP skripty (paměti, CPU time). a přitom abstrakce, kterou MySQL nabízí, je neskonale sofistikovanější, než abstrakce, kterou nabízí PHP - které reálně neumí skoro nic ! (v podstatě jediný větší komfort jsou asociativní pole - zbytek jsou povětšinou wrappery nad službami systému).

    takže prostě jen tvrdím, že prostor pro optimalizace tu je, a že abstrakce, kterou programátorům vnucují vyšší jazyky, nemusí být nutně ta jediná správná, kterou bychom potřebovali: prostě nás existující prostředí nutí myslet určitým způsobem, nutí nás to využívat zdroje určitým způsobem, apod.

    a teď bych už možná obrátil list, s dovolením.
    XCHAOS
    XCHAOS --- ---
    REDGUY: zapoměl si na druhou část mého příspěvku - MATCH AGAINST se ovšem mění podle nastavení serveru, takže ty věci nejsou zcela jednoznačné.

    no a co se mé hypotetické funkce týče, tak já bych jí viděl právě třeba jako rozšíření POSIXu - které by se řídilo třeba aktuálním locale. Dnes máš přece spoustu knihovních funkcí implementovaných v libc, jejichž chování se mění podle použitého locale... a často i způsobem, který reálně lidé ani moc nechtějí a obcházejí ho (např. desetinná čárka vs. desetinná tečka)
    ANT_39
    ANT_39 --- ---
    XCHAOS: No v tom specifikovanem vyznamu prave bude zakopany pes, ze...
    Nicmene, az udelas ~~, tak dalsim krokem by imho mela byt priblizna diference ~-.
    Kliknutím sem můžete změnit nastavení reklam