64 je dvakrát 32 - MujMAC.cz - Apple, Mac OS X, Apple iPod

20. května 2008, 09.00 | Jednou z nejvýznamnějších novinek Leoparda pro nás, programátory v prostředí Cocoa, je to, že nyní máme plně k dispozici všechny možnosti a výhody čtyřiašedesátibitového prostředí.

64 je dvakrát 32

Jednou z nejvýznamnějších novinek Leoparda pro nás, programátory v prostředí Cocoa, je to, že nyní máme plně k dispozici všechny možnosti a výhody čtyřiašedesátibitového prostředí.

My jsme se již mnohokrát s rozdíly mezi módem 32 bitů (zpětně plně kompatibilním s předcházejícími systémy, a proto omezeným) a módem 64 bitů setkali; vedle řady poměrných drobností – jako třeba že výjimky ve čtyřiašedesátibitovém režimu fungují poněkud jinak, nabízejíce maximální efektivitu pro @try/@catch na úkor zhoršené efektivity @throw, nebo že právě ve čtyřiašedesátibitovém módu se projeví výhody nově přidané direktivy @package pro řízení přístupu k instančním proměnným – je asi nejpodstatnějším rozdílem to, že ve čtyřiašedesátibitovém režimu pro Objective C neexistuje syndrom "fragile class" , a – což úzce souvisí – instanční proměnné není zapotřebí deklarovat, neboť překladač je dokáže vytvořit sám na základě deklarací @property.

Kromě těchto čtyřiašedesátibitových novinek, jež už známe, se ovšem v Leopardu objevilo několik dalších drobností; na ty se podíváme nyní.

Nové celočíselné typy

Leopard zavádí dvojici nových celočíselných typů: NSInteger a NSUInteger. V praxi nám mohou sloužit stejně, jako nám dosud sloužil int a unsigned; rozdíl spočívá v tom, že nové typy jsou vždy převeditelné na adresu (ukazatel): s intem to ve čtyřiašedesátibitovém režimu samozřejmě neplatí, neboť int (stejně jako unsigned) zůstávají dvaatřicetibitové.

(Možná někoho napadne: "Proč vůbec zavádět nové typy, proč nepoužívat ve čtyřiašedesátibitovém módu prostě long a unsigned long?" Inu, kvůli zpětné kompatibilitě s režimem dvaatřicetibitovým: nové typy NSInteger a NSUInteger jsou definovány tak, že longu/unsigned longu odpovídají pouze v režimu čtyřiašedesátibitovém, ale v režimu dvaatřicetibitovém odpovídají intu/unsigned intu. Pokud to ovšem pro nás není podstatné, můžeme definovat makro NS_BUILD_32_LIKE_64; pak budou prostě a jednoduše typy NSInteger a NSUInteger ekvivalentní typům long a unsigned long v libovolném režimu.)

Novým typům odpovídá také rozšíření služeb knihoven: vedle existujících služeb intXXX, jež pracují s typem int, jsou nyní k dispozici také služby integerXXX, pracující s typem NSInteger: kupříkladu třída NSNumber nyní přijímá zprávy numberWithInteger a numberWithUnsignedInteger, a její instance zprávy integerValue, unsignedIntegerValue; instance třídy NSString rozumějí zprávě integerValue a tak dále.

Máme také k dispozici odpovídající konstanty NSIntegerMax, NSIntegerMin a NSUIntegerMax pro minimální a maximální možné hodnoty.

Při používání nových typů s formáty (stringWithFormat:, NSLog, ...) je třeba dávat pozor právě vzhledem k tomu, jak jsou definovány: "%d" (a podobné varianty "%u", "%x", ...) samozřejmě nebude obecně fungovat. Nejjednodušším řešením je důsledně používat "%ld" (a podobné varianty "%lu", "%lx", ...), a hodnoty explicitně přetypovat na long:

NSInteger n;
...
NSLog(@"n=%ld",(long)n);

Je třeba si také dát pozor na hodnotu NSNotFound: ta samozřejmě má také odlišnou hodnotu ve dvaatřicetibitovém a v čtyřiašedesátibitovém režimu. Přímo v kódu s ní ovšem žádný problém nastat nemůže ("if (range.location==NSNotFound) ...") je tedy zcela v pořádku; pokud ji však dvaatřicetibitový program uloží např. do souboru a čtyřiašedesátibitový načte, nebude to pro něj již NSNotFound, ale "obyčejná" hodnota.

Nový typ pro desetinné hodnoty

Ačkoli to není vynuceno samotnou čtyřiašedesátibitovou architekturou, firma Apple využila toho, že stejně dochází ke změnám v API, a zároveň přidala nový symbolicky definovaný typ namísto původního typu float – CGFloat (předpona CG znamená, že typ je deklarován v knihovně Core Graphics; ostatní knihovny Apple jej ovšem bohatě podporují).

Podobně jako tomu je u typů NSInteger a NSUInteger, i CGFloat je definován různě pro různé architektury: zatímco ve dvaatřicetibitovém režimu samozřejmě odpovídá kvůli zpětné kompatibilitě typu float, v módu čtyřiašedesátibitovém přináší dvojitou přesnost, jsa definován jako double.

S typem CGFloat nyní pracují všechny zprávy vyjma těch, jež jsou explicitně určeny pro typ float (např. floatValue); také zůstal typ float zachován v některých konkrétních API (typesetting, animace). Vše ostatní bylo předeklarováno pro práci s typem CGFloat; speciálně také všechny geometrické struktury (NSPoint, NSSize, NSRect).

Explicitní typy pro výčtové hodnoty

Výčtové hodnoty (enum) jsou v jazyce C definovány poněkud nešťastně, neboť není jednoznačně určeno, jakému celočíselnému typu vlastně typ enum odpovídá (přesněji řečeno, překladač to určí na základě použitých výčtových hodnot). Aby zde nedocházelo k nekonsistencím, byly výčtové typy v Cocoa předefinovány na typy explicitní; namísto dosavadního

typedef enum { // až do Tygra včetně
    NSNullCellType = 0,
    NSTextCellType = 1,
    NSImageCellType = 2
} NSCellType;

se nyní používá

enum { // od Leoparda dále
    NSNullCellType = 0,
    NSTextCellType = 1,
    NSImageCellType = 2
};
typedef NSUInteger NSCellType;

Výhodou je to, že nyní lze explicitní jméno typu používat v deklaracích metod bez nebezpečí nekonsistence a binární nekompatibility mezi různými verzemi systému.