XCHAOS: No, treba je to smyslem u objektu sdilenejch mezi vic procesama, kdy bez pocitani referenci proste nevis jestli si posledni a mas to smazat, nebo na to drzi pointer jeste 3 ukazatele na tvym pocitaci a dalsi 2 pres sit. Ale, well, to by sis o tom COMu musel neco precist a ne to smahem odsoudit jako M$ a tudiz irelevantni.

DAVIDOWITCH: ježišmarja, manuálně pochopitelně můžeš dělat cokoliv... ale pokud bys po každém přiřazení musel volat nějakou inkrementující funkci, tak mě to opravdu přijde krajně neintuitivní. natož pak volání těch dekrementujících funkcí na konci scope...

já nevím... ale nebylo náhodou smyslem počítání referencí to, že to ten programovací jazyk dělá sám od sebe, a programátor to nemusí řešit ?

a nevzniká náhodou nová referende na objekt nejčastěji právě když se použije operátor přiřazení výsledku nějaké proměnné ?

DAVIDOWITCH: viz [ XCHAOS @ ANSI C/C99 (specifikace), GNU C (gcc, glibc), Tiny C (tcc) a POSIX - ne nutně C++,g++,libstdc++ nebo Win32 API ] - jde to, ale musel by si zapomenout na rovnítko. a používat místo toho něco, co by s těmi refcounty počítalo.

a stejně bys měl problém se snížením počtu odkazů na konci scope. takže ne - v čistém C to nejde.

refcounty jsou zajímavý trik, nic proti nim - ale je to jedna věc, co jde v C++ nebo vy vyšších jazycích, ale není jednoduše aplikovatelná v čistém C. (to máš stejné, jako že máš nějaké hudební nástroje, na které akord prostě nezahraješ... třeba píšťalu)

XCHAOS: Tak znova.. refcounty *NEJSOU* zalezitosti operatoru prirazeni. Jasne sme ti to rekli DVA, mne si za to dokonce podekoval.

REDGUY: hmm, Objektive C ovšem není C/C99, takže celé je to dost mimo mísu. Refcounty nejsou záležitost alokátoru, ale operátoru přiřazení. v čistém C můžeš použít celou spoustu strategií alokace a garbage collection - jenom ne refcounty

(mohl bys je diskutabilně použít, kdybys úplně zavrhl operátor přiřazení "=" ... a místo toho důsledně volal nějakou přiřazující funkci, inkrementující ten refcount)

jinak ano, moje alokační strategie se už kdysi v DOSu nápadně podobala alokační strategii v původním 16ti bitovém Mac OS (tedy před Mac OS X), sám jsem tady na to odvolával - takže nevím, proč mi najednou povýšeně radíš, ať si to "nastuduju".

(tedy samozřejmě - já na tu alokační strategii tehdy přišel nezávisle a o tom jak byl udělaný starý historický Macintosh jsem se dočetl až později, ale ono je přece o tolik víc cool našprtat se, jak něco dělal někdo přede mnou, než na něco přijít sám od sebe... to je přece trapné, mít nějaké nápady, že ano.. co kdyby se jim náhodou někdo vysmál...)

XCHAOS: Ja popravde moc ne, tvoje primarni odpoved byla totalne z cesty a vesmes mlzici. Mne furt zajima proc si myslis ze to nejde.

XCHAOS: Nevybavuju si ze bych tu kdy videl nejaky "tak takhle sem to ted nahrubo naspecifikoval, co vy na to." Ta vec se neustale menila a litala z jednoho konce na druhy, podle toho s kym a o cem ses zrovna hadal.

REDGUY: myslím, že ani nemáš moc představu, jaký design jsem zahodil a jaký chystám. samozřejmě, že ta diskutovaná datová struktura (která se určitě nejmenuje Maruška, ať už se jmenuje jakkoliv - podle mě je to binární B+ strom) je kompatibilní s jakýmkoliv design-pattern - ať už by šlo o container classes, nebo o cokoliv jiného.

(počítám ses nikdy moc neobtěžoval si nastudovat, o čem vlastně píšu - víceméně se ti daří dělat z lidí blbce i bez toho, aniž by ses jejich názory zabýval - ono toto totiž nepochybně jde, jsou na to osvědčené postupy, a ty jich používáš celou řadu...)

DAVIDOWITCH: děkuji, takhle nějak jsem si to představoval

XCHAOS: Podivej, pokud si myslis ze refcounty v klasickem C nefunguji, mel bys napsat do Applu a vysvetlit jim to. Cely iOS (a OS X do nejake relativne nedavne verze) stoji na refcountovane alokaci pameti a funguje jim to dost dobre. Urcite je pobavi az jim budes vysvetlovat jak to maji rozbity 8)
(Ano, iOS a OSX jsou psane v Objective-C. Nicmene na ten alokator to ma vliv pouze v tom, ze se jeho kod vola jako metoda objektu, ne jako funkce. Pretezovani operatoru tam neni, takze o O-C se da rict to co rikas o C: v čistém C nemůžou být refcounty, pokud použiješ obyčejné přiřazování referencí pomocí = ... protože chování tohoto operátoru neovlivníš.)

A btw, abych si odpracoval dnesni dobry skutek a dal ti moznost naucit se neco uzitecneho: nastuduj si jak v iOSu fungujou memory pooly. To je neco neco zhruba podobneho tvym kontextovym alokatorum, ale, abych se pridrzel sve hudebni analogie, programovali to Beatles, ne Christian Crusaders 8)

DAVIDOWITCH: bavíme se o normě ANSI C89/C99 ?

jestli tyhle normy definují nějaké "smart pointery", tak mi něco uniklo... a notabene COM je speciálně microsoftí věc, že jo...

XCHAOS: to mi prijde jako neco jinyho. To co rikas vylucuje existenci smart pointeru (at uz invazivnich nebo neinvazivnich), ale ref couting je neco jinyho. Teda, smart pointery typicky pouzivaj ref counting, ale treba COM to ma explicitne.

DAVIDOWITCH: v čistém C nemůžou být refcounty, pokud použiješ obyčejné přiřazování referencí pomocí = ... protože chování tohoto operátoru neovlivníš.

uvažoval jsem o nějakém makru např. "a=let(b)", které by jako vedlejší efekt někde evidoval počet referencí na b - ale fakt si to nejde představit (především: reference zaniká na konci scope, v C nemáš nic jako "destruktor", takže prostě... není to uhlídatelné).

fakt - když chci komfortní garbage collection v C, tak je nutné zvolit jiný přístup.

ANT_39: nikdy se to nejmenovalo maruška, především :)

REDGUY: hmm, hezké, že se umíš takhle rozkecat, ale v podstatě nic objevného si nenapsal. víceméně tvrdíš něco ve smyslu: "bez ohledu na to, jakými všemi způsoby se to dá dělat, a bez ohledu na to, kolik z nich já znám nebo si umím představit, jsem si jistý, že xChaos to udělá špatně, ha ha ha"

a dokaž mi, že ne.

XCHAOS: Vysmivam? Tim, ze zminuji marusku, nebo cim?

XCHAOS: tedy chápu to tak, že když to dělám já, je to směšné - a když to dělají ostatní, tak to vydá za článek na Wiki ? Vis, ono kdyz dva delaji "totez", neni to vzdy totez. Jak bych ti to jenom vysvetlil... jo, obrazkama: Kdyz se nekdo rozhodne delat hudbu, dopadne to takhle:



A kdyz se ji rozhodne delat nekdo jinej, dopadne to takhle:



Oboje je, technicky vzato, hudba. Ale presto je rozdil myslim zjevny.
(oukej, priznavam, to prvni jsem neslysel a soudim ciste podle obalky. Pokud se pletu, neni problem dosadit nejakou jinou prisernost, ekvivalentni Cll1 8) )

budou pouze anonymní kontexty remember { } a forget { } - skvele, mas jmena. A ted jeste jak budou fungovat?

ale aspoň to dodržuje ducha strukturovaného programování - co to? Zatimco jine pristupy k alokaci pameti ho nedodrzuji? Nebo jak jsi to myslel?

A ty refcounty by me taky docela zajimaly.

XCHAOS: s urážením tady fakt začal někdo jiný. - dost mozna. Jen mi prislo legracni ze to beres tak osobne, ze ciste fakticke a k predmetu prispevku irelevantni konstatovani "nevim odkud to citujes" je ti dobrou zaminkou k tomu psat cosi o "nedovtipnosti". Prosim, neber to jako stiznost, naopak 8)

XCHAOS: obecné přirovnání programátorů v C++ k leteckým dispečerům (myšlena na velkých mezinárodních letištích) bez další omáčky byste ale snad akceptovat mohli - proc? Protoze si to prejes? Cekas ze neco napises a ostatni to automaticky akceptujou? Obavam se ze tak to nefunguje. Proc zrovna leteckym dispecerum a ne treba architektum? Proc ne Perlisti a Javisti? Co Erlagnovci? Co lidi co pisou Cisco IOS? K jakym povolanim bys prirovnal ty? A vysvetlis mi konecne jak je to s tim vztahem zvidave analyticnosti a kreativnosti k objektovym jazykum, C++, kompilaci a interpretaci?

XCHAOS: Ja prosim ne. Proc tam nemuzou bejt ref county?

REDGUY: no jak vidíš, tak nedávno jsem změnil API ke kontextovému alkátoru :-) vytvářet nějaké pojmenované kontexty, to by bylo takové "goto".

budou pouze anonymní kontexty remember { } a forget { } (vnořovatelné do sebe, pochopitelně) ... a ano, pořád jsem byl líný to naprogramovat. ale aspoň to dodržuje ducha strukturovaného programování (pravda - to refcounty taky, ale proč v čistém C nemůžou být refcounty, to snad všichni chápou...)

REDGUY: s urážením tady fakt začal někdo jiný.