• ú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 --- ---
    DAVIDOWITCH: nic jako Maruška neexistuje, především :-) je to nějaký vás výsměšný pojem, kterým maskujete, že jste v podstatě ani vy nedostali nápad, jak sestavovat binární B+ strom s přiměřenou složitostí - třeba O(n), ale ideálně daleko lepší. v podstatě to tady všichni zahráli do autu, že je to nepodstatné a nudné téma, a že by taková datová struktura stejně byla skoro nanic (což rozhodně není pravda - i když je fakt, že jsem o ní přemýšlel hlavně předtím, než jsem se dozvěděl, že na současných PC architekturách je realloc() zřejmě implementovaný bez nutnosti zdlouhavě kopírovat rozsáhlé bloky paměti - což rozhodně mění situaci, když se bavíme o dynamických datových strukturách)

    a nevím, kdo tu prezentoval, že refcounty jsou zdaleka nejlepší strategie správy paměti, a že C++ je nejlepší prakticky na všechno.... takže jsem bral jako hotovou věc, že je to součástí většiny implementací... ale teď se dovídám, že je na to potřeba použít nějaký rozšiřující toolkit, jinak tam k dispozici nejsou... takže ono to je celé složitější.

    skutečně mi to připomíná situaci v řadě jiných klubů, kde třeba 2-3 roky mluvím o něčem, o čem se v té době běžně nemluví, a ani přesně nevím, jakým buzzwordem to média označí, když o tom mluvit začnou - viz např. "smart grid" v energetice, apod.

    chápu, že ustálené odborné pojmy a "buzzwordy" provařované v médiích jsou něco trochu jiného - ale zrovna "smart pointer" mě přijde spíš jako buzzword, než nějaký ustálený odborný termín - všechny reference na objekt např. v Pythonu jsou tím pádem (nejspíš) "smart pointery" - ale určitě tomu tak nikdo nebude říkat - jsou to prostě reference na objekt a tečka, že jo.
    DAVIDOWITCH
    DAVIDOWITCH --- ---
    XCHAOS: No, hmm.. ja bych ti to s tim upresnenim terminu a tak veril, ale to bys nesmel po dvojim upozorneni ze nemas pravdu a pletes dve veci dohromady potreti trvat na tom, ze refcounty potrebujou operator =, vis.
    XCHAOS
    XCHAOS --- ---
    REDGUY: ve skutečnosti - chápat nějaký koncept a netušit přesně, jakým pojmem je označován, to podle mě není žádná ostuda.

    a to, že bych nějaký pojem přiřadil chybně, to se zas tak často nestává. (Rozhodně se to nemůže stát někomu, kdo jen trolluje a sám se prezentuje tak, že je především chytřejší než všichni nebo většina ostatních, a tak ani nic přispívat nemusí).

    (nenapadlo tě někdy, že net obecně (a NYX zvláště) používám jako prostředí k ověření svých různých koncepcí a nápadů, či právě k ověření a upřesnění používané terminologie ? hloupý kdo neví, blbější, kdo se nezeptá... a já tedy nikdy nepracoval s internetem tak, jako že publikované příspěvky jsou nějaké zjevené pravdy, ke kterým se už nikdo nesmí vyjadřovat a opravovat ostatní, když se mýlí, nebo tak... právě naopak... pro mě je většina debat otevřených...)
    XCHAOS
    XCHAOS --- ---
    REDGUY: dobrá, byl to 32bitový procesor - ono to je fakt dlouho a já si negooglím všechny detaily předtím, než něco napíšu - jenže zřejmě neměl mechanismy ochrany paměti při multitaskingu, či co - prostě měl kooperativní multitasking, a aplikace musely ze všech smyček volat nějakou službu systému - a hlavně: při práci s většími bloky paměti se snad prý musely volat nějaké funkce pro aktualizaci obsahu bloku v paměti (podobně jako v DOSu).

    prostě navzdory honosnému GUI byly první Macintoshe programátorský prý dost hrozné. Já o tom bližší informace nemám - nikdy jsem pro tu platformu neprogramoval - ale min. ten kooperativní multitasking bývá často zmiňován
    REDGUY
    REDGUY --- ---
    XCHAOS: 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 - mimochodem, ted mi to doslo - na preOSX Macy nejsem ani zdaleka expert, ale pokud mluvis o " 16ti bitovém Mac OS", neni to jen dalsi dukaz ze opet placas o necem cemu nerozumis, protoze uz prvni Macintosh bezel na 68000, tudiz je pitomost mluvit o nem jako o 16bitovem? LOL. Tohle je cim dal tim lepsi 8)
    REDGUY
    REDGUY --- ---
    XCHAOS: ale nechápu, jak bys mohl nějakého programátora donutit dělat to manuálně: vznikaly by v tom obtížně debugovatelné chyby, když by někdo zapoměl ten kód pro snížení nebo zvýšení refcountu připsat, nebo naopak při změně kódu umazat, apod - HAHAHAHAHAHAHAHAHAHAHA. Kdybys nebyl nepoucitelnej trouba odmitajici jakoukoliv dobrou radu, misto HAHAHAHAHAHAHAHAHAHAHA bych ti tady napsal "Podivej se na OSX a iOS, tam presne tohle maji a funguje jim to velmi dobre, diky rozumnemu designu, zahrnujiicimu X, Y a Z." Ale protoze jsi trouba ktery se nepotrubuje koukat na OSX protoze "prece vi jak to fungovalo v původním 16ti bitovém Mac OS", tak si to necham pro sebe 8))
    REDGUY
    REDGUY --- ---
    XCHAOS: takže kde je celou dobu problém ? - v tom ze, jak se prave ukazalo, XChaos _zase_ nevi jak se rika ruznym vecem a vymysli si vlastni terminologii - a aby to bylo zabavnejsi, tak nevymysli vlastni slova, ale svym predstavam nahodne prirazuje existujici terminy ktere zahledl z rychliku a pak se divi, ze mu nikdo nerozumi.

    Cili, normalni situace ve vetsine klubech kam prispivas 8)
    REDGUY
    REDGUY --- ---
    XCHAOS: Objektive C ovšem není C/C99, takže celé je to dost mimo mísu. - ale houbelec. Jasne jsem v te zprave psal, ze rozdily mezi O-C a C/99 se netykaji toho jak tam funguje refcount a ze to co podle tebe brani pouziti refcountu v C/99 plati na O-C taky - a presto tam funguje. Ze ty jsi ji necetl a tvoje neustale obvinovani ostatnich ze "nectou tvoje zpravy" je jen projekce vlastniho problemu? 8)

    Refcounty nejsou záležitost alokátoru, ale operátoru přiřazení - HAHAHA.

    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" - Chapu spravne ze rikas "Nemusim se koukat jak funguje alokace v OSX, protoze si myslim ze vim jak fungovala pred dvaceti lety v sestnatibitovem pra-MacOSu"? ROFL. Krapet podcenujes vyvoj JabkOSU 8)

    Jednou za cas jsem konstruktivni a dam ti dobrou radu, podivat se jak lidi co tomu fakt rozumej resi problemy ktery se snazis resit ty a pro tebe je to skoro urazka? No, dost to o tobe vypovida.
    REDGUY
    REDGUY --- ---
    XCHAOS: myslím, že ani nemáš moc představu, jaký design jsem zahodil a jaký chystám - mam velmi dobrou predstavu co jsi zahodil pokud je to to, o cem jsme se tady pred par rokama hadali. Jasne si pamatuju ty bugy co jsem ti v tom onehda nasel 8) A pokud jsi od te doby vymyslel a zahodil jeste neco jineho? Bah.
    A co chystas? Ano, to nevim. Uz dvakrat jsem se te na to ptal a vypadlo z tebe cosi velmi, velmi neurciteho. Proto mi nezbyva nez extrapolovat na zaklade minulosti. Samozrejme, budu velmi rad kdyz nam tvuj novy vynalez podrobne vysvetlis. Takze?
    DAVIDOWITCH
    DAVIDOWITCH --- ---
    XCHAOS: Hele, mne je to relativne burta, mne zaujalo prohlaseni ze Ccko neumi refcounty, a pak teda to ze si evidentne pod refcountama predstavujes neco jinyho nez ja. Shodli sme se, doufam, ze Ccko refcounty umi, akorat zpusobem kterej tobe prijde nanic (manualne). Jestli to budes zkouset osrat nejakou makro magii tak have fun, ale dokud z tebe nevypadne alespon alfa verze nejaky specifikace, tak se o tom nebudu bavit. Debata o Marusce mne zcela vycerpala.
    XCHAOS
    XCHAOS --- ---
    DAVIDOWITCH: no a tady se dobíráme k tomu, že o co se snažím, je naučit C něco, co "nemá v základních knihovnách".

    jako to dělá boost pro C++, JQuery pro JavaScript, apod. - nic nového pod sluncem.

    jeden takový pokus pro C byla knihovna Glib (nezaměňovat s libc / glibc). mě osobně ten pokus přišel zmatený a nedotažený.
    DAVIDOWITCH
    DAVIDOWITCH --- ---
    XCHAOS: No, nevypadalo to tak.

    C++ to umi, jen proste nema smartpointery v zakladnich knihovnach. Casto se pouziva boost.
    XCHAOS
    XCHAOS --- ---
    DAVIDOWITCH: no ano, já vím co je to refcount.

    ale nechápu, jak bys mohl nějakého programátora donutit dělat to manuálně: vznikaly by v tom obtížně debugovatelné chyby, když by někdo zapoměl ten kód pro snížení nebo zvýšení refcountu připsat, nebo naopak při změně kódu umazat, apod.

    a překvapuje mi, že C++ neumí samo počítat reference na objekty: tím v mých očích zase mizí jedna ze (zjevně domělých) předností... jak říkám, C++ pořádně neovládám, tak mu možná přisuzuju nějaké mýtické vlastnosti, které vůbec nemá
    DAVIDOWITCH
    DAVIDOWITCH --- ---
    Podivej, refcounting je proste technika kde si nejak pocitas reference a kdyz dojdou na 0, tak ten objekt na kterej to pocitas smazes. Jestli se to dela manualne nebo automaticky je naprosto nerelevantni. Ja sem mel z tve poznamky pocit, ze nejak nejde udelat to smazani (nevim proc, proto sem se ptal).
    A jako priklad knihovny, ktera pouziva manualni pristup jsem daval COM, ktery opravdu ma AddRef a Release metody, ktere se daji explicitne volat. Pochopitelne, pro implementaci single threaded aplikace to neni az tak uzitecny, ale to neznamena, ze to "nejde".

    To co myslis ty, ze se to pocita automaticky, je typicka implementace neceho cemu se rika smart pointer. Ty pak, v typicky implementaci, pocitaj reference za tebe a na konci to smazou za tebe. (A to logicky v C++ nejde, o tom se nikdo nebavi).
    XCHAOS
    XCHAOS --- ---
    DAVIDOWITCH: mno, trochu jinak. volání destrukturu na konci scope je asi nedorozumění - bavíme se o snížení počtu referencí, když na objekt odkazovalal lokální proměnná v nějakém scope, která na jeho konci zaniká...

    protože v C se na konci obyčejného scope nic zvláštního nestane, tak prostě nemáš možnost to počítadlo odkazů nějak "vyčistit", aktualizovat. (leda by to fungovalo tak, že s refcountem se pracuje vždy jen v aktuálním scope, ale to se mi nezdá, to by mohlo vést k ignorování některých sofistikovaněji vytvořeých referencí...)

    (samozřejmě v mých speciálních scopech remember {} a forget {} se na konci cosi stane, ale to je už úplně něco jiného... stejně jako COM je něco jiného, apod.)
    DAVIDOWITCH
    DAVIDOWITCH --- ---
    XCHAOS: A to proto, ze ty sis myslel, a evidentne porad myslis, ze refcounty jsou to, cemu cely non-xchaos svet rika smartpointery a tudiz potrebujou pretizeny = a volani destruktoru na konci scope. A jelikoz pres nekolikere upozorneni ze to tak neni sme se nikam nepohnuli, nema "debata" zadny smysl.
    XCHAOS
    XCHAOS --- ---
    DAVIDOWITCH: ale vždyť o smartpointerech si tady začal mluvit až ty :)
    DAVIDOWITCH
    DAVIDOWITCH --- ---
    XCHAOS: No, ja se dozvedel ze nerozlisujes refcounty a smartpointery, coz mne na zacatku nenapadlo a tak sem byl zvedavej kde je problem s refcountama. That's all.
    XCHAOS
    XCHAOS --- ---
    DAVIDOWITCH: no ale o tom celou dobu mluvím... že abys mohl mít v C refcounty, tak se musíš vzdát něčeho tak zásadního, jako je operátor = ... zatím mě nikdo nepřesvědčil o opaku.

    takže kde je celou dobu problém ? k čemu posledních asi 10 příspěvků ? co nového se kdo dozvěděl ? flamewar pro flamewar ?
    DAVIDOWITCH
    DAVIDOWITCH --- ---
    XCHAOS: Protoze to ma funkcni refcounty, aniz by to pouzivalo operator=
    S rozumnym pouzim atd.
    Ale ok, takze to uzavrem na tom, ze "v Ccku nejde delat refcounty" znamena "Ccko neumi smartpointery, akorat nemam poneti jak se co jmenuje".
    XCHAOS
    XCHAOS --- ---
    DAVIDOWITCH: já COM neodsuzuju, akorát prostě nevím, proč to taháš sem: jako _nativní_ princip správy paměti v nativní C aplikaci pro POSIXový systém to použitelné není.

    v POSIXu se obecně na sdílení paměti ("objektů") mezi procesy (nikoliv mezi vlákny procseu) používá mechanismus sdílené paměti (shmget(), mmap()). je to jistě taky zajímavé téma - ale pro běžnou správu paměti v rámci jednoho procesu asi budeš chtít použít něco sice méně robustního a univerzálního - ale zato výrazně svižnějšího.
    DAVIDOWITCH
    DAVIDOWITCH --- ---
    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.
    XCHAOS
    XCHAOS --- ---
    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é ?
    XCHAOS
    XCHAOS --- ---
    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)
    DAVIDOWITCH
    DAVIDOWITCH --- ---
    XCHAOS: Tak znova.. refcounty *NEJSOU* zalezitosti operatoru prirazeni. Jasne sme ti to rekli DVA, mne si za to dokonce podekoval.
    XCHAOS
    XCHAOS --- ---
    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...)
    DAVIDOWITCH
    DAVIDOWITCH --- ---
    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.
    XCHAOS
    XCHAOS --- ---
    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...)
    XCHAOS
    XCHAOS --- ---
    DAVIDOWITCH: děkuji, takhle nějak jsem si to představoval
    REDGUY
    REDGUY --- ---
    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)
    Kliknutím sem můžete změnit nastavení reklam