Implémentation de CComObject, CComAggObject et CComPolyObject

Les classes de modèle CComObject, CComAggObject et CComPolyObject sont toujours les classes les plus dérivées de la chaîne d’héritage. Il est de leur responsabilité de gérer toutes les méthodes dans IUnknown: QueryInterface, AddRef, et Release. En outre, CComAggObject et CComPolyObject (lorsqu’ils sont utilisés pour les objets agrégés) fournissent le comptage et QueryInterface la sémantique de référence spéciaux requis pour l’inconnu interne.

Si CComObject, CComAggObjectou CComPolyObject est utilisé dépend de la déclaration d’une (ou aucune) des macros suivantes :

Macro	Résultat
DECLARE_NOT_AGGREGATABLE	Utilise CComObjecttoujours .
DECLARE_AGGREGATABLE	Utilise CComAggObject si l’objet est agrégé et CComObject s’il ne l’est pas. CComCoClass contient cette macro de sorte que si aucune des macros DECLARE_*_AGGREGATABLE n’est déclarée dans votre classe, il s’agit de la valeur par défaut.
DECLARE_ONLY_AGGREGATABLE	Utilise CComAggObjecttoujours . Retourne une erreur si l’objet n’est pas agrégé.
DECLARE_POLY_AGGREGATABLE	ATL crée une instance de CComPolyObject<CYourClass> quand elle IClassFactory::CreateInstance est appelée. Lors de la création, la valeur de l’inconnu externe est case activée ed. S’il s’agit de NULL, IUnknown est implémenté pour un objet non agrégé. Si l’inconnu externe n’est pas NULL, IUnknown est implémenté pour un objet agrégé.

L’avantage de l’utilisation CComAggObject et CComObject est que l’implémentation est IUnknown optimisée pour le type d’objet créé. Par exemple, un objet non agrégé a uniquement besoin d’un nombre de références, tandis qu’un objet agrégé a besoin à la fois d’un nombre de références pour l’inconnu interne et d’un pointeur vers l’inconnu externe.

L’avantage de l’utilisation CComPolyObject est que vous évitez d’avoir à la fois CComAggObject et CComObject dans votre module pour gérer les cas agrégés et non agrégés. Un objet unique CComPolyObject gère les deux cas. Cela signifie qu’une seule copie de la table virtuelle et une copie des fonctions existent dans votre module. Si votre vtable est volumineux, cela peut réduire considérablement la taille de votre module. Toutefois, si votre vtable est petit, l’utilisation CComPolyObject peut entraîner une taille de module légèrement plus grande, car elle n’est pas optimisée pour un objet agrégé ou non agrégé, comme c’est le cas CComAggObject et CComObject.

Voir aussi

Principes de base des objets ATL COM
Agrégation et macros de fabrique de classe