Les classes de modèles, CComObject, CComAggObjectet CComPolyObject sont toujours des classes plus dérivées dans la chaîne d'héritage. C'est leur responsabilité de gérer toutes les méthodes IUnknown: QueryInterface, AddRefet Release. En outre, CComAggObject et CComPolyObject (lorsqu'il est utilisé pour les objets agrégés) fournissent le décompte de références spéciales et de la sémantique de QueryInterface pour l'inconnu intérieur.
Si CComObject, CComAggObjectou CComPolyObject est utilisée dépend de si vous déclarez la macro DECLARE_POLY_AGGREGATABLE et de savoir si votre objet est étant agrégée:
L'avantage de l'utilisation de CComAggObject et CComObject , c'est que la mise en œuvre de IUnknown est optimisé pour le type de l'objet en cours de création. Par exemple, un objet non agrégée besoin seulement d'un décompte de références, alors qu'un objet agrégé doit à la fois un décompte de références pour l'inconnu intérieur et un pointeur vers l'inconnu externe.
L'avantage de l'utilisation de CComPolyObject est que vous éviter d'avoir les CComAggObject et CComObject dans votre module pour gérer les affaires agrégés et non agrégées. Un seul objet CComPolyObject gère les deux cas. Cela ne signifie qu'une seule copie de la vtable et une copie des fonctions existent dans votre module. Si votre vtable est importante, cela peut réduire considérablement la taille de votre module. Toutefois, si votre vtable est petite, à l'aide de CComPolyObject peut entraîner une taille légèrement plus grande du module parce qu'il n'est pas optimisé pour un objet agrégé ou non agrégée, comme sont CComAggObject et CComObject.
La macro DECLARE_POLY_AGGREGATABLE est automatiquement ajoutée à votre définition de classe par l'Assistant objet ATL lorsque vous créez un contrôle complet ou Internet Explorer. Pour plus d'informations sur l'Assistant, consultez création d'un projet ATL.