• ú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í
    REDGUY
    REDGUY --- ---
    XCHAOS: spoustu věcí se stringem (předávání reference, porovnávání, apod.) lze dělat aniž bych věděl, jak je ten string dlouhý - ano. Ale otazka kterou by sis mel polozit je, u kolika z techto operaci ti nejak _vadi_ ze mas na zacatku napsanou delku retezce. V jakych situacich te to (v soucasne dobe) stoji neco zasadniho navic oproti zero-terminated? Jak caste ty situace jsou? A naopak, pokud tu explicitni informaci o delce nemam, v jakych situacich me to boli? A jak caste jsou? Polozil sis tyhle otazky?


    ale kdybych se u každého pointeru i pole mohl zeptat "kolik mám místa ?" - nu, na to staci pouzivat rozumejsi jazyk, pro ktery pole neni jen flak pameti, ale chytrejsi objekt, ktery o sobe dokaze neco rict, napr. prave celkovou velikost.
    XCHAOS
    XCHAOS --- ---
    REDGUY: no jak říkám, studuj si jaké zdroje chceš, hlavně když máš dobrý pocit z toho, že urážíš druhé. (s tím se v životě určitě neztratíš... ušetříš za antidepresiva a tak...)

    mě víc než oficiální zdůvodnění zajímají takové ty podprahové důvody... skutečně mě přijde podstatné, že spoustu věcí se stringem (předávání reference, porovnávání, apod.) lze dělat aniž bych věděl, jak je ten string dlouhý. popravdě - kromě informací, které potřebuju nebo které by se teoreticky mohly hodit, mě zajímá třeba i přemýšlet, které informace vůbec nepotřebuju...

    ale co. jinak zajímavější je třeba debata, jak zjistit, kolik bylo pro který pointer alokováno.. tuším jsem tady postnul odkaz na nějaké GNU-only varianty tohoto, pro gnu libc malloc... (?) už jsem to ale zapomněl. proběhlo to pozoruhodně bez komentářů.

    copak délka stringu.. .ale kdybych se u každého pointeru i pole mohl zeptat "kolik mám místa ?" .... jo, tak to by bodlo.
    REDGUY
    REDGUY --- ---
    XCHAOS: hlavně, že TY víš, proč se tak rozhodli, že jo - no, ja to vim mj. proto, ze jsem si precetl zduvodneni napsane primo clovekem, ktery tak rozhodl. A pri vsi ucte, to mi prijde jako _mnohem_ verohodnejsi zdroj nez nejake tvoje blaboleni o "zobecneni". Ale samozrejme, jestli ani tohle zduvodneni ti neni dost dobre... nic jineho bych od tebe necekal 8) Jak jsem psal, napis mu, vysvetli mu jak to vlastne tenkrat myslel 8)

    A btw, co tvuj "jazyk"? Uz jsi vymyslel jak fixnout problem s returnem? Nebo porad trvas na tom, ze rozumne reseni je proste return uprostred funkce nepouzivat? Nebo snad dokonce zkusis pouzit nejakej pricetnej zpusob psani vlastniho jazyka (gasp!)?
    XCHAOS
    XCHAOS --- ---
    REDGUY: no ale hlavně, že TY víš, proč se tak rozhodli, že jo. díky tomu už je naštěstí zbytečné, abych se o nějaký odhad snažil já...

    (já nepopírám, že obě řešení mají svoje pro a proti, ale faktem je, že ten článek který si odkazoval, se tvářil, jako kdyby kopírování stringu byla nejčastější operace - což v C, vzhledem k tomu, že od začátku bylo koncipované na předávání referencí na stringy a ne vytváření jejich kopií.... no nic, no)
    REDGUY
    REDGUY --- ---
    XCHAOS: tahle reprezentace byla zvolena, protože ve své době umožňovala maximální zobecnění. Ach jo. Opet blabolis, bez ohledu na jakakoliv fakta nebo dokonce i zakladni logiku. Mozna bys mel napsat Dennisu Ritichiemu a vysvetlit mu, jak zasadne se ve svem zduvodneni plete, nemyslis? Prece jenom, co on, trouba a spoluautor C, o tom muze vedet, ne? Je na tobe abys mu vysvetlil ze to nebylo kvuli pohodli a omezeni delky, ale kvuli "maximalnimu zobecneni" a "stejne implementaci jako na pasce" 8)


    None of BCPL, B, or C supports character data strongly in the language; each treats strings much like vectors of integers and supplements general rules by a few conventions. In both BCPL and B a string literal denotes the address of a static area initialized with the characters of the string, packed into cells. In BCPL, the first packed byte contains the number of characters in the string; in B, there is no count and strings are terminated by a special character, which B spelled ‘*e’. This change was made partially to avoid the limitation on the length of a string caused by holding the count in an 8- or 9-bit slot, and partly because maintaining the count seemed, in our experience, less convenient than using a terminator.

    http://cm.bell-labs.com/cm/cs/who/dmr/chist.pdf
    DAVIDOWITCH
    DAVIDOWITCH --- ---
    No mne by furt zajimalo k cemu to pomaha. Protoze je tady s nama nejakejch 40 let a algoritmy jsou presto pro stringy zname delky.
    Z tveho podani mam dojem ze "kdyby byly stringy nezname delky, tak se zacnou delat algoritmy na veci nezname delky." Jenze ony jsou a presto nedelaji.

    a ad magneticka paska a hypoteza o zvoleni.. kdyz to nacitas z pasky, *musis* tomu naalokovat pamet. A pokud mas drahou pamet, tak si nemuzes az tak moc dovolit picoviny s reallocem, nebo si ji moc rozfragmentujes. Pokud by to bylo jak rikas, tak by fce co s tim pracujou musely umet pracovat se stringem co neni celej v pameti..
    XCHAOS
    XCHAOS --- ---
    (jestli něco Denis a Ritchie fakt posrali, tak to nebyl formát null-terminated string, ale standardní libc funkce scanf() - pozor, ne fscanf(), ten je už ok...)
    XCHAOS
    XCHAOS --- ---
    REDGUY: je to metafora a má cenu do toho tahat streamy: v unixu prostě všechno bylo navržené tak, aby se to co nejvíc podobalo něčemu jinému: string na co já vím, magnetické pásce mohl být implementovaný stejně, jako string v (tehdy ještě) drahé paměti RAM. tahle reprezentace byla zvolena, protože ve své době umožňovala maximální zobecnění.
    REDGUY
    REDGUY --- ---
    XCHAOS: null-terminated string je metafora pro obecný stream znaků neznámé délky - Houbelec. Za prve, null terminated string neni v kontextu teto debaty nejaka "metafora", ale konkretni zpusob implementace. Nema smysl tahat do toho streamy, protoze o nich neni rec. Rec je o tom, jake vyhody ma _v_operaceni_pameti_ reprezentovat textovy retezec bud null-terminated, nebo s explicitni delkou na zacatku. Obecne reci o tom, jestli v nejakem kyberprostoru existuji veci nezname delky jsou irelevantni.

    Ale hlavne, za druhe - v pripade null terminated stringu to neni tak, ze by jeho delka byla nejak obecne neznama nebo dokonce potencialne promenna behem zpracovani, tak jako u souboru nebo streamu. Ten string je ulozenej v pameti, bylo potreba pro nej naalokovat konkretni misto, ta ukoncovaci nula je na nejake konkretni pozici. Delka toho retezce _je_ pevne dana. Problem neni v tom ze by to byla neznama informace, problem je ze pro programatora je relativne drahe tu informaci ziskat (na rozdil od alternativniho zpusobu implementace retezcu).
    ANT_39
    ANT_39 --- ---
    XCHAOS: To zalezi jak to beres, tu obecnost. V null terminated stringu zas treba nemuzes mit nuly.
    XCHAOS
    XCHAOS --- ---
    (když jsme u toho, tak obecný iterátor for_each() - v Python jakékolivfor - by vlastně měl umět pracovat s kontejnery, jejichž délka v okamžiku otevření ještě není známá... ale to už jsme odbočili).

    s trochu nadsázky lze říct, že v podstatě v prostředí, ve kterém všechno víme předem, ani není důvod něco programovat :-)
    XCHAOS
    XCHAOS --- ---
    DAVIDOWITCH: no já jsem v podstatě chtěl říct, že null-terminated string je prostě obecnější datová struktura, než string známé délky - je to o tom, že s tím můžeš pracovat, i když o tom máš předem míň informací, během práce o tom shromáždíš míň informací, apod.

    nechtěl jsem zabředat do megaflejmu - jen poukazuju na to, že ty dva přístupy nejsou ekvivalentní, a že to není jen o tom, že by se vynálezci Céčka nějak svévolně rozhodli mezi dvěma rovnocennými alternativami a zvolili tu horší.

    REDGUY: viz výše - a viz všechno předchozí.

    null-terminated string je metafora pro obecný stream znaků neznámé délky ("everything is stream of bytes - repeat until enlightened"), pravda sice jde o speciální případ, kdy je ten stream (obvykle) celý v paměti - ale pořád můžeš vzít stejný algoritmus a v něm jenom změnit "čti bajty z paměti" za "čti bajty ze souboru" nebo "čti bajty ze streamu".

    obecně stejně jako máš stream neznámé délky (roura, TCP stream apod.) a soubory jako streamy, které mají v okamžiku otevření známou délku (která se ovšem může změnit !!!), a s těmi prvními můžeš pracovat jen sekvenčně, zatímco u souborů máš random seek, tak stejné je to i s těmi stringy: prostě null-terminated string je obecnější případ, ve kterém třeba dokud si ho "nepřepočítáš" ani nemůžeš náhodně seekovat.

    určitě si lze představit systém / prostředí, ve kterém by si o všech objektech jakéhokoliv typu předával informace o tom, jak jsou velké - to ano. (třeba by si ani nesměl otevírat streamy po síti, aniž bys neřekl, jak jsou velké). otázka je, jestli je takováhle restrikce fakt potřeba: jestli prostě netolerovat, že "v kyberprostoru kolem tebe" existují streamy předem neznámé délky...
    DAVIDOWITCH
    DAVIDOWITCH --- ---
    XCHAOS: To byla otazka. Jaka spousta. Krom toho ze ho ciste pipujes a vubec se ho nedotknes.
    XCHAOS
    XCHAOS --- ---
    DAVIDOWITCH: mno, tak v unixu se právě spousta věcí dělá předtím, než je string hotovej: třeba ho posíláš na stdout a ten jde přes stdin na vstup jinýho programu... (a co je stream nebo soubor jiného, než vlastně jen hodně dlouhej string ?). prostě to vede k psaní algoritmů, které nemají spočítáno, "kolik toho je" - ale spíš se ptají a jsem už na konci, nebo ještě něco přijde ?".

    v zásadě oba přístupy mají svoje závažné nevýhody, když si představíš třeba multithreading... s tím, že jedno vlákno string vytváří, a druhé se ho současně už snaží číst... jsou tam podobná dilemata, jako u všech jiných kontejnerových typů.

    a šlo by vymyslet i spoustu jiných divných datových struktur: třeba by mohl existovat konensus, že pole pointerů je ukončeno NULL pointerem - nebo jiným "divným" pointerem - a tak zjišťovat jeho délku... tohle se ale na rozdíl od null-terminated stringů pokud vím nikdy neujalo...

    tuším třeba pro LISP se kdysi vyráběl i speciální hardware, který nějak optimálněji pracoval s jejich specifickými datovými strukturami (ale moc o tom nevím). a "softwareová archeologie" je BTW oblíbeným námětem cyberpunkových sci-fi... a bylo by zábavné třeba jako zápletku nějaké sci-fi zapojit do hry analýzu fiktivních datových struktur objevených v operačním systému mimozemské kosmické lodi :-)
    DAVIDOWITCH
    DAVIDOWITCH --- ---
    XCHAOS: podobne jako kdyz dneska pises neco (v asm) na jednochip, rekl bych. A popravde mne nenapada moc manipulaci ktery by sly delat se stringem nez je hotovej.
    Pokud bys jel multithreading, tak si proste s tim reallocem uplne v haji, pokud to nebudes zamykat (a pak se nemusis vubec obtezovat multithreadingem). Pokud nemas, tak mas velmi tesne interleaved nacitani a tu operaci co zrovna delas, a to mi prijde jako velmi spatnej napad no matter what.
    A i tak by to byl velmi specialni pripad, a radsi budu mit univerzalni dobrou datovou strukturu a pak specialni pro specialni pripad, nez neco co se hodi na vsecky a sity to je na necky.

    (vic mne v tom prikladu desi napad, ze 16b delky by melo bejt dost pro vsechny)
    REDGUY
    REDGUY --- ---
    XCHAOS: V cam je tedy podle tebe vyhoda null terminated stringu pri tzv "on-the-fly" zpracovani? Musim ho mit v pameti, pamet musi byt predalokovana (resp. pokud neni, musim ji reallocovat v obou pripadech)? Kde je konkretni vyhoda? Nejak mi to z tveho vysvetlovani neni jasne, prosim, vysvetli to podrobneji.
    XCHAOS
    XCHAOS --- ---
    DAVIDOWITCH: mno, můžeš mít předalokovanou paměť... ale někde musíš mít uloženou tu délku, a postupně jí zvyšovat, jak ti načtený kus stringu přibývá.

    a tady by bylo závislé na konkrétní implementaci, jestli by si algoritmus pokaždé sahal na místo, kde je uložená délka stringu - a nebo jestli by si to okopíroval do proměnné na začátku.

    samozřejmě, u toho postupného načítání vznikne stejný problém, kdyby si chtěl třeba zavolat strlen() na začátku - jenže právě "tradiční" čtení null-terminated stringů je většinou "zleva doprava" - a ne, že se nejdřív zeptáš jak je to dlouhé.

    možná, že "výhoda" o které mluvím, hrála v těch 70tých letech větší roli, než dneska... těžko říct, moc si neumím představit, jak se tehdy doopravdy programovalo.

    JACHYMKO: hmm, vzhledem k tomu, že filename bývá dlouhé řádově max. desítky bajtů (tvrdý limit je tuším 256, nebo tak něco), tak zrovna TOHLE nevidím největší bottleneck POSIX API :-) (jako že několik vážných bottlenecků tam jinak existuje... hlavně, že se občas kvůli celkové koncepci práce se streamy a soubory kopírují větší bloky dat sem tam po paměti, když by se to _teoreticky_ dalo udělat jinak, apod.)
    DAVIDOWITCH
    DAVIDOWITCH --- ---
    XCHAOS: Jak s nim chces pracovat, s ohledem na jeho umisteni v pameti? Bude mas predalokovanej mrak pameti do ktery ho sosas (a pak muzes mit fixed length), nebo to reallocujes jak to jde, a pak s nim nemuzes delat vubec nic, protoze ti skace pameti jak nadmuta koza.
    XCHAOS
    XCHAOS --- ---
    (je to opět odbočka k mému filosofování o tom, že algoritmy pracující s případy, kdy "víme, kolik toho bude", jsou úplně jiná kategorie, než algoritmy třídy "nevíme, kolik toho bude...)
    XCHAOS
    XCHAOS --- ---
    jako já jsem o tomhle přemýšlel docela hodně, a musím se null-terminated stringů v některých ohledech zastat. především: ve chvíli, kdy se string začíná zpracovávat, vlastně ještě vůbec nemusíme vědět, jak bude dlouhý !

    dnes si všichni představují, že string na začátku vždycky musí být _někde_ v paměti... ale to prostě není pravda. null-terminated string může vznikat a být spracováván on-fly, a jeho zdrojem může být nějaké sériové zařízení (dnes nejčastěji TCP stream, historicky třeba sériový port...). V podstatě díky koncepci null-terminated stringu můžeme např. pracovat se stringem, jehož začátek už dorazil v prvních packetech - zatímco konec je pořád ještě na cestě.
    REDGUY
    REDGUY --- ---
    Co takhle misto off-topic spamu o historii DOSu od nejmenovaneho trolla neco k veci? 8)

    The Most Expensive One-byte Mistake - ACM Queue
    http://queue.acm.org/detail.cfm?id=2010365
    Kliknutím sem můžete změnit nastavení reklam