• úvod
  • témata
  • události
  • tržiště
  • diskuze
  • nástěnka
  • přihlásit
    registrace
    ztracené heslo?
    XCHAOSANSI C/C99 (specifikace), GNU C (gcc, glibc), Tiny C (tcc) a POSIX - ne nutně C++,g++,libstdc++ nebo Win32 API
    XCHAOS
    XCHAOS --- ---
    REDGUY: tak o vzájemné interakci přemýšlet FAKT nemusíš: buď si to alokoval jedním způsobem, nebo druhým

    musíš jen přemýšlet, jestli to za tebe někdo řeší, nebo ne - což ale není o tolik horší situace, než když musíš přemýšlet o všech pointerech: takhle ti zbudou jen jeden-dva speciální případy pointerů, u kterých si musíš pamatovat, že je musíš ručně uvolnit - a ostatní můžeš pustit z hlavy. to mi nepřijde jako že jsi na tom "hůř".

    (a rozhodně si na tom líp, než u té "manuální automatické správy", kdy si po každém přiřazení nové reference musíš ručně udělat další čárku na účet a jinde pak zase musíš ty čárky ručně škrtnout - aby bylo vidět, že už je účet zaplacený :-)
    XCHAOS
    XCHAOS --- ---
    REDGUY: mno taky otázka je, jak moc "automaticky" - zda se ten seznam počítadel prochází při každé alokaci dalšího objektu, nebo jak...

    každopádně z mého hlediska se to označení "automatické" fakt vztahuje na automatické udržování toho počítadla - a jako takové to pokládám za relativně dobrou, i když v případě existence velkého počtu objektů ne nutně extra výkonnou strategii.

    manuálně udržované refcounty budou jistě perfektně fungovat do doby, než programátor někam zapomene nakopírovat to volání inkrementace či dekrementace counteru :-)

    a pořád si myslím, že může nastat situace, kdy hlídat ten počet odkazů manuálně bude přinejmenším nepraktické (co když v nějakém výrazu vznikne objekt odkazující na jiný objekt ?). ale ok, pokud je tedy zvyk, že se tomu tak říká i v případě, že se "automatická" správa paměti používá manuálně, tak jsem fakt asi "prohrál".... každopádně tato "manuální automatická správa paměti" asi zůstane na okraji mého zájmu, co se týče metod správy paměti, bohužel.

    (ale pokud se tady někdo učí programovat v C, kdo sleduje tenhle klub, tak ho jistě potěší, že by tedy po každém vytvoření odkazu na alokovanou paměť měl cosi někde volat, a a pak by místo free(..) měl volat zase cosi jiného... a celé by to pak fungovalo "automaticky"...)
    REDGUY
    REDGUY --- ---
    XCHAOS: no... v takovém případě jsi na tom úplně stejně, jako kdybys ty moje makra neměl - to neni pravda, jsem na tom _hur_, protoze musim kombinovat dva ruzne systemy alokace pameti (malloc/free a tvuj bastl), musim premyslet o jejich vzajemne interakci, zvazovat kdy mam kterej pouzit, v pripade ze nekde budu delat vetsi modifikace kodu hlidat jestli nahodou nemusim prepsat alokaci pameti siroko daleko kvuli zmene logiky - proste vic prace a mnohem vic sanci k chybam.

    zavoláš free() na všechno kromě toho - ty jednotlive kousky pameti se stejne budou za oponou alokovat pres malloc? A stejne tak jednotlive uvolnovat?


    V cem konkretne si myslis, ze je zasadni vyhoda tveho systemu?
    XCHAOS
    XCHAOS --- ---
    JACHYMKO: ano... ale definici dle wiki, tedy "automatic memory management" to potom nesplňuje :-)
    XCHAOS
    XCHAOS --- ---
    REDGUY: no... v takovém případě jsi na tom úplně stejně, jako kdybys ty moje makra neměl :-)

    ale je to pochopitelně dobrý příklad: máš v podstatě dvě možnosti: buď na konci explicitně zahodíš všechny dílčí kusy paměti, co potřebuješ zahodit (tedy: zavoláš free() na všechno kromě toho, co si chceš zapamatovat - tím pádem si ale musíš pamatovat nějaký "seznam všeho, co chceš zapomenout" a nakonci ještě i zahodit tento seznam!) - a nebo můžeš vysloveně okopírovat konkrétní výsledek do jiného memory poolu, který nezahodíš.

    myslím, že se shodneme, že v případě, že zapamatovaný objekt má třeba řádově 10 bajtů a ty ho vybíráš z nějaké dočasné datové struktury o deseti tisíc položkách, tak je "moje strategie" v podstatě výhodná. A naopak - pokud jde o objekt velikosti řádu kilobajtů, a vybíráš ho třeba z deseti položek: tak je ovšem zavolání dealokace deseti položek zřejmě efektivnější, než kopírování kilobajtového objektu do jiného kontextu.

    vymyslet opravdu univerzální řešení podle mě fakt nejde: vždy najdeš nějaký protipříklad, v rámci kterého ta která strategie bude pomalá/neefektivní.

    já jsem uvažoval k tomu svému get(...) udělat ještě alternativu the(...), což by byl v podstatě malloc ("v podstatě" říkám proto, že tam mám nějaké syntaktické vychytávky okolo, které samotný malloc() nemá... ale v podstatě by se na pointery vzniklé pomocí the(....) volalo normálně free(...) - to už ani nemá smysl přejmenovávat :-) a pouze pointery vzniklé pomocí get(...) by se uvolňovaly tím remember/forget mechanismem.

    jako jo - je to asi krkolomné - ale všechno ostatní mě přijde taky krkolomné...
    REDGUY
    REDGUY --- ---
    XCHAOS: Ale prdlajs. To "automatic" se vztahuje na to, ze pamet je automaticky uvolnena kdyz refcount dojede na nulu, ne na to jestli refcount udrzujes automaticky nebo manualne.

    A uz po nekolikate: podivej se na iOS. Tam perfektne funguje to, o cem tvrdis ze neni mozne, memory management zalozeny na manualne udrzovanych refcountech.
    DAVIDOWITCH
    DAVIDOWITCH --- ---
    XCHAOS: Jop, neda se docilit toho, aby se refcount pouzival automaticky. Ccko neumi pouzivat automaticky refcount (respektive, ne defaultne, je nejakej gcc hack co se pouziva tusim na FF kterej nejakou takovou magii dela na urovni prekladu, ale to neni dobrej argument). Neznamena to ze jazyk neumim refcount. Aby neumel refcount, tak by musel mit nejakej zasadni problem s tim ze objekt maze nekdo jinej nez jeho tvurce, nebo tak neco.

    A s tim "syntax sugar" si ted vesmes prohlasil, ze kdo nema garbage collection, neumi refcounty? Chapu to dobre?
    XCHAOS
    XCHAOS --- ---
    Garbage collection (computer science) - Wikipedia, the free encyclopedia
    http://en.wikipedia.org/wiki/Garbage_collection_%28computer_science%29#Reference_counting
    Reference counting is a form of automatic memory management where each object has a count of the number of references to it....

    ... tedy není to "manual memory management", kde by se programátor podíval na nějaký výraz, a zamyslel se nad tím, kterým objektům vzniklým v rámci toho výrazu se asi tak zvýšil počet referencí a pak ručně zavolal nějakou metodu co ten počet zvyšuje. fakt ne.

    (nápověda: na objekt vzniklý v rámci vyhodnocení nějakého výrazu do té doby mohlo odkazovat právě 0 referencí, a přirazením vznikla právě první reference: jak asi v takovém případě reference counting provedete manuálně ? opravdu je "syntaktický cukr" když ten jazyk za vás sám udělá něco, co ani ručně udělat nelze ? :-)
    REDGUY
    REDGUY --- ---
    XCHAOS: Prima. A ted mi prosim vysvetli, jak budes resit nasledujici situaci:

    - funkce postupne buduje nejakou velkou strukturu (pocita, cte z disku, neco takoveho)
    - v okamziku kdy je struktura hotova se vyhodnoti nejaka podminka X, kterou lze spocitat az v okamziku, kdy je hotova cela struktura, ne drive.
    - pokud plati X, vratim vytvorenou strukturu, pokud X neplati, vratim neco jineho (null, jinou strukturu, tak neco)
    XCHAOS
    XCHAOS --- ---
    REDGUY: no vidíš, že se dokážeme konstruktivně bavit a nemusíme si jen nadávat...

    je to prosté, milý Watsone: samotné volání té funkce bylo přece uvnitř nějaké jiné struktury remember { } nebo forget { } - remember prostě jen vloží data "o úroveň výše", forget naopak založí nový, "zahoditelný" kontext. resp. nejvyšší úroveň programu (funkce main(), resp. v terminologii mých syntakticky přeslazených maker makro program { }) je pak logicky ekvivalentní jednom velkému forget{ } (tedy na začátku programu máš k dispozici základní kontext paměti, která se na konci zahodí)

    doufám teď už tušíš, o čem jsem mluvil, když jsem říkal, že "pojmenované paměťové kontexty" by byly něco jako "goto" :-) nic proti ním - ať si někdo používá pojmenované memory pooly, pokud chce - ale mě se to líbí takhle anonymně.

    ve většině případů dočasné pomocné proměnné, do kterých budeš cpát ta "zapomenutelná" data, budeš deklarovat až uvnitř daného jednoprůchodového scope - tedy bude to slušně bezpečné. ale samozřejmě - budeš to moci udělat tak, že budeš mít pořád deklarovaný pointer, který bude ukazovat na v tu chvíli uvolněnou paměť. bude ti to dávat prostor k tomu udělat chybu - bude to pořád Céčko, ne nějaký hypotetický super-hyper-bezpečný jazyk, ve kterém by vůbec neměla existovat reference na již (nebo ještě) nealokovaný kus paměti...
    XCHAOS
    XCHAOS --- ---
    DAVIDOWITCH: já sice chápu, že se o tom dá mluvit obecně, a nikdy jsem neříkal, že ne: ale prohlásit o něčem, že "to v daném jazyce lze použít, ale musí se to dělat ručně" je pro mě naprosto ekvivalentní výroku "v tomto jazyce nelze docílit toho, aby se taková věc prováděla automaticky".

    a fakt trvám na tom, že "syntaktický cukr" je název pro případ, kdy napíšeš "něco navíc" - ne pro případ, kdy ti jazyk umožní něco vůbec nenapsat, protože to dělá za tebe.

    např. moje navržená (a jistě diskutabilní) makra remember { } a forget { } (vymezující nějaké hranice toho, jakým způsobem se bude s alokovanou pamětí dále zacházet, navzájem vnořovatelné, apod.) jsou typickým případem "syntaktického cukru" - je to snaha zapsat srozumitelněji a přehledněji něco, co by se jinak muselo zapisovat dost možná nepřehledně a složitě (minimálně tedy v čistém Céčku, při použití malloc() a free()).

    Ovšem za syntaktický cukr prostě nemůžeš označit, když za tebe runtime udělá sám něco, co ty ani v daném jazyce nemůžeš zapsat jinak :-)
    REDGUY
    REDGUY --- ---
    XCHAOS: Aha. Takze v podstate forget prepne do veskere alokace do kontextu ktery se na konci bloku komplete zahodi a remember je prehodi do bloku kterej se nezahodi. je to tak? Takze prvni otazka: zavolal jsem funkci nejakafunkce, dostal jsem vracena data, zpracoval jsem je, nepotrebuju je. Jak uvolnim jimi zabranou pamet?
    REDGUY
    REDGUY --- ---
    XCHAOS:
    NějakýTyp nějakáfunkce(parametry)
    {
        NějakýTyp returnValue;
        forget
        {
            NěcoDočasného tmp=get(...něco...);
            if(neošetřenNějakýZvláštníPřípad(NěcoDočasného))
            {
                return NULL;
            }
    
        remember
        {
            returnValue=get(...něco...);
            returnValue->NějakáPodstruktura=get(...něco...); 
            atd.
        }
        NěcoJinéhoDočasného tmp2=get(...něco...); 
        atd.
        }
        return returnValue;
    }
    
    XCHAOS
    XCHAOS --- ---
    JACHYMKO: hezká anketa, ale případem "syntax sugar" je podle mě myšlený případ, kdy třeba máš víc možností jak něco vyjádřit - ale jedna z nich to má udělat čitelnější: viz http://en.wikipedia.org/wiki/Syntactic_sugar

    (víceméně - z tohoto hlediska se moje snaha vymyslet nějaká předpřipravená makra, typedefy a knihovní funkce, které učiní C srozumitelnější, dá popsat jako snaha vytvořit "přeslazený dialekt" Céčka, který bude tvořený čistě jen syntaktickým cukrem :-)

    jenže pokud jsou reference countery zabudované přímo uvnitř nějakého jazyka, tak o tom nemůžeš mluvit jako o syntaktickém cukru, protože syntaktický cukr není případ,kdy něco vůbec NENAPÍŠEŠ a přesto dosáhneš požadované funkce :-) v nějakém vyšším jazyce bude reference counter zvýšen přímo v případě vzniku nové reference na jakýkoliv objekt, vzniklý v rámci vyhodnocení jakéhokoliv výrazu - a bude snížen vždy na konci scope. A troufám si říct, že alternativa "ručního volání" tam ve vyšším jazyce vůbec nebude (tedy, ve smyslu, alternativa takového ručního volání, které by dávalo smysl a zachovalo funkčnost programu - můžeš si tu metodu zavolat samozřejmě ručně, ale výsledkem bude pravděpodobně nesmysl - protože tam především nebudeš mít možnost, aby si vytvořil referenci bez záznamu o ní...)
    XCHAOS
    XCHAOS --- ---
    (kurňa, mi to spolklo odsazení bloků...)
    XCHAOS
    XCHAOS --- ---
    REDGUY: implementace bude trochu na dýl... v C to bude asi makro, ve kterém bude skrytý jednoprůchodový for() cyklus, který něco udělá před vstupem do scope, něco na jeho konci, že ano. to je k té implementaci asi všechno, kdyby to "něco" bylo úplně triviální, tak už to mám hotové :-)

    popis pro uživatele: dejme tomu, že chceš napsat funkci, která až skončí, tak zahodí veškerou paměť alokovanou na heapu - dejme tomu - kromě datové struktury, na kterou má vrátit odkaz (a tedy i všech dílčích bufferů, na které tato struktura odkazuje - např. dílčí alokované stringy, apod.). pak bych to napsal třeba takhle (NějakýTyp je typu pointer - kdybys tam hledal hvězdičku a get(..) je základní podoba mého alokátoru paměti, který k tomu forget a remember patří):

    NějakýTyp nějakáfunkce(parametry)
    {
    NějakýTyp returnValue;
    forget
    {
    NěcoDočasného tmp=get(...něco...);
    if(neošetřenNějakýZvláštníPřípad(NěcoDočasného))
    {
    return NULL;
    }

    remember
    {
    returnValue=get(...něco...);
    returnValue->NějakáPodstruktura=get(...něco...);
    atd.
    }
    NěcoJinéhoDočasného tmp2=get(...něco...);
    atd.
    }
    return returnValue;
    }

    Popravdě - tenhle případ je hodně obecný a bude popisovat hodně častý případ: v "dřevním C" bys tu paměť vyhradil na úrovni toho scope, který danou funkci volá a předal by si pointer: ovšem pokud by ta funkce ani nedokázala splnit to, co má za úkol, tak by ta funkce třeba byla alokovaná zbytečně - tedy určitě má smysl alokovat paměť pro výsledek toho, co má funkce dělat, až když víme, že to opravdu lze provést. Celkově jsou podobné funkce dnes HODNĚ zavrhované - typicky je příkladem té "dřevní" alokační strategie funkce scanf() - která je dnes už taky mezi C programátory naprosto "deprecated", zavrhovaná.

    moje alokační strategie je prostě jen paralelou situace, kdy na všechny pointery, které nevracíš jako návratovou hodnotu, zavoláš na konci free(): moje makra nebudou řešit nic jiného, než aby se na všechny použité memory pooly to free zavolalo samo (a popravdě - možná dokonce bude pro každý ten "kontext" memory pool jenom jeden a v případě potřeby bude zvětšovaný tím realloc() ... tedy i free() se zavolá pro libovolný počet pointerů jen jednou).

    Dobře - možná je to celé pitomost, ale pojďte se bavit o jiných důvodech, proč je to pitomost, než je ten, že jsem s tím přišel já :-)
    DAVIDOWITCH
    DAVIDOWITCH --- ---
    XCHAOS: No, nemluvi. O pocitani referenci se mluvi jako o mechanismu kterej pocita reference. Ne s ohledem na jazyk, ne s ohledem na pretezovani cehokoliv, dokonce ani ne s ohledem treba na garbage collection a jeho implementaci. Reference counting does exactly what it says on the tin, nekdo nejak pocita kolik existuje na danou vec referenci (a kdyz uz zadna tak ji zahodi). "Pochopitelne" je bohuzel tvoje pochopitelne, ktere neni pochopitelne ani mym, ani zadneho jineho programatora ktereho znam. Vzhledem k tomu ze se nas pohled na takhle zakladni vec takhle zasadne lisi, tak na ten zbytek asi nema smysl reagovat, protoze proste nesouhlasim se zakladni premisou.
    XCHAOS
    XCHAOS --- ---
    DAVIDOWITCH: tak jako sorry, ale tohle je zase flejm pro flejm... úplně zbytečný.

    pochopitelně se o počítadle referencí (reference counter) mluví vždy v souvislosti se syntaktickými konstukcemi jazyka, ve kterém jsou ony reference na cosi vytvářeny a v souvislosti s okolnostma, kdy se tím počítadlo hejbá nahoru nebo dolů - vykládat o tom, že se v tom nemusí mluvit v souvislosti s takovými konstrukcemi, je bohapustý flejm - potom samozřejmě v každém jazyce můžeš použít jakoukoliv konstrukci, a samozřejmě je vymalováno, že jo.

    Pokud jsou počítadla odkazů v C++ v zásadě špatně, pokud nepoužiješ nějaký speciální typ pointerů, u kterého se při opuštění aktuální scope zavolá destruktor, který by stav počítadla snížil - pak sorry, tohle je problém, který si musí C++ programátoři nějak vyřešit sami a mě do toho netahat. v žádném jiném vyšším jazyce se takový pojem pokud vím nepoužívá (protože je to tam jaksi automatické, to snížení toho reference counteru, když reference opustí scope, že ...). (Příkladem jazyků, kde očekávám, že je tohle řešené automaticky, je Python nebo Java - pokud se mýlím, tak mě TEĎ opravte, teď to nebude chytání za slovíčko...)

    O tom je to "ne nutně C++" které je uvedené v názvu - o některých programátorských konstrukcích lze diskutovat, aniž by člověk nutně věděl, jak je to udělané v C++ a jak se tomu tam říká.

    ... a u té složitosti BINÁRNÍHO B+ stromu (diskutovaná datová struktura byla BINÁRNÍ B+ strom, ne obyčejný) šlo o složitost přidávání prvku - ne procházení. procházení musí být pochopitelně logaritmické. A přidávání je jediné, co na té datové struktuře nebylo jasné, a proč jsem se v první řadě chtěl s někým radit (a opět - složité na tom vlastně bylo jen to, že pro to přidávání nechci použít rekurzi...).
    DAVIDOWITCH
    DAVIDOWITCH --- ---
    XCHAOS: A je to tu zase, nemuzu si pomoc. Vsichni na svete rikaj refcounty jen mechanismu ze se pocitaj reference (nejak jakkoliv) a kdyz se dojde na 0, tak se objekt automaticky smaze. A ty, tapajici v terminech a hledajici upresneni, se tu aktivne hadas ze to je blbost a ze se tim mysli vlastne neco jinyho. Nema cenu se s tebou bavit, jakkoliv o cemkoliv, sorry.


    XCHAOS: Ne, tim se (ted sem koukal) maskuje to, ze ty rikas B+ strom necemu, co neni B+ strom a vesmes to tak ani nevypada. Ale usmyslel sis ze to je B+ strom. Redguy zareagoval podobne jako ja na refcounty, at probuh nepouzivas zavedeny terminy pro neco JINYHO nez sou zavedeny a rikas tomu klidne Maruska a ne B+ strom, protoze to B+ strom neni. Refcounty jsou jen veci alokatoru, a B+ strom nema "primerenou slozitost O(N)" protoze by to nebyl B+ strom. Howg.
    REDGUY
    REDGUY --- ---
    A neco trochu konstruktivniho - mas nejaky navrh jak budou fungovat tvuj novy alokator, ten s "remember" a "forget"? Fakt by me zajimalo jak si to predstavujes. Nemusis ukazovat implementaci, staci popis funkce pro uzivatele?
    Kliknutím sem můžete změnit nastavení reklam