Implementieren von CComObject, CComAggObject und CComPolyObject

Die Vorlagenklassen CComObject, CComAggObject und CComPolyObject sind immer die abgeleiteten Klassen in der Vererbungskette. Es liegt in ihrer Verantwortung, alle Methoden in IUnknown: QueryInterface, , AddRefund Release. Darüber hinaus stellen (CComPolyObjectbei Verwendung für aggregierte Objekte) die speziellen Verweiszählungen und QueryInterface Semantik bereit, CComAggObject die für das innere Unbekannte erforderlich sind.

Ob CComObject, oder wird verwendet, hängt davon ab, CComAggObjectCComPolyObject ob Sie eins (oder keine) der folgenden Makros deklarieren:

Makro	Effekt
DECLARE_NOT_AGGREGATABLE	Verwendet CComObjectimmer .
DECLARE_AGGREGATABLE	Verwendet CComAggObject , wenn das Objekt aggregiert wird und CComObject nicht. CComCoClass enthält dieses Makro, sodass keines der DECLARE_*_AGGREGATABLE Makros in Ihrer Klasse deklariert wird, ist dies die Standardeinstellung.
DECLARE_ONLY_AGGREGATABLE	Verwendet CComAggObjectimmer . Gibt einen Fehler zurück, wenn das Objekt nicht aggregiert wird.
DECLARE_POLY_AGGREGATABLE	ATL erstellt eine Instanz von CComPolyObject<CYourClass> , wenn IClassFactory::CreateInstance sie aufgerufen wird. Während der Erstellung wird der Wert des äußeren Unbekannten überprüft. Wenn es NULL ist, IUnknown wird für ein nicht aggregiertes Objekt implementiert. Wenn das äußere Unbekannte nicht NULL ist, IUnknown wird für ein aggregiertes Objekt implementiert.

Der Vorteil der Verwendung CComAggObject und CComObject ist, dass die Implementierung IUnknown für die Art des erstellten Objekts optimiert ist. Ein nicht aggregiertes Objekt benötigt beispielsweise nur eine Verweisanzahl, während ein aggregiertes Objekt sowohl eine Verweisanzahl für das innere Unbekannte als auch einen Zeiger auf das äußere Unbekannte benötigt.

Der Vorteil der Verwendung CComPolyObject besteht darin, dass Sie sowohl als auch CComAggObjectCComObject in Ihrem Modul vermeiden, die aggregierten und nicht aggregierten Fälle zu verarbeiten. Ein einzelnes CComPolyObject Objekt behandelt beide Fälle. Dies bedeutet, dass nur eine Kopie der vtable und eine Kopie der Funktionen in Ihrem Modul vorhanden ist. Wenn die vtable groß ist, kann dies die Modulgröße erheblich verringern. Wenn die vtable jedoch klein ist, kann die Verwendung CComPolyObject zu einer etwas größeren Modulgröße führen, da sie nicht für ein aggregiertes oder nicht aggregiertes Objekt optimiert ist, wie es sind CComAggObject und CComObject.

Siehe auch

Grundlagen von ARL COM-Objekten
Aggregation und Klassenfactory-Makros