ISTEVE: no ano, ale i spoustu jiných nástrojů musíš používat tak, jak je zdokumentováno a popsáno.

např. začátečníka by asi nenapadlo, že nesmí vrátit pointer na lokální proměnnou funkce:

char *funkce()
{
char s[LEN];
... načtu obsah do s ...
return &s;
}

toto je syntakticky platný kód, který klidně začátečníka napadne udělat. a taky mu musíš vysvětlit, že prostě ne - že tohle nesmí - že lokální proměnné po skončení funkce zaniknout a odkazy na ně budou neplatné.

C je plné takových věcí. já poskytuju nástroj, který ve skutečnosti docela otupuje ostré hrany, které C má i bez něj.

XCHAOS: ono se to ale neposere - skutecne? Tak schvalne, priklad:

void foo(void) {
  forget {
    return;
  }
}

void * bar(void) {
  remember {
    foo();
    x = ALOKUJ_PAMET;
  }
  return x;
}

Samozrejme nemam po ruce implementaci a a asi nikdy mit nebudeme, ale teoreticky, copak se asi tady stane kdyz zavolame bar()?

- v nejakem globalnim stavu se zapamatuje, ze jsme v pamatovaci kontextu.
- zavola se foo
- v nejakem globalnim kontextu se zapamatuje ze jsme v zapominacim kontextu
- vratim se z foo
- naalokuju pamet. Odkud? Ze zapominaciho kontextu, presto ze lexikalne jsem v pamatovacim kontextu.

To je v poradku? Nebo sis predefinoval "neposere"? 8)

REDGUY: ale ta možnost nepovede k jakkoliv čistému a korektnímu kódu. ono se prostě neprogramuje tak, že když se ti program začne větvit, tak že rozkopíruješ nějaké potřebné činnosti na víc míst.... jistě, mohl by sis udělat funkci "dealokuj a uzavři vše"... které ale předáš pět filedescriptorů a deset pointerů ? uvažuj: to, že tak lpíš na možnosti vyskočit z funkce v jejím libovolném bodě, to by nasvědčovalo tomu, že si na žádném opravdu složitém projektu v C ještě nepracoval... je to prostě úplně prázdná výtka.

kontexty nejsou "rozbité" kvůli tomu, že neřeší všechny možné případy - ty se pořád snažíš rozdělit kód na "rozbitý" a "správný" - ale takhle to prostě nefunguje: pomocí tradičních i pomocí mých nástrojů jde psát jak bezchybný, tak více či méně chybný kód. kontexty sice neřeší všechny případy, co mohou nastat - ale řeší část těch, které tradiční styl alokace nutí řešit úplně šíleně krkolomně.

vyčleňování jednotlivých pointerů z kontextu by byla celkem hezká finta - kterou ale prostě dělat nebudu, no... (to už by bylo jako ten ruční reference counting, co tady byl zmiňovaný).

kdyby se tvoje kritika zastavila v nějakém rozumném bodě - protože občas dokážeš přijít s rozumným protipříkladem - tak by nám všem zbylo daleko více volného času. ale ne - ty prostě MUSÍŠ mít poslední slovo. proč proboha ? už takhle ti většina lidí přiznává víc zásluh, než co já vím - třeba mě. tak proč si nedáš pauzu ?

XCHAOS: Blbe jsem se vyjadril -- posere se funkce, kterou to slibuje, ze dela (tedy effortless uvolnovani pameti)

XCHAOS: máš milion jiných případů, kdy prostě return z prostředku funkce neuděláš - prosim, ukaz mi jeden pripad z toho milionu. Bud tak hodny.

ty ovšem neodpovídáš na ŽÁDNÉ otázky (či nereaguješ na podněty), ty jsi fakt o level výše, koukám... - wut? A co asi delam posledni dve hodiny? V linkovanem prispevku neni jedina otazka. Prosim, na kterou tvoji zasadni otazku jsem neodpovedel?

ISTEVE: ono se to ale neposere - ono to jen udělá to samý, jako když zapomeneš na free(). v tom makru nebude schovaná větší věda, než volání jednoho (nebo několika) free().

XCHAOS: kud v normálním C stylu použiješ return před tím, než uvolníš paměť - tak se stane co ? máš alokovanou paměť - ale pointery na ní ti zmizely spolu se scope, který jsi opustil. jsi úplně stejně v pytli. - ano. Kdyz udelam v C chybu, bude to spatne. Sokujici. Ale v normalnim C mam aspon _moznost_ tu pameti uvolnit a udelat return uprosted funkce. V tvem bastlu tuhle moznost nemam a _musim_ organizovat kod tak abych skoncil na konci bloku.

totiž že ve chvíli alokace paměti často nevím, jak dlouho jí budu potřebovat [...] tam si měl pravdu - ale vycouval si, a teď vymýšlíš nesmysly. - wtf? Takze za prve, kde jsem prosim "vycouval" z toho ze kontexty jsou rozbite pokud nevim jak dlouho budu pamet potrebovat? A co presne jsou ty soucasne nesmysly? To ze je blbost zakazovat return uprostred funkce je ted oficialne "nesmysl"?

na nesmyslné protipříklady z dnešního večera už nebudu nijak reagovat - ale prozradím ti, že bych pokládal za užitečné moct individuální pointery buď vyčlenit z kontextu forget { } - a zařadit je do nadřazeného remember { } kontextu - Aha. Takze ty protipriklady jsou "nesmyslne", ale ocividne te dotlacili k rozsireni "designu" o vyclenovani individualnich pointeru, at uz to znamena cokoliv? 8))

prostě tvoje kritika je strašně samoúčelná, protože máš prostě strašně intenzivní nutkání mě kritizovat a to úplně za každou cenu - obdivuju tvoji schopnost autosugesce. 0:01:19 pises ze mam uplnou pravdu, pak naskoci autosugesce a 0:18:39 uz jsou moje protipriklady "nesmyslne", kritika "samoucelna" a zpusobena "intenzivnim nutkanim te kritizovat za kazdou cenu". Jen doporucuju abys ty zpravy kde pises ze mam pravdu nebo ze moje pripominky das do dokumentace radsi smazal, takhle to vypada trochu rozstepene 8)


a nepřináší žádné nové problémy, které by ti nevznikaly úplně běžně i u většiny ostatních programátorských pokusů v C ... - huh? U kterych "ostatních programátorských pokusů v C" nesmis pouzivat return uprostred funkce, protoze jinak ti to zacne leakovat pamet?

REDGUY: k uvolňování paměti uprostřed funkce jen odkážu co jsem už psal:
[ XCHAOS @ ANSI C/C99 (specifikace), GNU C (gcc, glibc), Tiny C (tcc) a POSIX - ne nutně C++,g++,libstdc++ nebo Win32 API ]

máš milion jiných případů, kdy prostě return z prostředku funkce neuděláš - a pokud jsi normální, tak to nepořešíš tak, že nakopíruješ X řádků kódu před tím return doprostřed. prostě to neuděláš. (ale pochopitelně: na nepříjemné výtky tady musím reagovat jen já.. ty máš výsadu mlčení)

já tu _jednou_ použil argument, že snad nemusím odpovídat na všechny otázky - ty ovšem neodpovídáš na ŽÁDNÉ otázky (či nereaguješ na podněty), ty jsi fakt o level výše, koukám...

XCHAOS: Nesouhlasim. Na jedny strane mam pravidlo "Co naalokujes, to uvolnujes". Na druhy strane mam pravidlo "O pamet se starat nemusis, je to pohodlny, akorat se ti to posere kdyz udelas return z funkce pred jejim koncem a nekolik dalsich -- exotictejsich -- veci". To druhy ma podivuhodnejsi a prekvapivejsi vyjimky, predevsim vzhledem k tomu na jakym jazyku stavi.

REDGUY: ... toto je ovšem už neřešitelné, pochopitelně... pokud použiješ flow control makra, musíš počítat s tím, že na ně působí break a continue.

podívej, tobě se prostě od začátku myšlenka flow control maker nelíbí. já sám jsem si díky těm polemikám uvědomil, že jsou tady určité rezervy v té srouzmitelnosti - stejně jako u spousty jiných věcí - ale prostě někomu v C přijdou nesrozumitelné aritmetické operace s pointery na vícerozměrná pole, někomu zase flow control makra a jejich nástroji: nemůžeš jednoznačně říct, že konstrukce zmiňované v http://stevenkobes.com/ctest.html jsou zcela blbuvzdorné a bez rizika - ale zato, že moje flow control makra jsou od základu špatná, protože na ně má vliv break, continue, apod.: blbost.

nechápu, jak v jazyce, který je v podstatě postaven na různých praseckých konstukcích a zkratkách, najednou může přijít s tím, že moje prasení je nějak zásadně horší, než prasení kohokoliv jiného: pokud se ti to nelíbí, nepoužívej to. ale nechápu, jak se to můžeš klasifikovat jako prasečtější, než jiné prasecké konstrukce...

REDGUY: mě ale baví řešit low-level pitomosti. nebaví mi flamewar s trolly, kteří ve chvíli, kdy by normální diskutér po rozumným argumentu aspoň trochu ustoupil a řekl "no ok, tak je to tak nějak napůl, asi", tak prostě úplně obrátí list, a začnou flejmovat o něčem úplně jiném.

to je fakt především úplně chorý přístup k té debatě: občas se trefí jeden, občas druhý, nikdo se nemůže úplně trvale mýlit. a věnovat takové množství času, jako věnuješ ty, abys všechny kolem přesvědčil, že někdo jiný v debatě se ZÁSADNĚ a VE VŠEM mýlí - to je postě fakt trochu psychopatické...

ISTEVE: ... no, a když vyskočíš z funkce a zapomeneš uvolnit paměť, tak je ovšem po determinismu :-)

REDGUY: no podívej... asi takhle... pokud v normálním C stylu použiješ return před tím, než uvolníš paměť - tak se stane co ? máš alokovanou paměť - ale pointery na ní ti zmizely spolu se scope, který jsi opustil. jsi úplně stejně v pytli.

tvoje "nesmíš skákat do jiného kontextu" je úplně bezpředmětné - nejhorší, co ti hrozí, je prostě neuvolnění paměti: je to stejné, jako obejít/vynechat několik příkazů free() - a u složitějšího kódu klidně HODNĚ příkazů free, popravdě.

první příklad - totiž že ve chvíli alokace paměti často nevím, jak dlouho jí budu potřebovat - byl samozřejmě hodně dobrý. toto je velký problém, a kontexty/pooly to neřeší: je to stejné jako s polem - pole je skvělé, pokud "víme, kolik toho bude" a nepotřebujeme dodatečně vkládat náhodně položky na jeho začátek. no a s tímhle je to stejné: kontexty jsou fakt výkonné - kromě případu, že předem nevíš, co s tou pamětí budeš dělat. tam si měl pravdu - ale vycouval si, a teď vymýšlíš nesmysly.

na nesmyslné protipříklady z dnešního večera už nebudu nijak reagovat - ale prozradím ti, že bych pokládal za užitečné moct individuální pointery buď vyčlenit z kontextu forget { } - a zařadit je do nadřazeného remember { } kontextu. jo, bude to mít určitou režii - ale pořád asi menší než fyzické kopírování bajt po bajtu (on totiž ten "kontext" je nakonec stejně jen spojový seznam pointerů na alokované bloky, co jiného...). (samozřejmě problém je v tom, že to jednoduše nejde - nebo ne bez obětování všech výkonnostních výhod memory poolu)

prostě tvoje kritika je strašně samoúčelná, protože máš prostě strašně intenzivní nutkání mě kritizovat a to úplně za každou cenu: je jasný, že můj návrh není zcela univerzální: jenom je vhodný ve slušném počtu počtu případů, které se v "tradičním" C řeší zbytečně pracně. a nepřináší žádné nové problémy, které by ti nevznikaly úplně běžně i u většiny ostatních programátorských pokusů v C ...

Pro mne je v programovani podstatny to, aby dana featura byla jednoznacna. Pokud dana featura "je skvela, ale s podminkama X, Y, Z", pak tu featuru nebudu pouzivat, pac je volaka cudna. Ostatne, to je duvod proc se goto a setjmp() nepouzivaj on daily basis -- jsou to silny nastroje, ktery ovsem maj spoustu bocnich veci ktery si je treba pamatovat.

Jinak receno, ja jsem old-fashioned, ja mam ten determinismus docela rad :)

XCHAOS: aby ta metafora byla fakt presna, znela by "vzdej to, k cemu bude ostatnim lidem pro ktere to pry delas v zahradni sekacce letecky motor?" ;)

A dalsi bizarnost:

for(int i = 0; i<10; i++) {
  forget {
    if (condition) {
      break;
    }
  }
}

Clovek je zvyklej ze break ukoncuje smycku, ze jo? Smula, v tomhle pripade vyskoci z forget, leakne pamet a pusti dalsi iteraci. continue se chova stejne idiotsky, u nej si ale XChaos muze namlouvat jakz-takz pricetne vysvetleni ze to je feature pro predcasny odchot z kontextu. Pro break to ale neplati, ten proste ten kontext rozbije a leakne.

_BENNY: sorry, ale tahle metafora je prostě špatná. C je spíš letecký motor - je složitý na seřízení a opravení apod. - jenže všichni kolem říkají "vzdej to, na co potřebuješ letecký motor - proč ti nestačí sekačka na trávu, jako všem okolo".

ISTEVE: no pochopitelně, pokud před returnem není bambilon řádek nějakého "uklízecího kódu" (ruční dealokace paměti, např. ?), který by musel být před každým returnem, tak pochopitelně není důvod to takhle dělat.

fakt je to tak těžké pochopit, jak to myslím ? id REDGUY má úplně pravdu - až na to, že nenavrhuje žádné alternativní řešení: můj nápad s polo-automatickou správou paměti není geniální, je jenom "hezký" - má spíše estetickou hodnotu, než že by byl nějak objektivně "správný" či "výkonný" nebo tak něco. má samozřejmě svoje vady, ano - jenže se tu zamlčuje ta podstatná část problému: a sice, že alternativní postupy jsou na tom úplně stejně !

je jistě nehezké když nemůžeš kdykoliv "čistě" vyskočit z funkce - jenže ejhle, když máš v té funkci paměť alokovanou klasicky pomocí malloc(), tak jsi na tom úplně stejně - není správné utéct, dokud ji nevrátíš ! takže pointa je, že mnou navrhované řešení není v žádném ohledu horší, než to kanonické. jediná výhoda je prostě ta, že pokud máš 2 a více pointerů, tak je to v mé verzi méně řádek kódu.