Temp&latelt; -KlasseThreadModel ≫
CComObjectRootEx Klasse: öffentliche CComObjectRootBase
Parameter
ThreadModel
Die Klasse, deren Methoden das gewünschte threading-Modell implementieren. Sie können explizit das threading-Modell, indem Sie ThreadModel auf CComSingleThreadModel, Suchenoder CComMultiThreadModelNoCS. Standardmodell Thread des Servers können Sie übernehmen, indem Sie ThreadModel auf CComObjectThreadModel oder CComGlobalsThreadModel.
CComObjectRootEx behandelt Verweis Count Objektverwaltung für zusammengesetzten und aggregierten Objekte. Es hält den Verweiszähler des Objekts, wenn das Objekt nicht aggregiert werden und enthält den Zeiger auf die äußere unbekannte, wenn das Objekt gerade zusammengesetzt wird. Für die aggregierten Objekte können CComObjectRootEx Methoden verwendet werden, behandeln das Scheitern des inneren Objekts zu erstellen, und um das äußere Objekt vor versehentlichem Löschen zu schützen, wenn innere Schnittstellen freigegeben werden oder das innere Objekt gelöscht wird.
Eine Klasse, die einen COM-Server implementiert muss von CComObjectRootEx oder CComObjectRoot erben.
Wenn die Klassendefinition das DECLARE_POLY_AGGREGATABLE -Makro gibt, erstellt ATL eine Instanz des CComPolyObjectlt;Debugfenster > wenn IClassFactory::CreateInstance aufgerufen wird. Während der Erstellung wird der Wert des äußeren unbekannten überprüft. Wenn es NULList, ist für einen zusammengesetzten Objekt IUnknown implementiert. Wenn die äußere unbekannte nicht NULList, wird IUnknown für eine aggregierte Objekt implementiert.
Wenn Ihre Klasse nicht das DECLARE_POLY_AGGREGATABLE -Makro angegeben wird, erstellt ATL eine Instanz des CComObjectlt;Debugfenster > für die aggregierten Objekte oder eine Instanz von CComAggObject <CYourClass> für zusammengesetzten Objekte.
Der Vorteil der Verwendung CComPolyObject ist, dass Sie vermeiden, dass CComAggObject und CComObject im Modul, die aggregierte und zusammengesetzten Fälle zu behandeln. Ein einzelnes CComPolyObject -Objekt behandelt die beiden Fälle. Daher vorhanden nur eine Kopie des der Vtable und eine Kopie der Funktionen im Modul. Wenn Ihre Vtable groß ist, kann dies Ihre Modulgröße erheblich verringern. Jedoch wenn Ihre Vtable klein ist, kann mit CComPolyObject in einer etwas größeren Modulgröße führen, da es nicht für eine aggregierte oder zusammengesetzten Objekts optimiert ist CComAggObject und CComObject sind.
Das DECLARE_POLY_AGGREGATABLE -Makro wird durch den Assistenten für ATL-Objekte automatisch auf die Klassendefinition hinzugefügt, beim Erstellen einen Vollzugriff oder Internet Explorer-Steuerelement.
Wenn Ihr Objekt aggregiert wird, IUnknown CComAggObject oder CComPolyObjectimplementiert ist. Diese Klassen delegieren QueryInterface, AddRefund Release Aufrufe von CComObjectRootEx OuterQueryInterface, OuterAddRefund OuterRelease , die äußere Unbekannte zu übermitteln. In der Regel, Sie CComObjectRootEx::FinalConstruct in Ihrer Klasse keine aggregierten Objekte erstellen überschreiben, und überschreiben CComObjectRootEx::FinalRelease zu aggregierten Objekte frei.
Wenn das Objekt nicht aggregiert wird, ist von CComObject oder CComPolyObject IUnknown implementiert. In diesem Fall sind Aufrufe QueryInterface, AddRefund Release CComObjectRootEx InternalQueryInterface, InternalAddRefund InternalRelease delegiert die tatsächlichen Vorgänge durchführen.
# include lt;atlcom.h>
Siehe auch&Nbsp;CComAggObject, CComObject, CComPolyObject