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ý.

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...)

Remembering Alan Turing On His 99th Birthday - Slashdot
http://science.slashdot.org/story/11/06/23/1314220/Remembering-Alan-Turing-On-His-99th-Birthday

XCHAOS: Takze pro kazdou funkci bude potreba navic vedet nasledujici (krome normalnich veci):
- pokud vraci nove alokovane objekty, jestli je alokovala v remember bloku nebo malloc
- jestli nejak alokuje pamet v defaultnim kontextu, pred tim nez udela svoje vlastni remember/forget, protoze podle toho bude volajici funkce mozna muset obalit jeji volani extra blokem.

Je to tak?

XCHAOS: 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ě ? - ne. Kdyby sis o tom ObjC a iOSu neco precetl, vedel bys, ze to neznamena ze se "parametr musi povinne jmenovat nejak", ale ze metody volam napr. [view insertSubview: sv atIndex:i], kde view je objekt jehoz metodu volam, sv,i jsou parametry metody. Tj. parametry nejsou pozicni, ale pojmenovane (byt musi byt ve spravnem poradi). Neco podobneho jako named parameters v pythonu. Je to ukecane, ale velmi to pomaha citelnosti a kdyz mas dobre ide, nepridava to praci.

co se setjmp, longjmp tyce - nechapu. Co se stane, kdyz z forget bloku udelam longjmp do remember bloku? (resp. (a) co chces aby se stalo a (b) jak to zaridis)

XCHAOS: Ja to vztahl k tem defaultnim promennym, ne k tomu prirazovani jmenem.

XCHAOS: A ja vim co je fortran, neni to jazyk nasich otcu a nebudiz mu zeme lehka, naprosta vetsiny moderni fyziky se v tom pocita a jeste mnoho let pocitat bude.
A jo, o tyhle tendenci vim, ty to chces opacne, zajimalo by mne planovany vyuziti takovy moznosti.

DAVIDOWITCH: tak já sakra vím, co to dělá, když jsem to zmínil !!!

DAVIDOWITCH: ano, a dnes je tendence udělat architekturu aplikace třeba v Pythonu, který je dynamicky vždy zcela nad věcí - a optimalizované moduly psát v C.

O tom, že Fortran je jazyk specializovaný na násobení matic, se vyprávěly vtipy už v prvních učebicích programování, když jsem byl ještě na základce. (V mém případě bych měl tendenci ten jazyk nazývat "fotran", protože můj fotr v něm velkou část života programoval :-) je to takový jazyk našich otců, budiž mu země lehká :-)

XCHAOS: Bacha, tohle je neco jinyho. Tohle je ze operator prirazeni, krom samotnyho prirazeni, taky vraci to co priradil. Je to ekvivalent:
if((a=strcmp) != 0){...}

XCHAOS: Pockej, mas pro mne nejaky pouziti?
Protoze typicky se chce aby se ty vic high level koncepty (cely systemy/programy) delaly v necem s vysokou abstrakci a cim niz se jde, tim vic se pak muzou podle potreby veci specializovat.

Priklad z fyzikalnich simulaci, velky veci se delaj ve fortranu. Ale kdyz dojde na ty konkretni veci uplne dole, tak ty cally jsou na knihovny psany v Ccku nebo primo v ASM.

Tj. treba nasobeni velkejch matic atd je hrozne multithreadovany a pres sit a kdesicosi (Fortran, Java apod), pak uz nejakej node dostane matici, kterou teda ma vynasobit a jde (ve Fortranu) rekurzivne na neco jako 16x16, kde nastoupi hyperoptimalizovanej ASM kod kterej to vypocita. (A to Fotran compilery nejsou zadny smejdy)

To po cem volas mi prijde jako presnej opak tohohle pristupu.

ISTEVE: tak zrovna o tomhle se rád dozvím víc, jak to funguje.

já assemblerista nejsem, ale zase na pre-compilaci do C zdrojáku bych si samozřejmě troufl. jestli mě přesvědčíte, že nemám vyvíjet žádná makra, ale rovnou používat Cython, bude to zajímavé :-)

DAVIDOWITCH: jako v C toto je platné pokud ta proměnná existuje se stejným názvem i uvnitř volajícího scope:

{
int a;
funkce((a=1));
}

teď mě samotného zmátlo, jestli jsem tím příkladem v pythonu deklaroval proměnnou i v aktuálním scope - podívám se:

> a
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
NameError: name 'a' is not defined

... takže ne. výrazy předávané jako parametr funkce jsou u C součástí aktuálního scope, v Pythonu je to naproti tomu nějaká elegantní antigravitační magie.

ANT_39: Videl, nice, dik.

XCHAOS: Ono tohle Ccko vlastne neumi, co? Ja to nemam moc rad, protoze kdyz se pak snazim lustit kod a nemam naseptavac, tak poznat ze to je call na stejnou fci a ne na jinou verzi je dost neprijemny. (Musi se hodne do dokumentace)

ANT_39:
http://en.wikipedia.org/wiki/Pyrex_%28programming_language%29
http://en.wikipedia.org/wiki/Cython

.... bohužel, tohle je přesně obrácený směr. mě by se líbilo naopak do programu v C vložit fragment s Pythoní syntaxí, který by se výsledně překompiloval jako součást té aplikace. a protože python je celkově čitelnější než C, tak vlastně to co chci, je něco jako precompiler z Pythonu do C (jenom nevidím důvod, proč by měl být do C++ ...)

samozřejmě, že vývoj který dělám teď se vůbec nevylučuje s tímhle cílem: v podstatě čím víc toho člověk umí naprogramovat v C, tak z tím většího množství "vyšších jazyků" je pak schopný udělat nějaký jednoduchý precompiler do C ...

XCHAOS: FYI: Pyrex, ani jeho naslednik Cython, nedelaj primej preklad Pythoniho zdrojaku do binarky.

XCHAOS: Tak muzes to psat nejakym tim subsetem pythonu a prelozit to do C++.

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: Eh, a aby byly videt ty pojmenovany parametry :)

[frac2 setNumerator: 1 andDenominator: 5];

XCHAOS: ... a pokud je chceš uvést, musíš je tuším pojmenovat, zapoměl jsem dodat. ale můžeš pojmenovat i ty povinný.

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];