La classe CObject
Classe de base principale pour la bibliothèque MFC (Microsoft Foundation Class).
Syntaxe
class AFX_NOVTABLE CObject
Membres
Constructeurs protégés
Nom | Description |
---|---|
CObject::CObject |
Constructeur par défaut. |
Méthodes publiques
Nom | Description |
---|---|
CObject::AssertValid |
Valide l’intégrité de cet objet. |
CObject::Dump |
Produit un vidage de diagnostic de cet objet. |
CObject::GetRuntimeClass |
Retourne la CRuntimeClass structure correspondant à la classe de cet objet. |
CObject::IsKindOf |
Teste la relation de cet objet à une classe donnée. |
CObject::IsSerializable |
Tests pour voir si cet objet peut être sérialisé. |
CObject::Serialize |
Charge ou stocke un objet depuis/vers une archive. |
Opérateurs publics
Nom | Description |
---|---|
CObject::operator delete |
Opérateur spécial delete . |
CObject::operator new |
Opérateur spécial new . |
Notes
Il sert de racine non seulement pour les classes de bibliothèque telles que CFile
et CObList
, mais aussi pour les classes que vous écrivez. CObject
fournit des services de base, notamment
- Prise en charge de la sérialisation
- Informations sur la classe d’exécution
- Sortie de diagnostic d’objet
- Compatibilité avec les classes de collection
CObject
ne prend pas en charge plusieurs héritages. Vos classes dérivées ne peuvent avoir qu’une CObject
seule classe de base et qui CObject
doit être la plus à gauche dans la hiérarchie. Toutefois, il est permis d’avoir des structures et des CObject
classes non dérivées dans des branches d’héritage multiples de droite.
Vous réaliserez des avantages majeurs de CObject
la dérivation si vous utilisez certaines des macros facultatives dans votre implémentation et déclarations de classe.
Les macros de premier niveau et DECLARE_DYNAMIC
IMPLEMENT_DYNAMIC
, autorisent l’accès au temps d’exécution au nom de la classe et à sa position dans la hiérarchie. Cela permet, à son tour, un dumping de diagnostic significatif.
Les macros de deuxième niveau et IMPLEMENT_SERIAL
, DECLARE_SERIAL
incluent toutes les fonctionnalités des macros de premier niveau et permettent à un objet d’être « sérialisé » vers et à partir d’une « archive ».
Pour plus d’informations sur la dérivation des classes Microsoft Foundation et des classes C++ en général et à l’utilisation CObject
, consultez Utilisation de CObject et de sérialisation.
Hiérarchie d'héritage
CObject
Spécifications
En-tête : afx.h
CObject::AssertValid
Valide l’intégrité de cet objet.
virtual void AssertValid() const;
Notes
AssertValid
effectue une vérification de validité sur cet objet en vérifiant son état interne. Dans la version de débogage de la bibliothèque, AssertValid
peut affirmer, puis mettre fin au programme avec un message qui répertorie le numéro de ligne et le nom de fichier où l’assertion a échoué.
Lorsque vous écrivez votre propre classe, vous devez remplacer la AssertValid
fonction pour fournir des services de diagnostic pour vous-même et d’autres utilisateurs de votre classe. La substitution AssertValid
appelle généralement la AssertValid
fonction de sa classe de base avant de vérifier les membres de données uniques à la classe dérivée.
Étant donné qu’il AssertValid
s’agit d’une const
fonction, vous n’êtes pas autorisé à modifier l’état de l’objet pendant le test. Vos propres fonctions de classe AssertValid
dérivée ne doivent pas lever d’exceptions, mais doivent plutôt affirmer s’ils détectent des données d’objet non valides.
La définition de « validité » dépend de la classe de l’objet. En règle générale, la fonction doit effectuer un « contrôle peu profond ». Autrement dit, si un objet contient des pointeurs vers d’autres objets, il doit vérifier si les pointeurs ne sont pas NULL
, mais il ne doit pas effectuer de test de validité sur les objets référencés par les pointeurs.
Exemple
Consultez CObList::CObList
la liste de la CAge
classe utilisée dans tous les CObject
exemples.
void CAge::AssertValid() const
{
CObject::AssertValid();
ASSERT(m_years > 0);
ASSERT(m_years < 105);
}
Pour obtenir un autre exemple, consultez AfxDoForAllObjects
.
CObject::CObject
Ces fonctions sont les constructeurs standard CObject
.
CObject();
CObject(const CObject& objectSrc);
Paramètres
objectSrc
Référence à une autre CObject
Notes
La version par défaut est automatiquement appelée par le constructeur de votre classe dérivée.
Si votre classe est sérialisable (elle incorpore la IMPLEMENT_SERIAL
macro), vous devez disposer d’un constructeur par défaut (constructeur sans argument) dans votre déclaration de classe. Si vous n’avez pas besoin d’un constructeur par défaut, déclarez un constructeur privé ou protégé « vide ». Pour plus d’informations, consultez Utilisation CObject
.
Le constructeur de copie de classe par défaut C++ standard effectue une copie membre par membre. La présence du constructeur de copie privée CObject
garantit un message d’erreur du compilateur si le constructeur de copie de votre classe est nécessaire, mais pas disponible. Fournissez un constructeur de copie si votre classe requiert cette fonctionnalité.
Exemple
Consultez CObList::CObList
la liste de la CAge
classe utilisée dans les CObject
exemples.
// Create a CAge object using the default constructor.
CAge age1;
// Create a CAge object using the copy constructor.
CAge age2(age1);
CObject::Dump
Vide le contenu de votre objet sur un CDumpContext
objet.
virtual void Dump(CDumpContext& dc) const;
Paramètres
dc
Contexte de vidage de diagnostic pour le vidage, généralement afxDump
.
Notes
Lorsque vous écrivez votre propre classe, vous devez remplacer la Dump
fonction pour fournir des services de diagnostic pour vous-même et d’autres utilisateurs de votre classe. La substitution Dump
appelle généralement la Dump
fonction de sa classe de base avant d’imprimer des membres de données uniques à la classe dérivée. CObject::Dump
imprime le nom de la classe si votre classe utilise la ou IMPLEMENT_SERIAL
la IMPLEMENT_DYNAMIC
macro.
Remarque
Votre Dump
fonction ne doit pas imprimer un caractère de ligne à la fin de sa sortie.
Dump
les appels n’ont de sens que dans la version de débogage de la bibliothèque de classes Microsoft Foundation. Vous devez crocheter les appels, les déclarations de fonction et les implémentations de fonction avec #ifdef _DEBUG
, #endif
instructions pour la compilation conditionnelle.
Étant Dump
donné qu’il s’agit d’une const
fonction, vous n’êtes pas autorisé à modifier l’état de l’objet pendant le vidage.
L’opérateur CDumpContext
d’insertion (<<) appelle Dump
lorsqu’un CObject
pointeur est inséré.
Dump
autorise uniquement le dumping « acyclique » des objets. Vous pouvez vider une liste d’objets, par exemple, mais si l’un des objets est la liste elle-même, vous allez éventuellement dépasser la pile.
Exemple
Consultez CObList::CObList
la liste de la CAge
classe utilisée dans tous les CObject
exemples.
void CAge::Dump(CDumpContext& dc) const
{
CObject::Dump(dc);
dc << _T("Age = ") << m_years;
}
CObject::GetRuntimeClass
Retourne la CRuntimeClass
structure correspondant à la classe de cet objet.
virtual CRuntimeClass* GetRuntimeClass() const;
Valeur de retour
Pointeur vers la CRuntimeClass
structure correspondant à la classe de cet objet ; jamais NULL
.
Notes
Il existe une CRuntimeClass
structure pour chaque CObject
classe dérivée. Les membres de la structure sont les suivants :
LPCSTR m_lpszClassName
Chaîne terminée par null contenant le nom de la classe ASCII.int m_nObjectSize
Taille de l’objet, en octets. Si l’objet a des membres de données qui pointent vers la mémoire allouée, la taille de cette mémoire n’est pas incluse.UINT m_wSchema
Numéro de schéma ( -1 pour les classes non modifiables). Consultez laIMPLEMENT_SERIAL
macro pour obtenir une description du numéro de schéma.CObject* (PASCAL* m_pfnCreateObject)()
Pointeur de fonction vers le constructeur par défaut qui crée un objet de votre classe (valide uniquement si la classe prend en charge la création dynamique ; sinon, retourneNULL
).CRuntimeClass* (PASCAL* m_pfn_GetBaseClass )()
Si votre application est liée dynamiquement à la version AFXDLL de MFC, pointeur vers une fonction qui retourne laCRuntimeClass
structure de la classe de base.CRuntimeClass* m_pBaseClass
Si votre application est liée statiquement à MFC, pointeur vers laCRuntimeClass
structure de la classe de base.
Cette fonction nécessite l’utilisation de la macro , IMPLEMENT_DYNCREATE
ou IMPLEMENT_SERIAL
de la IMPLEMENT_DYNAMIC
macro dans l’implémentation de classe. Sinon, vous obtiendrez des résultats incorrects.
Exemple
Consultez CObList::CObList
la liste de la CAge
classe utilisée dans tous les CObject
exemples.
CAge a(21);
CRuntimeClass* prt = a.GetRuntimeClass();
ASSERT(strcmp(prt->m_lpszClassName, "CAge") == 0);
CObject::IsKindOf
Teste la relation de cet objet à une classe donnée.
BOOL IsKindOf(const CRuntimeClass* pClass) const;
Paramètres
pClass
Pointeur vers une CRuntimeClass
structure associée à votre CObject
classe dérivée.
Valeur de retour
Différent de zéro si l’objet correspond à la classe ; sinon 0.
Notes
Cette fonction teste pClass
si (1) il s’agit d’un objet de la classe spécifiée ou (2) qu’il s’agit d’un objet d’une classe dérivée de la classe spécifiée. Cette fonction ne fonctionne que pour les classes déclarées avec la macro , DECLARE_DYNCREATE
ou DECLARE_SERIAL
.DECLARE_DYNAMIC
N’utilisez pas cette fonction en grande partie, car elle défait la fonctionnalité de polymorphisme C++. Utilisez plutôt des fonctions virtuelles.
Exemple
Consultez CObList::CObList
la liste de la CAge
classe utilisée dans tous les CObject
exemples.
CAge a(21); // Must use IMPLEMENT_DYNAMIC, IMPLEMENT _DYNCREATE, or
// IMPLEMENT_SERIAL
ASSERT(a.IsKindOf(RUNTIME_CLASS(CAge)));
ASSERT(a.IsKindOf(RUNTIME_CLASS(CObject)));
CObject::IsSerializable
Teste si cet objet est éligible à la sérialisation.
BOOL IsSerializable() const;
Valeur de retour
Différent de zéro si cet objet peut être sérialisé ; sinon 0.
Notes
Pour qu’une classe soit sérialisable, sa déclaration doit contenir la DECLARE_SERIAL
macro et l’implémentation doit contenir la IMPLEMENT_SERIAL
macro.
Remarque
Ne remplacez pas cette fonction.
Exemple
Consultez CObList::CObList
la liste de la CAge
classe utilisée dans tous les CObject
exemples.
CAge a(21);
ASSERT(a.IsSerializable());
CObject::operator delete
Pour la version Release de la bibliothèque, l’opérateur delete
libère la mémoire allouée par l’opérateur new
.
void PASCAL operator delete(void* p);
void PASCAL operator delete(
void* p,
void* pPlace);
void PASCAL operator delete(
void* p,
LPCSTR lpszFileName,
int nLine);
Notes
Dans la version de débogage, l’opérateur delete
participe à un schéma de supervision d’allocation conçu pour détecter les fuites de mémoire.
Si vous utilisez la ligne de code
#define new DEBUG_NEW
avant l’une de vos implémentations dans un . Fichier CPP, puis la troisième version de sera utilisée, stockant le nom de fichier et le numéro de delete
ligne dans le bloc alloué pour la création de rapports ultérieures. Vous n’avez pas à vous soucier de fournir les paramètres supplémentaires ; une macro s’occupe de cela pour vous.
Même si vous n’utilisez DEBUG_NEW
pas en mode Débogage, vous obtenez toujours la détection des fuites, mais sans les rapports de ligne de ligne de fichier source décrits ci-dessus.
Si vous substituez des opérateurs new
et delete
que vous perdez cette fonctionnalité de diagnostic.
Exemple
Consultez CObList::CObList
la liste de la CAge
classe utilisée dans les CObject
exemples.
void CAge::operator delete(void* p)
{
free(p);
}
void CAge::operator delete(void *p, LPCSTR lpszFileName, int nLine)
{
UNREFERENCED_PARAMETER(lpszFileName);
UNREFERENCED_PARAMETER(nLine);
free(p);
}
CObject::operator new
Pour la version Release de la bibliothèque, l’opérateur new
effectue une allocation de mémoire optimale de manière similaire à malloc
.
void* PASCAL operator new(size_t nSize);
void* PASCAL operator new(size_t, void* p);
void* PASCAL operator new(
size_t nSize,
LPCSTR lpszFileName,
int nLine);
Notes
Dans la version de débogage, l’opérateur new
participe à un schéma de supervision d’allocation conçu pour détecter les fuites de mémoire.
Si vous utilisez la ligne de code
#define new DEBUG_NEW
avant l’une de vos implémentations dans un . Fichier CPP, puis la deuxième version de sera utilisée, stockant le nom de fichier et le numéro de new
ligne dans le bloc alloué pour la création de rapports ultérieures. Vous n’avez pas à vous soucier de fournir les paramètres supplémentaires ; une macro s’occupe de cela pour vous.
Même si vous n’utilisez DEBUG_NEW
pas en mode Débogage, vous obtenez toujours la détection des fuites, mais sans les rapports de ligne de ligne de fichier source décrits ci-dessus.
Remarque
Si vous remplacez cet opérateur, vous devez également remplacer delete
. N’utilisez pas la fonction de bibliothèque _new_handler
standard.
Exemple
Consultez CObList::CObList
la liste de la CAge
classe utilisée dans les CObject
exemples.
void* CAge::operator new(size_t nSize)
{
return malloc(nSize);
}
void* CAge::operator new(size_t nSize, LPCSTR lpszFileName, int nLine)
{
UNREFERENCED_PARAMETER(lpszFileName);
UNREFERENCED_PARAMETER(nLine);
return malloc(nSize);
}
CObject::Serialize
Lit ou écrit cet objet dans une archive.
virtual void Serialize(CArchive& ar);
Paramètres
ar
Objet CArchive
à sérialiser vers ou depuis.
Notes
Remplacez Serialize
chaque classe que vous envisagez de sérialiser. La substitution Serialize
doit d’abord appeler la Serialize
fonction de sa classe de base.
Vous devez également utiliser la DECLARE_SERIAL
macro dans votre déclaration de classe, et vous devez utiliser la IMPLEMENT_SERIAL
macro dans l’implémentation.
Utilisez CArchive::IsLoading
ou CArchive::IsStoring
déterminez si l’archivage est chargé ou stocké.
Serialize
est appelé par CArchive::ReadObject
et CArchive::WriteObject
. Ces fonctions sont associées à l’opérateur CArchive
d’insertion ( <<
) et à l’opérateur d’extraction ( >>
).
Pour obtenir des exemples de sérialisation, consultez l’article Sérialisation d’un objet.
Exemple
Consultez CObList::CObList
la liste de la CAge
classe utilisée dans tous les CObject
exemples.
void CAge::Serialize(CArchive& ar)
{
CObject::Serialize(ar);
if(ar.IsStoring())
ar << m_years;
else
ar >> m_years;
}