Stocker des CGImageRef dans un NSDictionnary

Réponses

• cyrano Membre

  janvier 2011 15:10 modifié #2

  - (id)initWithCGImage:(CGImageRef)cgImage size:(NSSize)size
• zoc Membre

  janvier 2011 janvier 2011 modifié #3

  CGImageRef "dérive" du type CoreFoundation CFType. Sachant que CFType est "bridgé" avec NSObject (confirmé par un ingénieur Apple), un CGImageRef peut recevoir tous les messages supportés par NSObject.
  
  
  Par conséquent, pour mettre un CGImageRef dans un NSArray ou un NSDictionnary, il suffit de le caster en "id"
  
• zoc Membre

  janvier 2011 15:10 modifié #4

  dans 1293999703:

  
  - (id)initWithCGImage:(CGImageRef)cgImage size:(NSSize)size
  

  
  Beaucoup plus lent que la solution "toll free bridging" 
• AP Membre

  janvier 2011 15:10 modifié #5

  dans 1293999989:

  
  CGImageRef "dérive" du type CoreFoundation CFType. Sachant que CFType est "bridgé" avec NSObject (confirmé par un ingénieur Apple), un CGImageRef peut recevoir tous les messages supportés par NSObject.
  
  
  Par conséquent, pour mettre un CGImageRef dans un NSArray ou un NSDictionnary, il suffit de le caster en "id"
  

  
  
  Je viens d'apprendre qqlch. Merci beaucoup! Petite question additionnelle, quand la collection possède les objets qu'elle contient et que c'est un objet "CFType", lors de la suppression, elle fait un release ou un CFRelease?
  
  
  Merci
• zoc Membre

  janvier 2011 janvier 2011 modifié #6

  Pour la collection c'est transparent... Et comme la collection est écrite en Objective-C, elle va envoyer un message retain/release dans tous les cas. Mais en fait il est tout à  fait possible de caster un CFType en id, et de lui envoyer un message retain: Ca aura pour effet d'appeler CFRetain.
  
  De la même manière, il est possible de caster un (NSObject *) (ou tout autre objet dérivant de NSObject) en CFType et d'appeler CFRetain dessus: Ca aura le même effet qu'un envoi du message "retain".
  
  Les 2 types sont en effet interchangeables. C'est ce qu'Apple appelle le "toll free bridging". Dans le même style, CFString et NSString sont également interchangeables. Il y a plusieurs autres classes Cocoa "bridgées" avec leur équivalent Core Foundation.
  
  
  
  Dans le cas qui nous intéresse, la conclusion est qu'une collection Cocoa peut contenir des objets cocoa ou des objets Core Foundation. De la même manière, une collection Core Foundation peut très bien contenir des objets cocoa, et pas seulement des objets core foundation.
  
  
• AP Membre

  janvier 2011 15:10 modifié #7

  dans 1294002096:

  
  Pour la collection c'est transparent... Et comme la collection est écrite en Objective-C, elle va envoyer un message retain/release dans tous les cas. Mais en fait il est tout à  fait possible de caster un CFType en id, et de lui envoyer un message retain: Ca aura pour effet d'appeler CFRetain.
  
  De la même manière, il est possible de caster un (NSObject *) (ou tout autre objet dérivant de NSObject) en CFType et d'appeler CFRetain dessus: Ca aura le même effet qu'un envoi du message "retain".
  
  Les 2 types sont en effet interchangeables. C'est ce qu'Apple appelle le "toll free bridging". Dans le même style, CFString et NSString sont également interchangeables. Il y a plusieurs autres classes Cocoa "bridgées" avec leur équivalent Core Foundation.
  
  
  
  Dans le cas qui nous intéresse, la conclusion est qu'une collection Cocoa peut contenir des objets cocoa ou des objets Core Foundation. De la même manière, une collection Core Foundation peut très bien contenir des objets cocoa, et pas seulement des objets core foundation.
  

  
  
  Et bien merci pour cette explication claire et précise
  
  Question bête, pourquoi avoir Apple a fait 2 hiérarchies objet un peu parallèles?
  
  Merci
• AliGator Membre, Modérateur

  janvier 2011 15:10 modifié #8

  Parce que l'une est en C, à  base donc de CFTypes, créée pour le Framework CoreFoundation qui est la base de toute l'architecture logicielle de MacOSX, en dehors même de Cocoa lui-même (normal puisque pur C et pas de notion d'objet stricto sensu), CoreFoundation est vraiment la brique bas niveau... et l'autre est une hiérarchie écrite en Objective-C, pour le framework Cocoa, qui est une surcouche qui rajoute la notion de classes et d'objets et d'envois de messages... et que Apple allait pas réinventer tout CoreFoundation
  
  Cocoa n'étant limite qu'une surcouche de CoreFoundation (bon ok c'est un peu limitatif mais bon) au même titre que Objective-C est une surcouche du C, ils n'allaient pas réinventer la roue : quand tu manipules des NSArray, en réalité sous le capot ce sont des CFArrayRefs qui sont utilisés (en fait c'est pareil, NSArray, CFArrayRefs, basiquement c'est la même chose eux aussi son "toll-free bridged"), c'est juste que l'API "Cocoa", utilisant des NSArrays, classe dérivant de NSObject, ... est plus sympa à  utiliser (et est dans un contexte Cocoa qui définit la notion de classes et d'objets) que CFArrayRef qui est du C pur.
• AP Membre

  janvier 2011 15:10 modifié #9

  Merci 
• Céroce Membre, Modérateur

  janvier 2011 15:10 modifié #10

  dans 1294048400:

  
  Cocoa n'étant limite qu'une surcouche de CoreFoundation
  

  
  
  Pour être plus précis, Cocoa est séparée en deux parties:
  - Foundation (tout ce qui est manipulation des données)
  - App Kit (interface utilisateur et structure d'une appli).
  
  Sur Mac, on ne se rend pas toujours bien compte dans quelle partie se trouve une classe, mais sur iPhone, les classes Foundation commencent par NS, et les classes UIKit (équivalent d'AppKit) commencent par UI.
  
  Cette division explique certains choix de conception. Par exemple, NSString est une classe de Foundation. Mais pour pouvoir l'afficher à  l'écran, une catégorie lui ajoute des méthodes (NSString Application Kit Additions), assurant ainsi la séparation.