Nastal čas na kakao - Kopírování objektů - MujMAC.cz - Apple, Mac OS X, Apple iPod

Odběr fotomagazínu

Fotografický magazín "iZIN IDIF" každý týden ve Vašem e-mailu.
Co nového ve světě fotografie!

 

Zadejte Vaši e-mailovou adresu:

Kamarád fotí rád?

Přihlas ho k odběru fotomagazínu!

 

Zadejte e-mailovou adresu kamaráda:

Soutěž

Sponzorem soutěže je:

IDIF

 

Kde se narodil známý fotograf František Drtikol?

V dnešní soutěži hrajeme o:

Seriály

Více seriálů



Informace

Nastal čas na kakao - Kopírování objektů

3. června 2004, 00.00 | Na náš minulý rozbor toho, jak objekty vznikají a zanikají, je vhodné navázat popisem koncepce měnitelných a neměnných objektů. To proto, že kromě dosud popsaných postupů objekty mohou také vznikat jako kopie objektů dříve existujících – a způsob, jak jsou tyto kopie vytvářeny, je s koncepcí měnitelných a neměnných objektů úzce svázán.

Na náš minulý rozbor toho, jak objekty vznikají a zanikají, je vhodné navázat popisem koncepce měnitelných a neměnných objektů. To proto, že kromě dosud popsaných postupů objekty mohou také vznikat jako kopie objektů dříve existujících – a způsob, jak jsou tyto kopie vytvářeny, je s koncepcí měnitelných a neměnných objektů úzce svázán.

Vlastní kopírování

Ne všechny objekty prostředí Cocoa kopírování podporují: pro některé objekty by to totiž nemělo rozumný smysl – třeba taková instance třídy NSApplication, jež je v každé aplikaci jen jediná a zprostředkuje komunikaci kódu aplikace s operačním systémem: jaký by mělo smysl vytvářet její kopii?

Objective C proto pro kopírování využívá nám již známých protokolů: existuje protokol NSCopying, jemuž odpovídají právě ty třídy, jejichž instance lze kopírovat. Kromě toho existuje protokol NSMutableCopying, jemuž odpovídají právě ty třídy, od jejichž instancí lze vytvářet měnitelné kopie.

Kopii instance vytvoříme obecně tak, že jí pošleme zprávu copy:

NSString *novyString=[existujiciString copy];

Zpráva copy ovšem spolu s kombinací alloc/init patří mezi těch několik málo výjimek, jež sice vytvoří nový objekt, avšak nezařadí jej do správy paměti, takže garbage collector jej automaticky neuvolní.

To je proto, že v praxi zprávu copy daleko nejčastěji užíváme na místě zprávy retain v případech, kdy si chceme uchovat vlastní kopii daného objektu, nadále nezávislou na originálu:

@interface Foo:NSObject {
  NSString *title;
  ...
}
@end
@implementation Foo
...
-(void)setTitle:(NSString*)newTitle {
  [title autorelease];
  title=[newTitle copy];
}
...

Pokud bychom zde použili – podobně jako v příkladu v minulém dílu – "title=[newTitle retain];", vystavovali bychom se nebezpečí, že po chvíli obsah předaného objektu někdo nějak změní; změnil by se tak tedy i náš titulek (neboť s využitím zprávy retain sdílíme týž objekt, který nám odesilatel zprávy předal v parametru newTitle). To patrně nechceme!

(V minulém dílu toto risiko nehrozilo prostě proto, že textový objekt jsme tam nedostali od někoho jiného, ale sami jsme si jej vytvořili. Nebyl tedy sdílený, takže nám jej nikdo jiný změnit nemohl.)

V ostatních případech – pokud vytváříme kopii, již nechceme držet po delší dobu, než po dobu trvání dané metody – ovšem musíme explicitně použít zprávu autorelease:

...
NSArray *a=[[jinePole copy] autorelease];
// nějaké použití 'a'
// dále již 'a' potřebovat nebudu
...

Analogicky jako zpráva copy funguje i zpráva mutableCopy; ta však vždy vytvoří kopii, jejíž obsah můžeme měnit:

...
NSMutableArray *ma=[[pole mutableCopy] autorelease];
[ma addObject:jinyObjekt]; // nemění 'pole', jen mou kopii
...

Měnitelné a neměnné objekty

Základní myšlenkou koncepce měnitelných a neměnných objektů je dosažení vyšší efektivity (nejen, ale především) při kopírování objektů, aniž by se o to programátor musel vědomě starat.

Uvědomme si, že případů, kdy je zapotřebí vytvářet kopie objektů, je mnoho: služby "undo" v grafickém uživatelském rozhraní obvykle využívají kopií; naprosto klasickým případem je jeden z nejužívanějších objektů vůbec – hashovaná tabulka. Ukažme si právě tento případ: hashovaná tabulka v Cocoa samozřejmě je k dispozici, odpovídající třída se jmenuje NSDictionary. Základní dvě zprávy, jež nabízí, jsou

-(void)setObject:anObject forKey:aKey;
-objectForKey:aKey;

První z nich uloží do tabulky dvojici <klíč, hodnota>, druhá vyhledá hodnotu k zadanému klíči (v čase nezávisejícím na počtu hodnot v tabulce). Je zřejmé, že má-li hashovaná tabulka být konsistentní, musí interně udržovat ne sdílené odkazy na klíče, ale jejich neměnné kopie — kdyby v tabulce byly jen odkazy na klíče, mohl by se objekt reprezentující klíč kdykoli změnit, aniž by se o tom tabulka vůbec dozvěděla; hashovaná tabulka by se v takovém případě stala samozřejmě nekorektní. Implementace metody setObject:forKey: tedy musí vypadat přibližně takto:

-(void)setObject:anObject forKey:aKey {
  id myKey=[aKey copy]; // potřebuji vlastní neměnnou kopii
  id myVal=[anObject retain]; // hodnota se může klidně měnit (ale nesmí zaniknout)
  zaradit_do_tabulky(myKey,myVal); // hashováním se zde zabývat nepotřebujeme
}

Za těchto podmínek bude hashovaná tabulka pracovat korektně, ovšem zaplatíme za to zpomalením programu a větší spotřebou paměti: každý klíč vkládaný do tabulky se musí nejprve zkopírovat — to znamená, že potřebujeme dvakrát tolik paměti a navíc se program musí zdržovat kopírováním dat objektu. Přitom to v řadě případů není doopravdy zapotřebí: velmi často (v praxi téměř vždy, protože klíče obvykle bývají textové konstanty, tedy statické, neměnné objekty třídy NSString) se obsah klíčů stejně nikdy nebude měnit; hashovaná tabulka by si tedy ve skutečnosti vlastně mohla udržovat pouze odkazy na klíče — musela by ale 'vědět', které klíče se ještě mohou měnit a které ne.

Objektové prostředí se svým polymorfismem ovšem nabízí samozřejmé a velmi elegantní řešení: hashovaná tabulka samozřejmě nemůže vědět které objekty se budou měnit; mohou to ale vědět tyto objekty samy! Stačí zavést pro každý typ objektů pro který to dává rozumný smysl dvě třídy: třídu neměnných objektů a třídu objektů. které se mohou měnit — např. NSString (neměnné) a NSMutableString (měnitelné). Neměnné objekty pak nemusí nikdy vytvářet kopie; jejich metoda copy může být implementována nějak takto:

@implementation NSString // princip
...
-copy {
  return [self retain];
}
...
@end

Nyní funguje vše automaticky s nejvyšší možnou efektivitou: vkládáme-li do hashované tabulky klíč, který se nikdy nebude měnit, hashovaná tabulka bude udržovat pouze odkaz — žádná paměť navíc, žádná ztráta času, nic se nekopíruje. Pouze v případě že jako klíč využijeme měnitelný objekt — např. NSMutableString — kopie se vytvoří; v takovém případě se tomu ale stejně nemůžeme vyhnout. Navíc tentýž trik automaticky funguje nejen v hashované tabulce, ale kdekoli, kde potřebujeme okamžité kopie objektů: připravujeme např. program, který si pro funkci 'undo' musí zapamatovat momentální stav svých datových objektů? Nic jednoduššího — prostě vytvoříme kopie všech objektů reprezentujících data tak, že jim pošleme zprávu copy. Díky koncepci měnitelných a neměnných objektů nemusíme zkoumat, která data se mohou měnit, a která ne — fakticky se zkopírují jen ta, kterých se změny mohou týkat.

Cocoa proto v řadě případů nabízí dvojice tříd NSXXX a NSMutableXXX, kde objekty třídy NSXXX se nemohou měnit, zatímco objekty třídy NSMutableXXX ano (je tomu tak mimochodem i u třídy NSDictionary — metoda setObject:forKey: je tedy samozřejmě k dispozici pouze u objektů třídy NSMutableDictionary). Třída NSMutableXXX je vždy dědicem třídy NSXXX; měnitelné objekty tedy 'umějí' všechno, co neměnné, a navíc jsou schopny změn. Pošleme-li kterémukoli objektu třídy NSXXX zprávu copy, nevytvoří se žádná kopie; namísto toho získáme další sdílený odkaz na tentýž (neměnný) objekt. Pošleme-li však zprávu copy objektu třídy NSMutableXXX, dostaneme nový objekt třídy NSXXX, který bude obsahovat neměnnou kopii momentálního stavu původního objektu.

Složené objekty

Uvědomme si, že koncepce měnitelných a neměnných objektů zaručuje co nejefektivnější zkopírování i u složených objektů. Jako příklad vezměme objekt třídy NSMutableArray, který reprezentuje pole libovolných dalších objektů, do nějž můžeme přidávat nebo z něj odebírat (odpovídající neměnná třída NSArray reprezentuje pole, jehož obsah je při vytvoření pevně dán a nadále jej již nemůžeme měnit).

Obrázek ukazuje příklad objektu třídy NSMutableArray, obsahujícího (odkazy na) jak měnitelné, tak neměnné objekty. Vyžádáme-li si nyní zprávou copy neměnnou kopii momentálního stavu tohoto objektu, musí se vytvořit nový objekt třídy NSArray (protože existující objekt mutableArray je měnitelný) se stejným (a neměnným) obsahem. Nový objekt tedy může se starým sdílet odkazy na neměnné vnořené objekty, ale musí obsahovat vlastní (neměnné) kopie objektů, které byly měnitelné. Výsledek bude vypadat takto:

Čas od času bychom mohli potřebovat 'přece jenom' změnit neměnný objekt. Doslova to samozřejmě není možné — tím bychom celou koncepci měnitelných a neměnných objektů postavili na hlavu; můžeme si však pomocí zprávy mutableCopy vyžádat vytvoření vlastní měnitelné kopie objektu. Obsahuje-li původní objekt vnořené objekty, bude jeho měnitelná kopie obsahovat (odkazy na) tytéž objekty, a to i v případě, že tyto objekty samy jsou neměnné (chceme-li např. vytvořit měnitelnou kopii pole, je to proto, abychom do něj mohli přidávat nebo z něj odebírat další objekty; ne proto, abychom mohli měnit objekty v něm obsažené):

Koncepce měnitelných a neměnných objektů je velmi silným a šikovným mechanismem, který kromě výrazného zvýšení efektivity programů dokáže i omezit programátorské chyby: používáme-li neměnný objekt, nemůže se nám omylem stát, že jej některý úsek programu změní (z podobného důvodu byl např. v ANSI C zaveden modifikátor const). Rozdělení měnitelných a neměnných objektů na samostatné třídy NSXXX a NSMutableXXX navíc umožňuje některé takové chyby odchytit již při překladu — pokusíme-li se např. staticky typovanému objektu třídy NSArray poslat zprávu addObject: překladač vydá varování.

Obsah seriálu (více o seriálu):

Tématické zařazení:

 » Rubriky  » Informace  

 » Rubriky  » Agregator  

 » Rubriky  » Začínáme s  

Diskuse k článku

 

Vložit nový příspěvek   Sbalit příspěvky

 

Kopirovani poli funguje jinak

Autor: Jiri Volejnik Muž

Založeno: 03.06.2004, 10:38
Odpovědí: 0

Metody "copy" a "mutableCopy" u instanci NSArray a NSMutableArray v zadnem pripade nevytvareji kopie objektu ktere ta pole obsahuji, pouze kopie poli samotnych!
Neboli druhy odstavec a druhy obrazek v kapitole "Slozene objekty" jsou zcela spatne. Druhy obrazek ma byt stejny jako treti, s tim ze je nutne vzajemne prohodit objekty "array" a "mutableArray".

Odpovědět na příspěvek

RE: Kopirovani poli funguje jinak

Autor: OC Muž

Založeno: 03.06.2004, 14:58

DAMN! Další věc, kterou applovci zprasili :(((( To je zázrak, že jsem si o to ještě v žádném programu nerozbil ústa.

Takže: v principu mám pravdu já, ze samozřejmých důvodů to má fungovat tak, jak je popsáno v článku (protože úkolem "copy" je vytvořit aktuální snímek objektu, který není -- ani vnitřně -- sdílený).

Bohužel, v praxi je v Cocoa velmi nepříjemná chyba, o níž jsem nevěděl (a za to se čtenářům omlouvám): copy *nefunguje* korektně, takže "array" z prvního obrázku skutečně *sdílí* měnitelné "růžové" objekty B a C.

Kdyby se tak applovci nehrabali v OpenStepu, to by byla věc :(((

Odpovědět na příspěvek

RE: RE: Kopirovani poli funguje jinak

Autor: OC Muž

Založeno: 03.06.2004, 19:07

Jen pro zajímavost: trochu jsem se v tom hrabal, jeden z důsledků je třeba to, že ti #@$$%@#$ používají pro pole hash jenž je počtem prvků pole. Jinými slovy, pokud v Cocoa zkusíte používat pole jako klíče v NSDictionary, bude to zvířecky neefektivní (pokud, což je pravděpodobné, bude mít většina polí stejný počet prvků). Ach jo... :(((

Odpovědět na příspěvek

RE: RE: Kopirovani poli funguje jinak

Autor: ANo Muž

Založeno: 03.06.2004, 21:15

OC> Takže: v principu mám pravdu já

:-O !?

Bohuzel nemam s puvodnim OpenStepem zkusenosti, takze nemuzu posoudit, jak to bylo puvodne. Ale i co se tyce principu, prijde mi soucasny pristup prirozenejsi, protoze pole neobsahuje objekty, ale reference na ne. To zni mozna trivialne, ale vysvetlim to na prikladu:

1. Objekt main ma referenci na menitelny objekt obj.
2. Vytvorim pole array0, ktere bude take obsahovat referenci na obj.
3. Vytvorim array1 - kopii pole array0.
4. Zmenim menitelny objekt obj pomoci reference, kterou ma objekt main.

Kdyby to bylo tak, jak je to podle OC principialne spravne, referencovalo by pole array0 zmeneny objekt obj, zatimco array1 jeho starou verzi. Pritom s poli se nehybalo a mela by byt rovnocenna. Dochazi totiz k tomu, ze pri vytvareni pole se elementy referencuji (resp. are retained), zatimco pri jeho duplikaci se kopiruji.

IMO je spravnejsi implementace Applu: obe pole by referencovala ten samy zmeneny objekt. Pokud bych nechtel, aby se objekt ktery je v kopii pole dal "z vnejsku" menit, nechtel bych ani, aby se dal "z vnejsku" menit v puvodnim poli. Vlozil bych tedy jeho nemennou kopii uz do pole.

Jde jen o to:
- zda ma byt pole souborem referenci, zatimco jeho kopie nemennym snimkem (OC), nebo
- zda ma byt i jeho kopie tymz souborem referenci (Apple).

Svuj nazor nechci nikomu vnucovat. Ani nechci tvrdit, ze je spravne delat v API takhle zasadni zmeny a v podstate to programatorum zamlcet (bylo-li to v OpenStepu skutecne jinak). Jen chci ukazat, ze o tom, zda je pristup popisovany OC principialne spravny, se da prinejmensim diskutovat. A i kdyby, tenhle serial je snad o Cocoa, nikoli o OpenStepu a Ondrejem preferovanych (nebo spis zazitych) principech.

Odpovědět na příspěvek

RE: RE: RE: Kopirovani poli funguje jinak

Autor: OC Muž

Založeno: 03.06.2004, 21:41

To není otázka OpenStepu neOpenStepu, to je otázka základního pochopení principů práce s objekty.

*Samozřejmě
*, že array1 má obsahovat původní stav obj, a *právě na to* kopírování je. Představte si, že ta kopie slouží jako snapshot pro undo: *samozřejmě*, že při undo se chceme vrátit k -- dejme tomu -- původnímu textu obsahujícímu původní obrázek, a *nikoli* původnímu textu obsahujícímu *nový* obrázek, protože ten obrázek byl změněn z "main", že ne?

Ještě jednou: úkolem -copy je vytvořit můj vlastní, nesdílený, a zásadně neměnný snímek, s nímž mi nikdo jiný nebude cvičit. *Právě* proto, že pole obsahuje odkazy (a ne přímo hodnoty) je tak důležité, aby -copy fungovalo jako deep copy, a ne tak, jak to zprasili applovci.

Odpovědět na příspěvek

RE: RE: RE: RE: Kopirovani poli funguje jinak

Autor: ANo Muž

Založeno: 04.06.2004, 18:17

Premyslel jsem nad tim... Mozna mam deformovany pohled, ale bral jsem to tak, ze kopie by v prve rade mela obsahovat tytez objekty (nebo jeste lepe reference na tytez objekty), ne jejich kopie. Dejme tomu, ze mam seznam lidi (pole), a vytvorim si jeho kopii. Jeden z lidi si zmeni jmeno. Podle me by kopie i original mely obsahovat v prve rade tytez lidi, konec koncu lidi nikdo nemnozil, jen jsem si delal kopii jejich seznamu. Sve minule jmeno by mel (pokud vubec nekdo) ve svych zaznamech (inst. promennych) mit ten konkretni clovek.

Treba je to skutecne spatne, a na popisovane by se melo pouzit jedine +arrayWithArray:, jak pises, ale vzhledem k tomu, ze Cocoa takhle skutecne funguje, asi u toho prozatim zustanu. (Kdyz uz jsme u toho +arrayWithArray: ve specifikaci OpenStepu AFAIK neni, musel bych to rozepsat: [[[NSArray alloc] initWithArray:X] autorelease]).

Prijde mi neskutecne, ze by Apple zmenil takhle dulezitou veci jen tak. Copak nemaji co delat a jen tak si meni chovani zakladnich trid? Jediny duvod, co me napada, je rychlost (zasilani retain namisto copy ale v pripade nemennych objektu usetri jen jednu zpravu na objekt). Ac nejde IMO o "bug" v pravem slova smyslu, urcite o tom posli bug report do Apple. Jejich odpoved by me zajimala.

Odpovědět na příspěvek

RE: RE: RE: RE: RE: Kopirovani poli funguje jinak

Autor: OC Muž

Založeno: 04.06.2004, 22:44

> Prijde mi neskutecne, ze by Apple zmenil takhle dulezitou veci jen tak

Ten důvod je jednoduchý -- může za to Carbon. Fakt.

Jde o to, že jen a jenom kvůli Carbonu vznikla vrstva CoreFoundation, a to je podivný kočkopes, neobjektové objekty (budeme se o nich trochu podrobněji bavit, ale až na samém konci našeho seriálu). Nad nimi pak je postavena sdíleně funkčnost Cocoa i Carbonu. A v nich je nejvíc čuňáren velmi tvrdého kalibru.

Tak třeba NSArray i NSMutableArray mohou být ve skutečnosti implementovány _jedinou_ třídou, takže se může stát, že

if ([[NSArray array] isKindOfClass:[NSMutableA
rray class]])
... tento kód se provede! ...

a ještě horší věci :(((

Mimochodem, až někdy do verse 10.1 (nebo snad dokonce 10.2, už si to přesně nepamatuji) dokonce -- opět vinou CoreFoundation!!! -- nefungovalo ani to, že immutable objekt na zprávu copy vrací sám sebe; i immutable objekty se fakticky kopírovaly!!!

Jiný trik, za který pro změnu mohl přechod na Quartz (taky hrozný šmejd): ještě nedávno -- v 10.3 je to konečně opraveno -- fungovalo překreslování tak, že když se změnil jeden pixel v levém horním rohu okna a jeden pixel v pravém dolním rohu okna, překreslilo se okno kompletně celé!

A pak lidé mohli tvrdit, že ObjC je neefektivní: prdlajs, ObjC je rychlé jako blesk, ale to nepomůže, když někdo zprasí systémové knihovny :(((

Bugreport jsem poslal, Apple odpověděl že je to "intended behaviour". To se dalo čekat, to mi napsali i když jsem před lety upozorňoval na ty výše zmíněné chyby (jež pak, řadu let později, konečně opravili!), nebo třeba když jsem dááááávno hned u 10.0 bety psal, že mají blbě práci s okny -- po letech v Jaguáru pak tiše a bez velké publicity přešli na to, co jsem jim tehdy doporučoval..... Ach jo :(((

Odpovědět na příspěvek

RE: RE: RE: RE: RE: RE: Kopirovani poli funguje jinak

Autor: ANo Muž

Založeno: 05.06.2004, 15:55

V tom pripade se tesim na posledni dil (...mozna se spis trochu obavam, co se dozvim).

Prekvapuje me, ze o techhle problemech se zas tolik nemluvi. Stalo by za to zalozit nejakou iniciativu za ciste Cocoa. To, ze je pod tim CoreFoundation snad jeste neznamena, ze se to nemuze chovat rozumne (snad jen mene efektivne).

Dost by me take zajimalo, jak se k tomu stavi GNUstep. Ma pry udrzovat (volitelne) kompatibilitu i s Cocoa, coz je zrejme dost nemozne.

No uvidime, co prijde v dalsich verzich Mac OS X. Bohuzel tam Apple tyto chyby/vlastnosti dost mozna ponecha, protoze programy jiz vznikle pro Cocoa s nimi pocitaji.

Odpovědět na příspěvek

RE: RE: RE: RE: RE: Kopirovani poli funguje jinak

Autor: OC Muž

Založeno: 04.06.2004, 22:49

Mimochodem, ještě jsem si vzpomněl: je to krásně vidět také na tom, že kód samotné třídy NSMutableArray *dělá* deep copy! Jen kód těch jejích konkrétních skrytých podtříd (jež už fakticky nejsou podtřídy NSArray, nýbrž čuňárny z CoreFoundation) to nedělá. Stačí ale napsat vlastní podtřídu NSMutableArray, a standardní -copy bude -- přesně jak Pámbu mínil a jak to v tom systému když jej koupili a než jej zprasili také bylo -- dělat deep copy ;)))

Odpovědět na příspěvek

RE: RE: RE: Kopirovani poli funguje jinak

Autor: OC Muž

Založeno: 03.06.2004, 21:47

P.S.: samozřejmě, že existují i případy, kdy bychom potřebovali immutable shallow copy. Na to ale není -copy, na to je +[NSArray arrayWithArray:].

To není jen tak hříčka s touto zprávou/tamtou zprávou, to je důležitý princip, "intention-revealing". Když řeknu "copy", znamená to, že chci *kopii* -- a nezlobte se na mne, pokud si udělám kopii něčeho a pak se změní originál, kopie zůstává v původním stavu. To je právě smysl kopírování.

V jiných případech chci objekty sdílet tak, abych všechny změny vzájemně viděl, samozřejmě -- to je dokonce častější případ. Ale na to je -retain (a další). Nikoli -copy.

Odpovědět na příspěvek

 

 

Vložit nový příspěvek

Jméno:

Pohlaví:

,

E-mail:

Předmět:

Příspěvek:

 

Kontrola:

Do spodního pole opište z obrázku 5 znaků:

Kód pro ověření

 

 

 

 

 

Přihlášení k mému účtu

Uživatelské jméno:

Heslo: