• ú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: 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
    XCHAOS
    XCHAOS --- ---
    JACHYMKO: jak říkám, nejsem windowsolog, ale můj obecný pocit byl, že to stálo za hovno.

    chápej, zkus si něco vyhrabat, jak se programovalo v Borland C++ 3.1 pro Windows 3.1 ... co všechno bylo potřeba inicializovat, apod.

    a pak ti někdo ukáže Unix, ve kterým je stdin, stdout a stderr, a hudba se dá hrát tak, že pošleš obsah souboru na /dev/audio ... v polovině 90tých let prostě nebylo těžké rozhodnout se pro Unix.

    později se použitelnost woken diskutabilně zlepšila, ale prostě programátorsky jsem to už nijak zvlášť neřešil: elegance základní unixové architektury je značná, i když uživatel-neprogramátor to bude mít potíže ocenit. (blbý je, že v dnešní událostma řízený době to už není taková sláva, no..)
    ANT_39
    ANT_39 --- ---
    ANT_39: A ten strom odkazu, co od tam vede, taky neni spatnej, btw.
    REDGUY
    REDGUY --- ---
    JACHYMKO: Ono obecne The Old New Thing je drobne cteni. Pro me nejzajimavejsi tam je ten neustalej (az do nedavna?) duraz Microsoftu na zpetnou kompatibilitu skoro za kazdou cenu a dusledky, jaky to ma. Sice to neni pristup kterej bych zvolil ja, ale plne je chapu.
    ANT_39
    ANT_39 --- ---
    JACHYMKO: Dik za odkaz.
    XCHAOS
    XCHAOS --- ---
    ANT_39: preemptivní multitasking v DOS boxech začínal jakž-takž fungovat pod Windows 95... ale pořád byly problémy (nebo složitosti) s grafikou a komunikačními drivery pro modemy... paradoxně nejčastějším zadáním multitaskingu tehdy ale bylo "chci stahovat něco přes modem a u toho gamesit svojí oblíbenou DOSovskou hru" :-) (mluvím o roce 1995)
    ANT_39
    ANT_39 --- ---
    JACHYMKO: Zajimavy, mel jsem o tom podobny predstavy jako XCHAOS... v te dobe jsem programoval v basicu na atari, takze jsem o tom dohromady nic nevedel, ale vzdy jsem mel za to (hlavne na zaklade toho, co jsem slysel), ze tam preempce nefungovala.
    XCHAOS
    XCHAOS --- ---
    JACHYMKO: ehm, no tak kdo tehdy zkoušel trochu víc to multitaskování ve Windows 3.x, tak právě radši rychle přešel na to Desqview, nebo tak něco :-)

    jsem myslel, že 32bitový byly až Windows 95 ... nevím, nejsem windowsolog, pouze si pamatuju, že to bylo třeskutě nepoužitelný, a pro skutečně produkční účely se na běžně dostupných konfguracích (typu 4 MB RAM, apod.) používal MS-DOS ještě hluboko v polovině 90tých let.
    XCHAOS
    XCHAOS --- ---
    JACHYMKO: tak Windows 3.x samozřejmě byly DOS, že jo. a tím bych tuhle offtopic debatu fakt ukončil.
    XCHAOS
    XCHAOS --- ---
    JACHYMKO: co je "původní PC" ?

    krátce jsem měl přístup k více či méně obskurním 286kám, ale moje první vlastní PC byla 386ka. v té době jsem Linux neznal - ale faktem je, že na stejné architektuře (486ky, Pentia) šlo s pomocí vyzrálejšího Linuxu s jádrem 2.x postavit vcelku stabilní, na dálku administrovaný internetový server.

    to bych nenazval jako "bastl určenej primárně na hraní" - ve skutečnosti, na konci 90tých let v době dot com boomu vydělal ten "spíchnutej" bastl nainstalovanej na secondhand PC připojený do netu leckomu miliony, šťastlivcům jako Google pak rovnou miliardy.

    a naproti tomu - hlavním argumentem pro nasazení MS-DOSu a později Windows byla dostupnost kvalitních her :-) s vyděláváním peněz to bylo složitější (ano - šlo je vydělat tím, že si prodal spoustu PC s MS-DOSem a později Windowsy nějaké rozsáhlé kancelářsky-orientované firmě: ale vydělat peníze koupí této platformy - to už byla jiná kapitola...)

    takže při posuzování toho, co přesně v 90tých letech naplňovalo kategorii "bastl na hraní" bych byl opatrný. ano - na desktopu možná, a v 90tých letech málokoho napadlo použít PC jinde než na desktopu. Ale někteří z těch, které to napadlo, jsou dnes multimilionáři. I díky Linuxu.
    XCHAOS
    XCHAOS --- ---
    JACHYMKO: jo, a nezapomínej taky na nutnost držet kompatibilitu s psacím strojem. té se i v 90tých letech přikládal velký význam, a co teprve v 80tých... :-)
    XCHAOS
    XCHAOS --- ---
    BLAMI: co to je "počítačový panic" ? dnes se malé děti učí zacházet s poměrně složitými mobily dříve, než vůbec jdou třeba do školy, nebo tak... předvést dětem příkazovou řádku bude něco jako mě ukázat ten telefon rozmontovaný (konkrétně starý, klasický mechanický telefon - jo, v tom jsem uměl "spravit" mechanicky zaseklé zavěšovací vidlice a možná seřídit zvonění :-)

    opravdu jednoduchý systém pro začátečníky byl 8bit CP/M, když jsme u toho. oproti MS-DOSu neměly diskety ani adresáře, a hodně logické bylo i zavádění programů do paměti (vše tam stačilo staticky zlinkovat a spouštět od adresy FFH :-)

    každá další éra byla více jednodušší pro toho, kdo chtěl počítače jen používat jako uživatel - případně používat pro vývoj (jednoduchých) aplikací nějaké hotové (složité) vývojové prostředí. ale jiná věc je pochopit, jak věci fungují: a tady skutečně pochopit sekačku na trávu může být jednodušší, než pochopit motor ze stíhačky.

    problém je, že MS-DOS používal motor ze sekačky na trávu pro pohon seriózně se tvářícího sportovního letadla. zatímco Linux by spočátku jen ten motor ze stíhačky -ale bez té stíhačky okolo, dalo se s ním max. jezdi dokola po runwayi na kolečkách od sekačky na trávu :-)
    Kliknutím sem můžete změnit nastavení reklam