• ú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
    ISTEVE
    ISTEVE --- ---
    XCHAOS: FYI: Pyrex, ani jeho naslednik Cython, nedelaj primej preklad Pythoniho zdrojaku do binarky.
    ANT_39
    ANT_39 --- ---
    XCHAOS: Tak muzes to psat nejakym tim subsetem pythonu a prelozit to do C++.
    XCHAOS
    XCHAOS --- ---
    ANT_39: ...si říkám, že nějaká možnost použít tímhle způsobem v C zdrojáku fragmenty Pythonu by právě nebyla od věci :-) a nějaký precompiler by to pak unrollnul do čistého C, a bylo by s tím méně hádek, než u těch mých maker...
    ANT_39
    ANT_39 --- ---
    ANT_39: Eh, a aby byly videt ty pojmenovany parametry :)
    [frac2 setNumerator: 1 andDenominator: 5];
    XCHAOS
    XCHAOS --- ---
    XCHAOS: ... a pokud je chceš uvést, musíš je tuším pojmenovat, zapoměl jsem dodat. ale můžeš pojmenovat i ty povinný.
    ANT_39
    ANT_39 --- ---
    DAVIDOWITCH: ObjC je v podstate smalltalk naroubovany na C. Jestlis nekdy videl volani funkci ve smalltalku, tak v ObjC je to hodne podobne. Nejaky nahodny priklad z google:
       Fraction *frac = [[Fraction alloc] init];
       [frac setNumerator: 1];
    
    XCHAOS
    XCHAOS --- ---
    JACHYMKO: tak v Pythonu je to tak jako šalamounsky, že některý parametry funkcní mohou mít defaultní hodnotu, a ty jsou pak při volání nepovinný.

    ovšem můžeš to tam udělat i tak, že předáš povinný parametry pojmenovaný:

    >>> def funkce(a): return a
    ...
    >>> funkce(a=1)
    1

    jako neříkám, že je mi Python úplně cizí, a možná bych měl rozvíjet nějaký ten Pyrex, Cython, nebo tak něco - prostě nástroje pro přímý překlad Pythoního zdrojáku do binárky, ať už via C nebo jinak. (možná precompiler z Pythonu do C by mi pro začátek získal daleko více příznivců, než moje snahy...)

    Ad to "podívej se někdy na něco jinýho, než C99" - tedy, kromě "nutného zla" v podobě potýkání se s udržování prehistorických PHP skriptů (což fakt není programování) jsem se v posledních letech setkal zejména s Pythonem, SQL a JQuery (což je tedy výrazně více, než JavaScript - JQuery je vlastně svět sám pro sebe, velmi inspirativní...) - takže děkuji za optání, ale nějaké základní povědomí "jak se něco dělá jinde" snad přeci jen mám... problém je, že jsou to vyšší jazyky a nad některýma věcma se tam prostě nepřemýšlí.
    XCHAOS
    XCHAOS --- ---
    REDGUY: chci jen říct, že to bude záviset na tom, jak kdo implementuje a zdokumentuje tu danou funkci: ta funkce bude dělat to, co programátor uzná za vhodné, a co je u ní bezprostředně požadováno.
    DAVIDOWITCH
    DAVIDOWITCH --- ---
    XCHAOS: Nevim, field se v jave rika member variable, jestli s tim miris na web, nechces kolize jmen.
    DAVIDOWITCH
    DAVIDOWITCH --- ---
    JACHYMKO: Ja uhnu hodne stranou (a zkazim si svoji peclive vybudovanou povest uzce specializovaneho doktoranda programujiciho pocitacove hry) a zeptam se prikladem z VHDL, at to pochopim. Tam je instancovani entity (plus minus autobus ekvivalent volani fci) cca takhle:
    ...nejakej bordel...
    port map(
    jmeno_promenny_uvnitr_entity0 => promenna_ve_volajicim0,
    jmeno_promenny_uvnitr_entity1 => promenna_ve_volajicim1,
    jmeno_promenny_uvnitr_entity2 => promenna_ve_volajicim2);

    tj. je vzdycky jasne videt i ve volani co skonci v jak pojmenovany promenny (ultradulezity kdyz predavas konstantu).

    Je to nejak cca tak?
    XCHAOS
    XCHAOS --- ---
    REDGUY: hmm, jako že nějaký parametr třeba u funkce se musí povinně jmenovat nějak ? když s tím přijde ObjC, tak je to dobré, když mám něco povinně pojmenovaného já, tak je to špatně ? :-)

    REDGUY: polovina byla spíš vlastnost zvolené koncepce, než chyba. pokud vyjdeš z premisy "složitější je vždy lepší, než jednoduché", tak ano - pak si měl v podstatě pravdu, a upozornil si "chybně jednoduchou koncepci", na několika bodech.

    REDGUY: jo, u toho try { } pomocí setjmp()/longjmp() bude asi jasné, že fail() bude muset být uzavřením všech načatých paměťových kontextů, ano.. pěkně se nám to zamotává, ale holt tam bude asi nějaký globální seznam kontextů týkající se vždy aktuálního try { } - a stejně bude globální seznam těch vyjímek, aby šlo ta odchycení vnořovat. jako jednoduché to nebude.
    REDGUY
    REDGUY --- ---
    XCHAOS: Ted si nejsem jistej jestli ti spravne rozumim. Rikas, ze funkce A, ktera si bude pro svoje pracovni ucely alokovat nejakou pamet, aniz by ji vracela ven, se nebude muset starat o to, jestli je ve forget nebo remember kontextu, protoze se o to postara funkce B, ktera ji bude volat? Nebo jsem to spatne pochopil?

    a jinak ano - na thread safety asi budeme muset zapomenout. to bude až C<<2 - LOL. Takze na jedne strane rikas, ze chces delat superefektivni programy, ktere umozni provoz serveru pro tisice lidi na jedne masine a na druhe strane zcela rezignujes na multithreadovost - v dobe, kdy desktopova masina muze mit tucet threadu a bez vetsich problemu lze koupit server se stovkama hw threadu. To dava smysl. Moment. Nedava 8)

    A co signaly? A setjmp/longjmp?
    REDGUY
    REDGUY --- ---
    XCHAOS: že si prakticky nikdy nenavrhl žádnou opravu ničeho, čemu říkáš "chyba" - whoa. A ja myslel ze opravy tech bugu co jsem ti ukazoval jsou tak trivialni ze to nemusim ukazovat 8)
    A "chyba" tomu rikame oba, protoze proc jinak bys to potom opravil, ze 8)
    XCHAOS
    XCHAOS --- ---
    REDGUY: já bych se popravdě na základě tvého stylu diskuze a neustálého odvolávání se na iOS vůbec nedivil, kdybys měl něco společného s Dannym. jenže ten měl na NYXu vlastní login, takže je to trochu záhada.
    XCHAOS
    XCHAOS --- ---
    REDGUY: bude se to dědit napříč voláním, ano. funkce NEBUDE muset začínat jedním z těhle maker - máš spoustu funkcí, které vůbec nic nealokují, a pokud ano, a pokud budeš programovat složitější projekt v prostředí, kde budou tyhle alokační zvyklosti - tak bude záležitostí volajícího, zda a kdy chce tu paměť uvolnit nebo ne (tedy např. si do forget nebo remember umístí celé volání funkce - která v naprosté většině případů nebude muset řešit, co s tím chce dělat)

    a jinak ano - na thread safety asi budeme muset zapomenout. to bude až C<<2 :-)
    REDGUY
    REDGUY --- ---
    DAVIDOWITCH: Na tohle je skvelu ObjC a obzlvast v iOSu, jak mas vlastne povinne pojmenovany parametry. Je to trochu o zvyk, ale s rozumnym IDE je to bomba na pouziti.
    XCHAOS
    XCHAOS --- ---
    DAVIDOWITCH: a co ten BENNYHO field ? ten se mi líbí víc....
    a "vector" se většinou vyznačuje velikostí (ovšem v geometrickém smyslu se neváže na žádný pevný výchozí bod). "field" ovšem může znamenat také "položka"...)
    XCHAOS
    XCHAOS --- ---
    REDGUY: chci tady jen nově příchozím vysvětlit, že si prakticky nikdy nenavrhl žádnou opravu ničeho, čemu říkáš "chyba": víceméně se ti musí přiznat, že přemýšlíš o některých méně triviálnějších případech použití, a taky si mě nasměroval k tomu, že v případě někdo jako parametr makra dát složitější výraz, tak pak u mě dojde k jeho vícenásobnému vyhodnocení - což je tedy v podstatě celkově vážný problém při využití jakýchkoliv složitějších maker v Céčku.

    ale tedy to samé by někdo určitě dokázal říkat i méně arogantně.
    REDGUY
    REDGUY --- ---
    XCHAOS: Az na to ze uz v mirne komplikovanem pripade to nefunguje, takze paralelne s tim muzis pouzivat normalni alloc, viz muj priklad par dni dozadu.
    A stav kontextu se dedi napric volani funkce? Podle te globalni promene soudim ze ano. Cili pokud budu chtit konzistetni chovani, kazda funkce bude muset zacinat jednim z tehle maker?
    A kdyz uz mluvime o globalni promenne - znamena to ze na thready muzes leda smutne vzpominat? Jak to bude fungovat se signalama? Co setjmp/longjmp?
    DAVIDOWITCH
    DAVIDOWITCH --- ---
    XCHAOS: muzes tomu rikal array_s, vhodne zkrat dle vlastni chute. Ja sem pro ukecany promenny a fce.
    Kliknutím sem můžete změnit nastavení reklam