• ú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 --- ---
    1 odpověď
    XCHAOS: pokud bys použil scope, o kterém víš, že je explicitně určený pro vymezení nějaké alokace paměti - a právě proto si ho použil - tak bys do tohohle scope asi nedával goto nebo longjmp() - proc ne? Proc by se v takovem kontextu nemohla vyskytnout situace kdy by bych potreboval goto/longjmp?
    Kazdopadne jsi mi neodpovedel. Co se stane v tom pripade co jsem napsal?

    no prostě tohle fakt nechám na ostatních, ať rozhodnou. já prostě tvrdím, že goto se obecně nedporučuje, i když k dispozici je. takhle učili programovat mě. jestli tebe jinak, tak se holt pochlub, k čemu ho běžně používáš ty - pekne menis tema. Ale zduraznoval jsem ze jde o ten blabol v zavorce o ukoncovani programu po pouziti goto. Pokud te tohle nekdo ucil, mel bys chtit vratit penize. A pokud ses to naucil sam... hmmm, jo, to dava smysl 8)
    XCHAOS
    XCHAOS --- ---
    1 odpověď
    REDGUY: no nevím, jak běžně ve svých programech ostatní běžně používají "holé" setjmp/longjmp... je pravda, že s tím mícháním kontextů to moc dohromady nejde.

    já nevím, pokud bys použil scope, o kterém víš, že je explicitně určený pro vymezení nějaké alokace paměti - a právě proto si ho použil - tak bys do tohohle scope asi nedával goto nebo longjmp() ... ano, předpokládám u lidí aspoň minimální příklon k základním zvyklostem strukturovaného programování, po všech těch letech. pokud jsem řekl, že "pojmenované kontexty by byly něco jako goto", tak jsem měl na mysli, že v mých vlastních programech se už nějaký ten pátek žádné goto nevyskytlo...

    REDGUY: no prostě tohle fakt nechám na ostatních, ať rozhodnou. já prostě tvrdím, že goto se obecně nedporučuje, i když k dispozici je. takhle učili programovat mě. jestli tebe jinak, tak se holt pochlub, k čemu ho běžně používáš ty :-)
    REDGUY
    REDGUY --- ---
    1 odpověď
    XCHAOS: ne náhodou se v C doporučuje použít goto max. jen na ošetření chyb (s následným rychlým ukončením programu, pokud možno). - wtf? Prosim, ukaz mi kde se _tohle_ doporucuje, zejmena ta cast v zavorce. Opravdu by me to velmi zajimalo. Predem diky 8)
    REDGUY
    REDGUY --- ---
    1 odpověď
    XCHAOS: Dobre, takze konkretni priklad:
    static jmp_buf buf;
 
void foo(void) {
    forget {
        longjmp(buf,1);
    }
}
 
void main() {
    remember {
        if ( ! setjmp(buf) ) {
            foo();
        }
        ALOKUJ_PAMET;
    }
}


    Z ktereho kontextu se bude brat pamet v miste ALOKUJ_PAMET?

    proč pořád potkávám online takové lidi, jako jsi ty hmmm. Porad potkavas lidi co ti vysvetluji jake nesmysly rikas? Hmmm... to je ale opravdu zvlastni, cim by to jenom mohlo byt 8))
    (a uz po nekolikate: obavam se, ze "Strawman fallacy" znamena neco jineho nez si myslis ze znamena. Vzhledem k tomu jak casto to spojeni pouzivas, doporucuju si to zjistit a _pochopit_ 8)
    XCHAOS
    XCHAOS --- ---
    XCHAOS: (ok, už tam jsem)
    XCHAOS
    XCHAOS --- ---
    1 odpověď
    DAVIDOWITCH: hmm, nevím:

    501 Not Implemented
    The requested method is not implemented by the server.

    .. ale jistě dobrý pokus.

    ale s tou definicí obsahu struktur v tomhle stylu je to fakt pěkné... přiznám se, že to nějak šlo mimo mě, je to velmi úsporný zápis.
    XCHAOS
    XCHAOS --- ---
    1 odpověď
    REDGUY: "co se stane, když někdo udělá goto" je velice zajímavá otázka - ne náhodou se v C doporučuje použít goto max. jen na ošetření chyb (s následným rychlým ukončením programu, pokud možno).

    no a protože já jsem navrhl (a předvedl) mechanismus odchytávání chyb, který se bez goto obejde, tak víceméně se dá říct, že v dialektu C<<1 nebude použití goto doporučeno a basta :-) tohle je už fakt mlácení prázdné slámy: v jazyce, ve kterém se programování skládá prakticky jen z možných chyb, které programátor může udělat (námatkou: zapomene zavolat free() na pointer, opakovaně alokovaný v nějaké smyčce, nebo hůře zavolá free() na pointer, na který existuje ještě nějaký jiný odkaz, přistupuje do pole za jeho poslední alokovaný prvek, atd., atd.) mě někdo začne vyčítat, že i při použití mnou navrhovaných technik se bude možné dopustit chyb !

    ano, bude - pokud se někdo mermocí rozhodne otrávit a navíc ještě oběsit z Nuselského mostu a potom se navíc ještě k tomu zkusí zastřelit, ale netrefí se do hlavy, ale do nohy - tak ano, v tom případě mu opravdu nepomůže standardní postup, že by ho z té oprátky někdo prostě odříznul. Můj postup je určený pro lidi, kteří se chtějí normálně obesit doma na půdě na trámu - a nechtěji se u toho současně ještě otrávit nebo zastřelit.
    XCHAOS
    XCHAOS --- ---
    1 odpověď
    REDGUY: ...což je přesně záležitost optimalizací jen u některých compilerů na některých platformách... zatímco když chci optimalizovat já, je to vždycky špatně.

    REDGUY: proboha, kdo by tady něco chtěl zakazovat ? jsou to prostě funkce, které nabízí libc a podle mě specifikace POSIX. mě by je normálně používat nenapadlo - ale na odchytávání chyb v C++/Java/Python apod. stylu se nic jiného použít nedá. já je použiju tak korektním způsobem, jak to bude možné - ale proboha, pokud si někdo jiný bude chtít způsobit problémy, ať si je způsobuje, proč bych mu to zakazoval ?

    chápeš, že tvoje linie diskuze ve stylu "všechno co řekneš je špatně, protože si idiot" je prostě dlouhodobě neudržitelná - po čase když ti začnou docházet reálné argumenty, vymyslíš si úplně umělé, abys měl dál nepřítele. prostě jedna strawman fallacy za druhou. (proč pořád potkávám online takové lidi, jako jsi ty ? co vás na tom baví ?)
    REDGUY
    REDGUY --- ---
    1 odpověď
    DAVIDOWITCH: Nemluve o tom ze misto aby se to predavalo pekne rychle v registrech, slo by to pres pamet.
    REDGUY
    REDGUY --- ---
    2 odpovědi-1
    XCHAOS: Chapu spravne ze zakazes pouzivani setjmp/longjmp jinak nez povolenym zpusobem? A btw, co se stane kdyz nekdo udela goto z remember do forget (nebo naopak)? A prosim neutikej k podobnstvim o otevrenych souborech a podobne: zajima me, kde se bude v takovem pripade alokovat pamet.
    REDGUY
    REDGUY --- ---
    XCHAOS: tak zásadně předávej jako parametry všech funkcí v C struktury, a tyto struktury před zavoláním funkce vyplň. efekt bude stejný. - ROFL. Pevne doufam ze tohle je jen projev tveho nutkani se mnou za kazdou cenu nesouhlasit, protoze jestli to myslis vazne, potes pambu. Pro kazdou funkci vytvorit extra parametrovou strukturu, pred kazdym volanim vytvorit jeji instanci, vyplni a pak predat do funkce je mi prijde jako vyrazne jiny efekt nez proste napsat [object setX:x andY:y]. I kdyz pravda, o Cll1 si myslis ze je to dobre a snadno pouzitelny jazyk, takze to vlastne dava zvlastni, hrozivy smysl.... brrrr, uplne me zamrazilo 8)
    REDGUY
    REDGUY --- ---
    XCHAOS: jestli to je pro dané prostředí "nativní" funkce, nebo jestli je to externí knihovna. - podle toho co jsi psal i nativni funkce budou muset nekdy pouzivat malloc, v okamziku kdy staticnost forget/remember prestane stacit.

    bude to asi stejně snadno zdokumentovatelné, jako dnešní chování libc funkcí - urcite je to "snadno zdokumentovatelne". Ale je to dalsi informace kterou musis brat v uvahu, coz komplikuje praci.

    a ano - pokud to bude nativní Cll1 funkce, tak nejspíš ovšem neuvolní a bude alokovat v nadřazeném kontextu a ne pomocí malloc. - tim "alokovat v nadrazenem kontextu" myslis alokovat i pracovni pamet, kterou nebude vracet?


    pokuď místo standardního malloc() použiješ nějaký garbage collector či tak něco - jak to uděláš ? - v prvni rade, pouzivam jazyk ktery uz ma rozumnou praci s pameti od narozeni a nemusim do nej dobastlovat nejakou prasarnu. V druhe rade, kdybych mermomoci chtel dobastlit neco do C (jakoze mi to prijde jako zbytecna a marna prace), zakladni podminka by byla aby to byl _univerzalni_ alokator, schopny zvladnout vsechny situace a tudiz aspon teoreticky schopny nahradit malloc. Coz tvuj bastl neni. Design rikajici "pouzivej muj alokator, ale v situaci kdy jeho omezene schopnosti prestanou stacit, vrat se zpatky k mallocu" je horsi nez nic.
    DAVIDOWITCH
    DAVIDOWITCH --- ---
    ANT_39: jasny
    ANT_39
    ANT_39 --- ---
    1 odpověď
    DAVIDOWITCH: Zalezi co bys od toho potreboval. Ty membry muzou byt char const * ci tak neco, zejo.
    DAVIDOWITCH
    DAVIDOWITCH --- ---
    2 odpovědi+3
    XCHAOS: Ono je to validni i bez tech .x =, akorat pak to zase neplni ucel.
    Jinak, asi by te mohl (a mel) zajimat tenhle odkaz:
    C Programming Puzzlers
    http://stevenkobes.com/ctest.html
    XCHAOS
    XCHAOS --- ---
    1 odpověď
    ANT_39: tak popravdě, zase jednou si mi překvapil... že je takovýhle zápis validní, to jsem fakt nečekal... :-)
    XCHAOS
    XCHAOS --- ---
    1 odpověď
    REDGUY: hele, k tomu setjmp/longjmp - já to chci využívat velice specifickým způsobem, který má implementovat (vnořovatelnou) try { } strukturu odchytávání vyjímek. tedy někaé "longjmp dovnitř rememeber" je úplný nesmysl - když se podíváš na moje starší pokusy (pravda, nedokonalé), tak z nich vyplyne, že

    a) skočit lze pouze na místo,kde si udělal setjmp (v mém případě tedy jen dovnitř makra try { }), a
    b) lonjmp se volá v místě vyjímky

    tedy nemůžeš z principu skočit "dovnitř" něčeho, kde si před tím nebyl: opustíš ovšem několik úrovní scope - a pokud tyto scopy měly vlastní memory pool/pamětový kontext, tak by bylo žádoucí na úrovni toho odskoku provést patřičné operace - tedy nastavit správný kontext a uvolnit ty opuštěné.

    podotýkám, že jde o stejný problém, jako např. o uzavření otevřeného souboru, pokut vyjímku vyvolá operace čtení - pokud to neuděláš, tak se všechny sobory uzavřou po ukončení programu, a všechna alokovaná paměť se taky uvolní po ukončení programu.

    já budu logicky uvažovat tak, abych v rámci svého systému ošetření vyjímek pokud možno řešil vše, co jsem mohl "pootvírat" automatickými strukturami jazyka: tedy pokud budu mít nějaké for_each na čtení souboru, bylo by asi rozumné ten soubor zavřít - a to samé v případě paměti, socketů...

    ano, bylo by samozřejmě zajímavé posoudit, jak to dělají ostatní jazyky - když vyjímka nastane v situaci, kdy máš X otevřených souborů, spoustu inicializovaných objektů, apod. - a najednou skočíš do jiné části programu a odchytáváš vyjímku. - nemyslím, že tohle je C specifický problém, a několikrát jsem zmiňoval, že systém odchytávání vyjímek je ošemetný a neměl by být nadužíván (já jsem viděl příklady, kdy se s vyjímkou počítá jako v podstatě "normální situací", pro řízení algoritmu - např. že nemožnost přidat prvek do SQL tabulky je odchycen jako vyjímka, apod.)
    DAVIDOWITCH
    DAVIDOWITCH --- ---
    2 odpovědi
    ANT_39: Tak, ucel by to splnilo. Bude se to asi blbe constovat, ne?
    ANT_39
    ANT_39 --- ---
    3 odpovědi+2
    Hmm...
    typedef struct {
  int x, y, z;
} foo_params;

int foo (foo_params params) {
  return params.x + params.y + params.z;
}

int main(int argc, char *argv[]) {
  return foo ((foo_params) {.x=1, .y=2, .z=3});
}

    Jarku rozkos ;)
    XCHAOS
    XCHAOS --- ---
    1 odpověď
    REDGUY: ok, no tak pokud ti to vyhovuje, tak zásadně předávej jako parametry všech funkcí v C struktury, a tyto struktury před zavoláním funkce vyplň. efekt bude stejný.
    XCHAOS
    XCHAOS --- ---
    1 odpověď
    REDGUY: tedy, ten první bod je částečně pravda - prostě budeš potřebovat vědět, jestli to je pro dané prostředí "nativní" funkce, nebo jestli je to externí knihovna.

    ten druhý bod není úplně pravda - resp. bude to asi stejně snadno zdokumentovatelné, jako dnešní chování libc funkcí - některé paměť alokují, jiné chtějí pointer na už alokovanou strukturu, apod.

    zatím jsem popravdě nepřemýšlel, jak by vypadaly konvence pro psaní složitějších knihoven v mém prostředí: je asi zjevné, že funkce po sobě tak či onak uklidí to, co nepotřebuje, a neuklidí jen to, na co vrací nějaký odkaz (to je stejné, jako dnes, řekl bych). a ano - pokud to bude nativní C<<1 funkce, tak nejspíš ovšem neuvolní a bude alokovat v nadřazeném kontextu a ne pomocí malloc.

    víceméně - pokuď místo standardního malloc() použiješ nějaký garbage collector či tak něco - jak to uděláš ? jsi na tom podle mě stejně, ty části programu či externí knihovny používající standardní malloc() místo tvého superalokátoru, budou od tvého systému správy paměti izolované (přiznám se, že na tak rozsáhlém projektu jsem zatím nedělal...)
    Kliknutím sem můžete změnit nastavení reklam