Cela ressemble (et peut-être basé sur) au principe C des unions
Euh non pas vraiment, le principe des unions c'est d'utiliser qu'un seul bloc de mémoire pour contenir deux variables différentes. Par exemple si j'écris :
union Test {<br /> int entier;<br /> float decimal;<br />};
Ici, "union Test" fera 4 octets et non pas 8 si on remplace "union" par "struct", les champs "entier" et "decimal" occupe le même espace mémoire.
Alors que ce qui permet de faire ce genre de manipulation ici, c'est le fait que deux types différents soient interchangeables parce qu'ils ont des champs identiques et placés dans le même ordre.
Euh non pas vraiment, le principe des unions c'est d'utiliser qu'un seul bloc de mémoire pour contenir deux variables différentes. Par exemple si j'écris : union Test { Â Â int entier; Â Â float decimal; };
Ici, "union Test" fera 4 octets et non pas 8 si on remplace "union" par "struct", les champs "entier" et "decimal" occupe le même espace mémoire.
Oui, je sais ce qu'est une union : le même bloc mémoire est déclaré pouvoir être interprété de différentes façons, évitant ainsi des cast fastidieux sur les adresses.
dans 1199283891:
Alors que ce qui permet de faire ce genre de manipulation ici, c'est le fait que deux types différents soient interchangeables parce qu'ils ont des champs identiques et placés dans le même ordre.
Cela ne semble nécessaire qu'au début du bloc mémoire seulement, c'est pour cela que je parle d'union.
Alors que ce qui permet de faire ce genre de manipulation ici, c'est le fait que deux types différents soient interchangeables parce qu'ils ont des champs identiques et placés dans le même ordre.
Cela ne semble nécessaire qu'au début du bloc mémoire seulement, c'est pour cela que je parle d'union.
Excuse-moi mais je vois toujours pas la relation avec les unions. o_O
J'ai en tête le modèle des événements boutons, claviers, expose, ... , dans la bibliothèque XLib qui sont définis par des unions, avec en début de bloc mémoire les éléments communs (type, géométrie, ..) et les infos spécifiques en fin de bloc.
NSMakeCollectable Makes a newly allocated Core Foundation object eligible for collection.
NS_INLINE id NSMakeCollectable(CFTypeRef cf) { return cf ? (id)CFMakeCollectable(cf) : nil; } Discussion This function is a wrapper for CFMakeCollectable, but its return type is id"avoiding the need for casting when using Cocoa objects.
This function may be useful when returning Core Foundation objects in code that must support both garbage-collected and non-garbage-collected environments, as illustrated in the following example.
- (CFDateRef)foo { CFDateRef aCFDate; // ... return [NSMakeCollectable(aCFDate) autorelease]; } CFTypeRef style objects are garbage collected, yet only sometime after the last CFRelease is performed. Particularly for fully-bridged CFTypeRef objects such as CFStrings and collections (such as CFDictionary), it is imperative that either CFMakeCollectable or the more type safe NSMakeCollectable be performed, preferably right upon allocation.
Réponses
Cela ressemble (et peut-être basé sur) au principe C des unions
Euh non pas vraiment, le principe des unions c'est d'utiliser qu'un seul bloc de mémoire pour contenir deux variables différentes. Par exemple si j'écris :
Ici, "union Test" fera 4 octets et non pas 8 si on remplace "union" par "struct", les champs "entier" et "decimal" occupe le même espace mémoire.
Alors que ce qui permet de faire ce genre de manipulation ici, c'est le fait que deux types différents soient interchangeables parce qu'ils ont des champs identiques et placés dans le même ordre.
Oui, je sais ce qu'est une union : le même bloc mémoire est déclaré pouvoir être interprété de différentes façons, évitant ainsi des cast fastidieux sur les adresses.
Cela ne semble nécessaire qu'au début du bloc mémoire seulement, c'est pour cela que je parle d'union.
Excuse-moi mais je vois toujours pas la relation avec les unions. o_O
#define CGAutorelease(x) (__typeof(x))[NSMakeCollectable(x) autorelease]
et la doc qui va avec
NSMakeCollectable
Makes a newly allocated Core Foundation object eligible for collection.
NS_INLINE id NSMakeCollectable(CFTypeRef cf) {
return cf ? (id)CFMakeCollectable(cf) : nil;
}
Discussion
This function is a wrapper for CFMakeCollectable, but its return type is id"avoiding the need for casting when using Cocoa objects.
This function may be useful when returning Core Foundation objects in code that must support both garbage-collected and non-garbage-collected environments, as illustrated in the following example.
- (CFDateRef)foo {
CFDateRef aCFDate;
// ...
return [NSMakeCollectable(aCFDate) autorelease];
}
CFTypeRef style objects are garbage collected, yet only sometime after the last CFRelease is performed. Particularly for fully-bridged CFTypeRef objects such as CFStrings and collections (such as CFDictionary), it is imperative that either CFMakeCollectable or the more type safe NSMakeCollectable be performed, preferably right upon allocation.