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)

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

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)

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: (ok, už tam jsem)

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.

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.

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