REDGUY: return se doporučuje používat na konci :)

mě to tak směšné nepřijde: máš tam místo toho třeba pět nějakých pointerů na nějaké struktury, pole stringy - prostě objekty vytváření "za pochodu", které tak či onak musíš alokovat a na které musíš na konci ručně volat free()

fakticky nakopíruješ těch pět volání free() před každý return v té funkci ?

mimochodem - z mého kontextu půjde předčasně escapnout pomocí instrukce continue; - a dealokace se pochopitelně provede - tedy design pattern je následující:

rv=0;
forget
{

if(redguy)
{
rv=-1;
continue;
}


}
return rv;

toto opravdu není nic, co by bylo nějak nepoužívané, nesrozumitelné, a nedělalo se to hlavně i v případě, že potřebuješ uvolnit paměť JAKKOLIV JINAK, ukončit spojení, uzavřít soubory apod. - prostě funkce, které mají jediný return a ne padesát, jsou mezi programátory dlouhodobě pokládané za vcelku dobrý nápad, není to z mé hlavy.

XCHAOS: takže si dobře rozmysli, který design pattern nese větší rizika čeho, než některý zatratíš... - takze memory leaky jsou pro tebe "design pattern"? HAHAHAHAHAHAHAHA. Takze je v poradku ze tvuj "alokator" zacne leakovat pamet na vsechny strany, jen co se do nej opre lehky vanek (treba return uprostred funkce), protoze je prece "design pattern" ze se program pro jistotu kazdejch pet minut restartuje a je to prece lepsi nez segfault? HAHAHAHAHAHA.

XCHAOS: v dokumentaci bude tedy [...] zmíněná i nevhodnost použití returnu z funkce. - HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA. Proboha. Tebe bych si fakt nedokazal ani vymyslet.

Hele, co na tohle rict. Snad jen ze opravdu urpimne obdivuju zarputilost, s jakou dokazes navzdory vsem argumentum proti hajit i tu nejvetsi pitomost, jen proto ze to je tvuj oblibeny projekt a nedovolis aby ti ho nekdo rozbil, obzvlast ten zlej redguy. Ale tohle uz je fakt hodne, hodne, hodne zly. "return se nedoporucuje pouzivat"... to ze "nedoporucuje" je eufemismus pro "kdyz to udelate, pravedpodobne vam to bude brutalne leakovat" je ten nejmensim problem 8)

Ale mam pro tebe dobrou zpravu: existuje cesta z tohohle pruseru, nezarhnujici podobny idiotsky omezeni v dokumentaci. Sice neni moc elegantni, ale fungovalo by to (resp. resilo by to tenhle problem, mozna (skoro urcite) by to melo jiny potize plynouci z designu tveho bastlu). Schvalne jestli na to prijdes 8)

Why Johnny Can't Code and How That Can Change - Slashdot
http://developers.slashdot.org/story/11/06/23/1422224/Why-Johnny-Cant-Code-and-How-That-Can-Change

REDGUY: v C se dostaneš do nekonzistentního stavu i spoustou jiných způsobů. chápu, že tě baví upozorňovat, že do lodi teče - ale to co vyvíjím já, je spíš takový vor: vor může mít díry a stejně do něj neteče.

pro začátek si ujasni, co reálně vadí víc:
- memory leaking (v C opravdu ČASTÁ chyba, přiznejme si to - i bez mých nápadů) nebo
- přístup k již dealokované paměti ?

memory leaks jsou tak častá chyba, že třeba i server Apache se pro jistotu po (konfigurovatelném) množství přístupů zrestartuje, aby uvolnil paměť. je to jeho normální činnost: neohrožuje to stabilitu, nic. jen to šetří resourcy systému.

naproti tomu přístup k dealokované paměti znamená segfault.

takže si dobře rozmysli, který design pattern nese větší rizika čeho, než některý zatratíš...

REDGUY: mno. hmm. teď si fakt našel výrazně lepší protipříklad, než ty předchozí :-) tedy ne, že by return z funkcí z míst, kde si na konvenčně alokovanou paměť nezavolal free(), způsobil cokoliv jiného - ale budiž.

gratuluju - v dokumentaci bude tedy kromě nekompatibility z goto a setjmp/longjmp tedy zmíněná i nevhodnost použití returnu z funkce.

(víš, oni někteří hnidopichové se dokonce domnívají, že by funkce měly pokud možno mít jen jediný return na konci - a uvnitř by měly být normálně strukturované na cykly a podmínky a max. nastavovat návratovou hodnotu... ale já se přiznám, že to hodil za hlavu a neřešil, proč by to tak mělo být... zajímavé)

XCHAOS: oznamenat, že pokud všechny pointery alokované uvnitř forget { } také DEKLARUJEŠ uvnitř toho scope (což je hezká vlastnost C - že v jakémkoliv scope můžeš deklarovat další lokální proměnné), tak že se nemůže stát, že bys na tu dealokovanou paměť přistupoval za koncem scope? - coze? Nerozumim. Tohle je podle tebe reseni toho problemu se setjmp/longjmp? Tam nejde o _pristup_ k te pameti, tam jde o to, ze longjmp te dostane z jednoho kontextoveho bloku do druheho aniz by si toho tvuj bastl vsiml a tim se dostanes do nekonzistetniho stavu.

Hele, xchaosi, sice mam jen velmi mlhavou predstavu o tom, jak to budes implementovat (a neco mi rika ze ty taky), ale jen tak cvicne, predstav si tohle:

char * foo(void) {
  forget {
    GET_MEMORY;
    remember {
      GET_MEMORY;
      forget {
        GET_MEMORY;
        remember {
          GET_MEMORY;
          return stuff;
        }
      }
    }
  }
}

Jakym zpusobem se uvolni pamet v tech dvou forget blocich? Jestli forget/remember jsou jen nejaky wrappery kolem for, tak ten return je zcela odignoruje a proste se vrati, bez nejakyho uklidu. Nebo mi neco unika?

ISTEVE: jo, no tak samozřejmě :-) záložky v některý IRC klientech byly fakt zmatená věc, snadno se to pastlo do jiného okna...

a v té době byl lamer taky ještě celkem underground, že jo :-)

REDGUY: ve skutečnosti - unixové manuálové stránky k C knihovním funkcím jsou plné poznámek o různých kompatibilitách a nekompatibilitách.

ano, našel si hrozivý příklad na možný memoryleak - v prostředí, kde i bez mých nápadů je leakování paměti tak jako tak jedna z nejčastějších chyb. gratuluju.

ale co takhle poznamenat, že pokud všechny pointery alokované uvnitř forget { } také DEKLARUJEŠ uvnitř toho scope (což je hezká vlastnost C - že v jakémkoliv scope můžeš deklarovat další lokální proměnné), tak že se nemůže stát, že bys na tu dealokovanou paměť přistupoval za koncem scope? já vím, detail. něco takového vymýšlí hloupí estéti, překlepávající se na numerické klávesnici. chytrého matematika by ani nenapadlo, že by mohl udělat chybu - a tak ani nenavrhuje takový styl programování, který by umožňoval chybám předcházet....

XCHAOS: ...nebo jako heslo na router :]

REDGUY: je to duplicitní - první dvě zmínky byly vtipný, ale překlep na numerické klávesnici není vtipný donekonečna -není to tak vtipné jako to "vzrušování" na qwerty klávesnici, které bodovalo na lamerovi....

ISTEVE: jinak ten test na jednom místě nahlas předpokládá, že velikost pointeru i intu je 2 a zmiňuje to - ale na dřívějším místě to předpokládá tiše, což mi celkem i zmátlo. test je dobrý a podle mě málokdo tady udělá všech 16 bodů - některé otázky jsou easy, ale je tam pár chytáků (hlavně ty vícerozměrný pole) a pár jsem vzdal rovnou.

akorát bych do prvního odstavce dal že se předpokládají dvoubajtové inty i pointery (místo aby se to na jednom místě zamlčelo a na druhém uvedlo explicitně)

ISTEVE:
_BENNY: kurňa, tohle je fakt zákon schválnosti :-( test počítá se sizeof(int)=2, tak jsem chtěl podotknout, že to pamatuju, a debilně jsem se uklepl.

ale konekonců, lepší se asi smát překlepu, než když někdo něco neví

XCHAOS: ale fakt dobrej. licha velikost slova, to snad nemely ani rusky pocitace :D

_BENNY: ty jo, neviděl si nikdy numerickou klávesnici ? prostě překlep, no

jinak moje starší představa exception handlingu je zde - dokonce si přeloží
https://dev.arachne.cz/svn/cll1h/browser/branches/fork-0.7/demos/exceptions/failures.c

ale dnes už to ve skutečnosti mám vymyšlené poněkud jinak - hlavně bude existovat nějaký seznam nahromaděných vyjímek, a "except" odebere vždy poslední požadovanou vyjímku z toho seznamu

(vyjímky nebudou hierarchicky uspořádané, ovšem budou asi nějak kategorizované, a víceméně půjde o zalogování všech POSIXových errno/errstr/doplňujících hlášek po cestě ... nějak bych chtěl vyřešit, aby když se třeba postupně nepodaří otevřít tři soubory a vyjímky budou sice odchycené, ale pak nebudou nija ošetřené - tak aby nějaký except na nejvyšší úrovni vždy mohl vypsal všechny "nahromaděné" neošetřené vyjímky... jakási interní errorlog... vychází mi to na except() {} a except_all() {} - přičemž except by vyjmulo ze seznamu chyb poslední vyjímku daného typu a except_all by iterovalo přes všechny nahromaděné chyby... )