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í ?)

DAVIDOWITCH: Nemluve o tom ze misto aby se to predavalo pekne rychle v registrech, slo by to pres pamet.

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)

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.

ANT_39: jasny

DAVIDOWITCH: Zalezi co bys od toho potreboval. Ty membry muzou byt char const * ci tak neco, zejo.

ANT_39: tak popravdě, zase jednou si mi překvapil... že je takovýhle zápis validní, to jsem fakt nečekal... :-)

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

ANT_39: Tak, ucel by to splnilo. Bude se to asi blbe constovat, ne?

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á :-)