Anteckning
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
Mallklasserna CComObject, CComAggObject och CComPolyObject är alltid de mest härledda klasserna i arvskedjan. Det är deras ansvar att hantera alla metoder i IUnknown: QueryInterface, AddRefoch Release. Dessutom CComAggObject och CComPolyObject (när de används för aggregerade objekt) ger den särskilda referensräkning och QueryInterface semantik som krävs för det inre okända.
Om CComObject, CComAggObjecteller CComPolyObject används beror på om du deklarerar ett (eller inget) av följande makron:
| Makro | Effekt |
|---|---|
| DEKLARERA_EJ_AGGERBAR | Använder CComObjectalltid . |
| DECLARE_AGGREGATABLE | Används CComAggObject om objektet aggregeras och CComObject om det inte är det.
CComCoClass innehåller det här makrot, så om inget av DECLARE_*_AGGREGATABLE makron deklareras i klassen är detta standardvärdet. |
| DEKLARERA_ENDAST_AGGREGERBAR | Använder CComAggObjectalltid . Returnerar ett fel om objektet inte aggregeras. |
| DECLARE_POLY_AGGREGATABLE | ATL skapar en instans av CComPolyObject<CYourClass> när IClassFactory::CreateInstance den anropas. Under skapandet kontrolleras värdet för det yttre okända. Om det är NULL IUnknown implementeras för ett icke-aggregerat objekt. Om det yttre okända inte är NULL IUnknown implementeras för ett aggregerat objekt. |
Fördelen med att använda CComAggObject och CComObject är att implementeringen av IUnknown är optimerad för den typ av objekt som skapas. Ett icke-aggregerat objekt behöver till exempel bara ett referensantal, medan ett aggregerat objekt behöver både ett referensantal för det inre okända och en pekare till det yttre okända.
Fördelen med att använda CComPolyObject är att du undviker att ha både CComAggObject och CComObject i din modul för att hantera aggregerade och icke-aggregerade fall. Ett enda CComPolyObject objekt hanterar båda fallen. Det innebär att det bara finns en kopia av den virtuella tabellen och en kopia av funktionerna i modulen. Om din vtable är stor kan det avsevärt minska storleken på din modul. Men om din vtable är liten kan användning av CComPolyObject resultera i en något större modulstorlek eftersom den inte är optimerad för ett aggregerat eller icke-aggregerat objekt, till skillnad från CComAggObject och CComObject.
Se även
Grunderna i ATL COM-objekt
Aggregerings- och klassfabriksmakron