XCHAOS: tak o vzájemné interakci přemýšlet FAKT nemusíš: buď si to alokoval jedním způsobem, nebo druhým - Takze budu mi pro alokaci pameti dva ruzne, nezavisle systemy? To ti prijde prakticke? U kazde funkce si pamatovat, jakym zpusovem alokovala pamet na vysledky co vraci? A co kdyz zmenim implementaci funkce, takze misto forget/remember bude muset pouzit malloc? Budu muset prepsat vsechny mista v kodu kde se ta funkce pouziva a kdyz na jedno misto zapomenu, tak se to rozbije? To ti opravdu prijde prakticke a pouzitelne v jakemkoliv netrivialnim projektu?

Nebo ještě pro upřesnění: smart pointer si představuji jako speciální objekt, jehož destruktor obsahuje volání metody odkazovaného objektu pro snížení počtu evidovaných referencí (a případně - diskutabilně - i volání nějakého pokusu o provedení správy paměti - možná podle velikosti objektu který byl uvolněn, nebo v závislosti na tom, jestli ten počet referencí klesl na 0, apod.)

To je všechno fajn - ale chápeš, že ve většině ostatních jazyků kromě C++, které použijí refcounty, toto bude přímo nativní forma implementace VŠECH referencí na VŠECHNY třídy objektů: tedy, je to jakási dost C++ specifická berlička, o které uživatelé většiny vyšších jazyků prostě netuší, že to jejich jazyk má pod kapotou - zatímco u C++ si můžeš vybrat, jestli to pod tu kapotu namontuješ, nebo ne.

DAVIDOWITCH: ale já jsem nemyslel smart pointery :-) mimo C++ se prakticky nevyskytují a tohle není klub o C++

a z toho, co jste mě o tom donutili si nastudovat, jsem přesvědčený, že automatické udržování počtu referencí na objekt je něco jiného, než smart pointery.

A kratsi to rozhodne mohlo bejt. Stacilo "aha, jasny, myslel sem smart pointery, ne refcounty." A ne se hadat.

XCHAOS: Ja neprogramuju akademicky. Ja delam doktorat. To je dost rozdil (typicky se lisi v tom jestli se bavim s panem ucitelem, nebo s researchem NVIDIA). Kazdopadne, ja sem ti navrhl upresneni terminologie. Rekl sem ti, nekolikrat, ze reference counting je jen a pouze pocitani referenci jakkoliv, a ze automaticke pak maji smartpointery. A pokazde sem se dozvedel ze nemam pravdu. Tak co bys chtel priste navrhovat jako upresneni? Nejakou uplne specialni terminologii, abychom uzavreli ferovy kompromis, kdyz jednoznacne nemas pravdu?

DAVIDOWITCH: tak ano, bude to "manuální escape analysis" - přímo během psaní kódu :-) já si vůbec nehraju na automatickou garbage collection :-)

XCHAOS: Ale ta konverze bude manualni, ne automaticka (prekladacem, memory alokatorem), right?

XCHAOS: No, takhle. Nevim kde pracujes. Tam kde ja (nemecka uni, delam doktorat) je technika hodne moc o "hrani si se slovicky". Protoze pokud se pouziva zavedenej termin spatne, nadela to spoustu paseky. Pouzivat refcount pro smartpointery je ten lepsi pripad. Protoze, v mem oboru, je napriklad opravdu velkej rozdil mezi stochastic progressive photon mapping a probabilistic progressive photon mapping. Prestoze to je v anglictine skoro synonymum.

A protoze ty tuhle naprosto zasadni zasadu v odbornem klubu (ac svem) neuznavas a kdyz se nekdo zdesi ze pouzivas termin blbe, tak se zacnes hadat, tak si myslim ze ten flamewar za to stal. Byls umlacen k tomu, abys uznal ze refcount je neco jinyho a ze to co chces ty je automaticky reference counting. (A tady zase ustoupim ja, nemusi to bejt nezbytne smart pointer, muzes mit reference treba na disky, a kdyz uz ho nikdo nepotrebuje, tak ho zacnes zalohovat nebo co ja vim.)

DAVIDOWITCH: tedy, víceméně je to to, co jsem tvrdil na začátku, akorát si hrajeme se slovíčky: každý jazyk, ve kterém lze implementovat Turingův stroj samozřejmě umí VŠECHNO co ostatní jazyky, ano :-) akorát se tedy shodneme, že "C nemá nativní podporu pro refcounty", ok ?

bylo kvůli tomu nutné napsat 50 příspěvků flamwar ?

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

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

JACHYMKO: ano... ale definici dle wiki, tedy "automatic memory management" to potom nesplňuje :-)

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

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.