• ú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
    REDGUY
    REDGUY --- ---
    1 odpověď
    XCHAOS: Sigh. Jeden hlas na osobu a moznosti, z nichz nektere se nevylucuji? Ty fakt neumis delat ankety...
    DAVIDOWITCH
    DAVIDOWITCH --- ---
    XCHAOS: Jasny. Ja jen ze kdybys chtel asociativni pole jako datovou strukturu, tak to je a dokonce to je glib.
    XCHAOS
    XCHAOS --- ---
    1 odpověď
    DAVIDOWITCH: můj přístup právě umožnuje jako klíč použít téměř cokoliv.. a holt se volá nějaký if() nad akutální hodnotou klíče

    (jiná věc je efektivní hledání, ale to jsme tu řešili snad dva roky.. .do toho bych nerad znovu zabředal)
    DAVIDOWITCH
    DAVIDOWITCH --- ---
    2 odpovědi+1
    XCHAOS: Tak postav ten sytanktickej cukr nad timhle.
    Interface a datova struktura jsou dve separatni veci.
    GHashTable je univerzalni a za to se holt plati.
    Pokud chces jako klice jen stringy, pujde udelat wrapper co to dost zjednodusi.
    XCHAOS
    XCHAOS --- ---
    2 odpovědi

    Je pro vás použití struktury GHashTable intuitivní?

    8 hlasy od 8 respondentů

      XCHAOS
      XCHAOS --- ---
      -1
      JANFROG: děkuji... ale v podstatě to pro mě není nová informace. víceméně - orientuju se na přenositelnost mezi různými distribucemi Linuxu, které všechny stojí na vzájemné kompatiblitě jednotlivých verzí gcc na úrovni kompilovaného kodu (i když binárky a jejich efektivita se liší).

      (víceméně jsem nezávislá socka, působí mimo korporátní i akademické prostředí - a tedy cokoliv kromě Linuxu je v podstatě jak mimo můj dosah, tak i mimo dosah cílové skupiny, pro kterou programuji..)
      JANFROG
      JANFROG --- ---
      1 odpověď
      XCHAOS: gcc s kazdou svou verzi meni to co vygeneruje. Dokonce GCC stejne verze se stejnymi prepinaci na ruznych distribucich linuxu generuje rozdilny kod. Nicmene delej jak chces, jsem sem se Ti snazil poradit na zaklade svych zkusenosti :-)
      XCHAOS
      XCHAOS --- ---
      DAVIDOWITCH: ... ale v tomto klubu je "vysoký obsah syntaktického cukru" zmíněný přímo v záhlaví :-)
      DAVIDOWITCH
      DAVIDOWITCH --- ---
      1 odpověď+1
      XCHAOS: Nevim, taky sem zagooglil:
      Hash Tables
      http://developer.gnome.org/glib/stable/glib-Hash-Tables.html
      Asociativni pole je uvnitr bud hashmap, nebo nejakej strom (STLkovej map je Red-Black tree), pristup pres ["key"] je jen syntactic sugar.
      (Co je asociativni pole v PHPku je black magic, a evidentne to ma vic reprezentaci mezi kterejma to vybira.. vcetne linearniho pole jako mas ty, ktery se pak vyznacuje zoufale pomalym pristupem)
      XCHAOS
      XCHAOS --- ---
      -1
      DAVIDOWITCH: ok, ale nemohli bychom zůstat u toho, že průměrný C programátor toto ví, a je s tím smířen - stejně jako s otázkami týkajícími se možnosti posmrtného života, praktičnosti pohřebu žehem, apod.?
      XCHAOS
      XCHAOS --- ---
      1 odpověď
      DAVIDOWITCH: "běžná céčková knihovna".. to je něco jako "běžný prací prášek"? nevím... zagooglím..
      bud šílenosti jako http://rosettacode.org/wiki/Associative_arrays/Creation/C
      nebo ještě spíš http://cboard.cprogramming.com/c-programming/72160-how-use-associative-arrays-c.html - No. There are no associative arrays in C. Your best bet is to simulate them using structures with whatever key or name you wish to associate with them.

      můj makro-toolkit (zcela nezávisle na tomhle a jiných tutorialech) směřuje k tomu poskytnout pokud možno intuitivní framework pro deklaraci a práci s jednoduchými strukturami, které mají klíč ... princip hashování znám, ale nějak mi neimponuje (Vernamovu šifru na všechny MD5 podepisovače :-)
      DAVIDOWITCH
      DAVIDOWITCH --- ---
      1 odpověď
      XCHAOS: Ono GCC taky meni generovanej kod s kazdou verzi (proto sem, mmj, chtel ten vypis ASM po tobe.. protoze ty verze se lisej obcas dost drasticky)
      DAVIDOWITCH
      DAVIDOWITCH --- ---
      1 odpověď
      XCHAOS: To nema zadna z beznejch Cckovejch knihoven hashmap?
      XCHAOS
      XCHAOS --- ---
      2 odpovědi-1
      JANFROG: jinak k tomu " kazdy C prekladac s kazdou verzi s kazdym jednotlivym prepinacem generuje jiny kod" .... no, tady bych argumentoval tím, že jsem se rozhodl, že mě bude zajímat prostě jen gcc (a holt pokud se časem gcc změní, budu možná muset změnit i moje optimalizace).

      chápu, že se vám moje cíle zdají nízké.. ale jde zhruba o to, že ve většině případů může můj precompiler dosáhnout třeba 5x větší rychlosti, než typické interpretery (Python, PHP) - a holt jsem takový máslo, že to nebude 10x větší rychlost (jak by mohla být, kdybych měl vychytaný všechny ty C optimalizace). (až na to, že já zatím precompiler vůbec nepíšu - píšu si jen normální toolkit, v podstatě pro zlepšení čitelnosti a inutitivnosti nativního C zdrojáku...tím výkon nezvyšuju už vůbec, je to spíš anti-optimalizace - zlepšení srozumitelnosti kodu na úkor efektivity)
      XCHAOS
      XCHAOS --- ---
      JANFROG: počkej... " vyssi programovaci jazyk preklada do C," ... tomu já říkám prekompilace :-)

      každopádně já Javu prostě nerad - co k tomu mám dodat? V tomto klubu to snad není offtopic říct :-)
      JANFROG
      JANFROG --- ---
      2 odpovědi
      XCHAOS: Prekompilace...slepa vetev. Nas system se bootstrapuje tim ze vyssi programovaci jazyk preklada do C, ktere se pozdeji prelozi pomoci GCC/BCC/MSVC. Super technologie pred 25 lety. Dnes uz bych do toho nesel a to i za cenu toho, ze jinak bych musel opustit jednu z mych oblibenych featur soucasneho systemu (inline-C). Dnes bych vse nechal na JITu a pro bootstrap minimalniho systemu bych pouzil interpret AST, jedno jak pomalej.

      Duvody jsou dva:
      (i) stejne musis mit JIT pro rozumny vykon a inkrementalni vyvoj (pro me co nedovoluje vyvijet inkrementalne je nepouzitelne, jsem narocny :-)
      (ii) pokud chces rychlost + GC + nejake pokrocile featurky jako reifikovatelny stack, kontinuace apod, tvrde narazis na to, ze kazdy C prekladac s kazdou verzi s kazdym jednotlivym prepinacem generuje jiny kod, nekdy invalidni, nekdy proste jen ignoruje/ruzne si vyklada volatile, inline apod. Nikdy nemas kontrolu nad tim, jak presne vypada frame na stacku, co v nem presne je, nikdy nevis co presne je v registrech a co v pameti. Tahle nejistota je zabijak...

      Takze pokud prekompilovat, tak jedine do ASM a vypnout vsechny jeho "optimalizace" jako automaticke plneni delayslotu podobne legracky. Kompilovat do C je o neco snadnejsi na zacatku a obrovsky problem na konci. Takze tudy ne, alespon ne pro HLL.


      DAVIDOWITCH: Tak u vsech modernich VM je se zasobnikovy bytekod pouziva spis proto, ze do nej pohodlne preklada a ze to je tradice. Stejne prvni co udelas je ze to dekompilujes zpet do AST a prelozis do strojaku...


      PIGSTER: My jsme tam doiterovali a delame si vsechno sami (VM, knihovny, GUI, IDE, krom operacniho systemu :-) a ma to sve vyhody...
      XCHAOS
      XCHAOS --- ---
      1 odpověď-1
      PIGSTER: no jo... v C určité úrovně abstrakce ale prostě chybí a to klade vyšší nároky na programátora (já zrovna patřím k těm lidem, co by tento problém rádi vyřešili použitím nějakého elegantního toolkitu).

      třeba asociativní pole jsou dost nezbytnost u programování čeho webového/databázového - protože vše, co nějak dostaneš od okolního světa, se nějak jmenuje. přesto třeba když na toto použiješ PHP, tak se můžeš připravit, že ta PHP aplikace sežere v rámci toho procesu nejvíc paměti i času CPU a bude úzkým hrdlem, co se týče počtu přístupů, apod. .. takže třeba toolkit, který by co nejelegantněji a nejjednodušeji suploval asociativní pole v C, mě docela zajímá (já pro svoje vlastní účely zatím používám spojové seznamy normální datových struktur, protože se mi s tím dobře dělá...)
      DAVIDOWITCH
      DAVIDOWITCH --- ---
      PIGSTER: asi preklad, "to delaji proto, ze neumeji"?
      PIGSTER
      PIGSTER --- ---
      3 odpovědi
      XCHAOS: hmm, rekl bych, ze lidi, co pouzivaji nejaky interpretovany jazyk (ruby treba) nebo nejaky GC VM jazyk (c# nebo java treba) to delaji pro to, ze neumeji programovat v C - dokonce bych si dovolil tvrdit, ze nekteri z nich jsou velmi dobre schopni vytvorit infrastrukturu, kterou pouzivaji, kdyby to bylo nutne - ale proc by to nekdo delal? Proc psat framework kdyz uz jich tu je cela rada velmi dobrych (zamerna paralela se soucasnou ceskou PHP komunitou)? Proc ztracet cas vymyslenim hranateho kola, kdyz ho je mozne vyuzit vyvojem automobilu (ktery pouziva jiz existujici kulata kola a evidentne je to plne vyhovujici reseni)?
      Mimochodem, kdyby se to iterovalo o kousek dal, skoncis u psani nastroju, ktere vyviji firmy jako Cadence nebo Synopsys - abys to mel echt sobestacne :)
      DAVIDOWITCH
      DAVIDOWITCH --- ---
      1 odpověď
      JANFROG: Mne se na cely tyhle veci stejne nejvic libi, ze VM jsou misto kde se fakt realne stale porad pouziva zasobnikovej (stack based) ASM. Protoze se to dekoduje rychlejc. (I kdyz, predpokladam ze v momente kdy nejak dopredu JITujes, tak to neni az tak podstatny jako kdyz se chroupaj instrukce po instrukci).
      Kliknutím sem můžete změnit nastavení reklam