Les classes d'interface sont très largement utilisées dans les programmes C ++. Mais, malheureusement, des erreurs sont souvent commises lors de l'implémentation de solutions basées sur des classes d'interface. L'article décrit comment concevoir correctement les classes d'interface; plusieurs options sont envisagées. L'utilisation de pointeurs intelligents est décrite en détail. Un exemple d'implémentation d'une classe d'exception et d'un modèle de classe de collection basé sur des classes d'interface est donné.

Table des matières

Présentation

Une classe d'interface est une classe qui n'a pas de données et se compose principalement de fonctions purement virtuelles. Cette solution vous permet de séparer complètement l'implémentation de l'interface - le client utilise la classe d'interface - à un autre endroit, une classe dérivée est créée dans laquelle les fonctions purement virtuelles sont redéfinies et la fonction d'usine est définie. Les détails de l'implémentation sont complètement cachés au client. De cette façon, une véritable encapsulation est implémentée, ce qui est impossible avec la classe habituelle. Vous pouvez lire sur les classes d'interface de Scott Meyers [Meyers2]. Les classes d'interface sont également appelées classes de protocole.

L'utilisation de classes d'interface vous permet d'affaiblir les dépendances entre les différentes parties du projet, ce qui simplifie le développement de l'équipe et réduit le temps de compilation / assemblage. Les classes d'interface facilitent la mise en œuvre de solutions flexibles et dynamiques lorsque les modules sont chargés de manière sélective lors de l'exécution. L'utilisation des classes d'interface en tant que bibliothèque d'interface (API) (SDK) simplifie la solution des problèmes de compatibilité binaire.

Les classes d'interface sont utilisées assez largement, avec leur aide, elles implémentent l'interface (API) des bibliothèques (SDK), l'interface des plug-ins (plugins) et bien plus encore. De nombreux modèles de Gang of Four [GoF] sont naturellement implémentés à l'aide de classes d'interface. Les classes d'interface incluent les interfaces COM. Mais, malheureusement, des erreurs sont souvent commises lors de l'implémentation de solutions basées sur des classes d'interface. Essayons de clarifier ce problème.

1. Fonctions membres spéciales, création et suppression d'objets

Cette section décrit brièvement un certain nombre de fonctionnalités C ++ que vous devez connaître pour bien comprendre les solutions proposées pour les classes d'interface.

1.1. Fonctions spéciales des membres

Si le programmeur n'a pas défini les fonctions membres de la classe dans la liste suivante - le constructeur par défaut, le constructeur de copie, l'opérateur d'affectation de copie, le destructeur - alors le compilateur peut le faire pour lui. C ++ 11 a ajouté un constructeur de déplacement et un opérateur d'affectation de déplacement à cette liste. Ces fonctions membres sont appelées fonctions membres spéciales. Ils ne sont générés que s'ils sont utilisés et des conditions supplémentaires spécifiques à chaque fonction sont remplies. Nous attirons l'attention sur le fait que cette utilisation peut s'avérer assez cachée (par exemple lors de l'implémentation de l'héritage). Si la fonction requise ne peut pas être générée, une erreur est générée. (À l'exception des opérations de relocalisation, elles sont remplacées par des opérations de copie.) Les fonctions membres générées par le compilateur sont publiques et intégrables.

Les fonctions membres spéciales ne sont pas héritées, si une fonction membre spéciale est requise dans la classe dérivée, le compilateur essaiera toujours de la générer; la présence de la fonction membre correspondante définie dans la classe de base par le programmeur n'affecte pas cela.

Le programmeur peut interdire la génération de fonctions membres spéciales, en C ++ 11 il est nécessaire d'utiliser la construction "=delete" lors de la déclaration, en C ++ 98 déclarer la fonction membre correspondante privée et non définir. Dans l'héritage de classe, l'interdiction de générer une fonction membre spéciale faite dans la classe de base s'applique à toutes les classes dérivées.

Si le programmeur est à l'aise avec les fonctions membres générées par le compilateur, alors en C ++ 11, il peut l'indiquer explicitement, et pas simplement supprimer la déclaration. Pour ce faire, vous devez utiliser la construction "=default" lors de la déclaration, tandis que le code est mieux lu et que des fonctionnalités supplémentaires apparaissent liées à la gestion du niveau d'accès.

Des détails sur les fonctions spéciales des membres peuvent être trouvés dans [Meyers3].

1.2. Création et suppression d'objets - détails de base

La création et la suppression d'objets à l'aide des opérateurs new/delete est une opération deux-en-un typique. Lors de l'appel de new , la mémoire est d'abord allouée à l'objet. Si la sélection réussit, le constructeur est appelé. Si le constructeur lève une exception, la mémoire allouée est libérée. Lorsque l'opérateur de delete est appelé, tout se passe dans l'ordre inverse: d'abord, le destructeur est appelé, puis la mémoire est libérée. Le destructeur ne doit pas lever d'exceptions.

Si le new opérateur est utilisé pour créer un tableau d'objets, la mémoire est d'abord allouée à l'ensemble du tableau. Si la sélection réussit, le constructeur par défaut est appelé pour chaque élément du tableau à partir de zéro. Si un constructeur lève une exception, alors pour tous les éléments créés du tableau, le destructeur est appelé dans l'ordre inverse de l'appel du constructeur, la mémoire allouée est libérée. Pour supprimer un tableau, vous devez appeler l'opérateur delete[] (appelé l'opérateur delete pour les tableaux), et pour tous les éléments du tableau, le destructeur est appelé dans l'ordre inverse de l'appel du constructeur, puis la mémoire allouée est libérée.

Attention! Vous devez appeler la forme correcte de l'opérateur de delete , selon qu'un seul objet ou tableau est supprimé. Cette règle doit être strictement respectée, sinon vous pouvez obtenir un comportement indéfini, c'est-à-dire que tout peut arriver: fuites de mémoire, crash, etc. Voir [Meyers2] pour plus de détails.

Les fonctions d'allocation de mémoire standard ne std::bad_alloc à satisfaire la requête, std::bad_alloc une exception de type std::bad_alloc .

Il est sûr d'appliquer n'importe quelle forme de l'opérateur de delete à un pointeur nul.

Dans la description ci-dessus, une clarification est nécessaire. Pour les soi-disant types triviaux (types intégrés, structures de style C), le constructeur ne peut pas être appelé et le destructeur ne fait en aucun cas quoi que ce soit. Voir également la section 1.6.

1.3. Niveau d'accès destructeur

Lorsque l'opérateur de delete est appliqué à un pointeur sur une classe, le destructeur de cette classe doit être disponible au point d'appel de delete . (Il existe une exception à cette règle, abordée dans la section 1.6.) Ainsi, en sécurisant ou en fermant le destructeur, le programmeur interdit l'utilisation de l'opérateur de delete lorsque le destructeur n'est pas disponible. Souvenez-vous que si aucun destructeur n'est défini dans la classe, le compilateur le fera seul et ce destructeur sera ouvert (voir section 1.1).

1.4. Créez et supprimez en un seul module

Si le new opérateur a créé un objet, alors l'opérateur de delete doit se trouver dans le même module pour le delete . Au figuré, "mettez-le là où vous l'avez pris". Cette règle est bien connue, voir par exemple [Sutter / Alexandrescu]. Si cette règle est violée, une «non-concordance» des fonctions d'allocation et de libération de mémoire peut se produire, ce qui, en règle générale, entraîne une interruption anormale du programme.

1.5. Suppression polymorphe

Si vous concevez une hiérarchie polymorphe de classes dont les instances sont supprimées à l'aide de l'opérateur de delete , il doit y avoir un destructeur virtuel ouvert dans la classe de base, cela garantit que le destructeur du type réel de l'objet est appelé lorsque l'opérateur de delete est appliqué au pointeur sur la classe de base. Si cette règle est violée, un appel au destructeur de classe de base peut se produire, ce qui peut entraîner une fuite de ressources.

1.6. Suppression lorsque la déclaration de classe est incomplète

Le caractère omnivore de l'opérateur de delete peut créer certains problèmes; il peut être appliqué à un pointeur de type void* ou à un pointeur sur une classe qui a une déclaration incomplète (préemptive). Dans ce cas, aucune erreur ne se produit, seul l'appel au destructeur est ignoré, seule la fonction de libération de la mémoire est appelée. Prenons un exemple:

 class X; //   X* CreateX(); void Foo() {    X* p = CreateX();    delete p; } 

Ce code se compile même si une déclaration de classe X complète n'est pas disponible sur le pair de delete numérotation. Vrai, lors de la compilation (Visual Studio), un avertissement est émis:

warning C4150: deletion of pointer to incomplete type 'X'; no destructor called

S'il existe une implémentation de X et CreateX() , le code est CreateX() , si CreateX() renvoie un pointeur vers l'objet créé par le new opérateur, alors l'appel Foo() correctement exécuté, le destructeur n'est pas appelé. Il est clair que cela peut conduire à un épuisement des ressources, donc encore une fois sur la nécessité de faire attention aux avertissements.

Cette situation n'est pas farfelue, elle peut facilement survenir lors de l'utilisation de classes telles que des pointeurs intelligents ou des classes de descripteurs. Scott Meyers traite de ce problème dans [Meyers3].

2. Fonctions purement virtuelles et classes abstraites

Le concept de classes d'interface est basé sur des concepts C ++ tels que les fonctions virtuelles pures et les classes abstraites.

2.1. Fonctions virtuelles pures

Une fonction virtuelle déclarée à l'aide de la construction "=0" est appelée virtuelle pure.

 class X { // ...    virtual void Foo() = 0; }; 

Contrairement à une fonction virtuelle classique, une fonction purement virtuelle ne peut pas être définie (à l'exception du destructeur, voir section 2.3), mais elle doit être redéfinie dans l'une des classes dérivées.

Des fonctions purement virtuelles peuvent être définies. Emblem Sutter propose plusieurs utilisations utiles pour cette fonction [Shutter].

2.2. Classes abstraites

Une classe abstraite est une classe qui a au moins une fonction purement virtuelle. Une classe dérivée d'une classe abstraite et ne remplaçant pas au moins une fonction purement virtuelle sera également abstraite. La norme C ++ interdit la création d'instances d'une classe abstraite; vous ne pouvez créer que des instances de dérivés de classes non abstraites. Ainsi, une classe abstraite est créée pour être utilisée comme classe de base. Par conséquent, si un constructeur est défini dans une classe abstraite, alors cela n'a pas de sens de le rendre ouvert, il doit être protégé.

2.3. Destructeur virtuel pur

Dans certains cas, il est conseillé de faire un destructeur virtuel pur. Mais cette solution a deux fonctionnalités.

1. Un destructeur purement virtuel doit être défini. (La définition par défaut est généralement utilisée, c'est-à-dire en utilisant la construction "=default" .) Le destructeur de classe dérivé appelle des destructeurs de classe de base tout au long de la chaîne d'héritage et, par conséquent, la file d'attente est garantie d'atteindre la racine - un destructeur purement virtuel.
2. Si le programmeur n'a pas redéfini un destructeur virtuel pur dans la classe dérivée, le compilateur le fera pour lui (voir section 1.1). Ainsi, une classe dérivée d'une classe abstraite avec un destructeur purement virtuel peut perdre son caractère abstrait sans écraser explicitement le destructeur.

Un exemple d'utilisation d'un destructeur virtuel pur peut être trouvé dans la section 4.4.

3. Classes d'interface

Une classe d'interface est une classe abstraite qui n'a pas de données et se compose principalement de fonctions purement virtuelles. Une telle classe peut avoir des fonctions virtuelles ordinaires (non purement virtuelles), par exemple, un destructeur. Il peut également y avoir des fonctions membres statiques, telles que des fonctions d'usine.

3.1. Implémentations

Une implémentation d'une classe d'interface sera appelée une classe dérivée dans laquelle des fonctions purement virtuelles sont redéfinies. Il peut y avoir plusieurs implémentations de la même classe d'interface, et deux schémas sont possibles: horizontal, lorsque plusieurs classes différentes héritent de la même classe d'interface, et vertical, lorsque la classe d'interface est la racine de la hiérarchie polymorphe. Bien sûr, il peut y avoir des hybrides.

Le point clé du concept de classes d'interface est la séparation complète de l'interface de l'implémentation - le client ne travaille qu'avec la classe d'interface, l'implémentation n'est pas disponible pour elle.

3.2. Création d'objets

L'inaccessibilité de la classe d'implémentation provoque certains problèmes lors de la création d'objets. Le client doit créer une instance de la classe d'implémentation et obtenir un pointeur sur la classe d'interface via laquelle l'objet sera accessible. Étant donné que la classe d'implémentation n'est pas disponible, vous ne pouvez pas utiliser le constructeur, par conséquent, la fonction d'usine est utilisée, qui est définie du côté de l'implémentation. Cette fonction crée généralement un objet à l'aide du new opérateur et renvoie un pointeur sur l'objet créé, transtypé en pointeur sur une classe d'interface. Une fonction de fabrique peut être un membre statique d'une classe d'interface, mais elle n'est pas nécessaire, par exemple, elle peut être membre d'une classe de fabrique spéciale (qui, à son tour, peut elle-même être une classe d'interface) ou une fonction libre. Une fonction d'usine peut renvoyer non pas un pointeur brut vers une classe d'interface, mais un pointeur intelligent. Cette option est discutée dans les sections 3.3.4 et 4.3.2.

3.3. Supprimer un objet

La suppression d'un objet est une opération extrêmement critique. Une erreur entraîne une fuite de mémoire ou une double suppression, ce qui entraîne généralement un plantage du programme. Ci-dessous, ce problème est considéré aussi détaillé que possible, avec une grande attention portée à la prévention des actions erronées des clients.

Il existe quatre options principales:

1. Utilisation de l'opérateur de delete .
2. Utilisation d'une fonction virtuelle spéciale.
3. Utilisation d'une fonction externe.
4. Suppression automatique à l'aide du pointeur intelligent.

3.3.1. Utilisation de l'opérateur de delete

Pour ce faire, vous devez avoir un destructeur virtuel ouvert dans la classe d'interface. Dans ce cas, l'opérateur de delete , appelé pour un pointeur vers une classe d'interface côté client, fournit un appel au destructeur de la classe d'implémentation. Cette option peut fonctionner, mais il est difficile de la reconnaître comme réussie. Nous recevons des appels des new opérateurs et delete différents côtés de la «barrière», new du côté de l'implémentation, delete du côté client. Et si l'implémentation de la classe d'interface se fait dans un module séparé (ce qui est assez courant), alors nous obtenons une violation de la règle de la section 1.4.

3.3.2. Utilisation d'une fonction virtuelle spéciale

Plus progressive est une autre option: la classe d'interface doit avoir une fonction virtuelle spéciale qui supprime l'objet. Une telle fonction, au final, revient à appeler delete this , mais cela se produit déjà du côté de l'implémentation. Une telle fonction peut être appelée de différentes manières, par exemple, Delete() , mais d'autres options sont également utilisées: Release() , Destroy() , Dispose() , Free() , Close() , etc. En plus de suivre la règle de la section 1.4, cette option présente plusieurs avantages supplémentaires.

1. Vous permet d'utiliser des fonctions personnalisées d'allocation / désallocation de mémoire pour la classe d'implémentation.
2. Vous permet d'implémenter un schéma plus complexe pour contrôler la durée de vie de l'objet d'implémentation, par exemple, à l'aide d'un compteur de référence.

Dans ce mode de réalisation, une tentative de suppression d'un objet à l'aide de l'opérateur de delete peut être compilée et même effectuée, mais il s'agit d'une erreur. Pour l'empêcher dans la classe d'interface, il suffit d'avoir un destructeur protégé vide ou purement virtuel (voir section 1.3). Notez que l'utilisation de l'opérateur de delete peut être assez masquée, par exemple, les pointeurs intelligents standard utilisent l'opérateur de suppression pour supprimer un objet par défaut et le code correspondant est profondément enfoui dans leur implémentation. Un destructeur protégé vous permet de détecter toutes ces tentatives au stade de la compilation.

3.3.3. Utilisation d'une fonction externe

Cette option peut attirer une certaine symétrie des procédures de création et de suppression d'un objet, mais en réalité elle n'a aucun avantage par rapport à la version précédente, mais il existe de nombreux problèmes supplémentaires. Cette option n'est pas recommandée pour une utilisation et n'est pas envisagée à l'avenir.

3.3.4. Suppression automatique à l'aide du pointeur intelligent

Dans ce cas, la fonction d'usine ne renvoie pas un pointeur brut vers une classe d'interface, mais un pointeur intelligent correspondant. Ce pointeur intelligent est créé côté implémentation et encapsule l'objet de suppression, qui supprime automatiquement l'objet implémentation lorsque le pointeur intelligent (ou sa dernière copie) sort du domaine côté client. Dans ce cas, une fonction virtuelle spéciale pour supprimer l'objet d'implémentation peut ne pas être requise, mais un destructeur protégé est toujours nécessaire, il est nécessaire d'empêcher l'utilisation erronée de l'opérateur de delete . (Certes, il convient de noter que la probabilité d'une telle erreur est sensiblement réduite.) Cette option est examinée plus en détail à la section 4.3.2.

3.4. Autres options pour gérer la durée de vie d'une instance d'une classe d'implémentation

Dans certains cas, le client peut recevoir un pointeur vers la classe d'interface, mais ne le possède pas. La gestion de la durée de vie de l'objet d'implémentation est entièrement du côté de l'implémentation. Par exemple, un objet peut être un objet singleton statique (cette solution est typique pour les usines). Un autre exemple est lié à l'interaction bidirectionnelle, voir la section 3.7. Le client ne doit pas supprimer un tel objet, mais un destructeur protégé pour une telle classe d'interface est nécessaire, il est nécessaire d'empêcher l'utilisation erronée de l'opérateur de delete .

3.5. Copier la sémantique

Pour une classe d'interface, la création d'une copie de l'objet d'implémentation à l'aide du constructeur de copie n'est pas possible, donc si la copie est requise, la classe doit avoir une fonction virtuelle qui crée une copie de l'objet d'implémentation et renvoie un pointeur vers la classe d'interface. Une telle fonction est souvent appelée constructeur virtuel et son nom traditionnel est Clone() ou Duplicate() .

L'utilisation de l'opérateur d'affectation de copie n'est pas interdite, mais ne peut pas être considérée comme une bonne idée. L'opérateur d'affectation de copie est toujours associé; il doit être associé au constructeur de copie. L'opérateur généré par le compilateur par défaut n'a pas de sens, il ne fait rien. Il est théoriquement possible de déclarer un opérateur d'affectation purement virtuel avec redéfinition ultérieure, mais l'affectation virtuelle n'est pas une pratique recommandée, des détails peuvent être trouvés dans [Meyers1]. De plus, l'affectation semble très peu naturelle: l'accès aux objets de la classe d'implémentation se fait généralement via un pointeur vers la classe d'interface, donc l'affectation ressemblera à ceci:

 * = *; 

Il est préférable d'interdire à l'opérateur d'affectation, et si nécessaire, une telle sémantique a dans la classe d'interface la fonction virtuelle correspondante.

Il existe deux façons d'interdire l'attribution.

1. Déclarez l'opérateur d'affectation supprimé ( =delete ). Si les classes d'interface forment une hiérarchie, cela suffit pour le faire dans la classe de base. L'inconvénient de cette méthode est qu'elle affecte la classe d'implémentation, l'interdiction s'y applique également.
2. Déclarez une instruction d'affectation protégée avec une définition par défaut ( =default ). Cela n'affecte pas la classe d'implémentation, mais dans le cas d'une hiérarchie de classes d'interface, une telle annonce doit être faite dans chaque classe.

3.6. Constructeur de classe d'interface

Souvent, le constructeur d'une classe d'interface n'est pas déclaré. Dans ce cas, le compilateur génère le constructeur par défaut nécessaire pour implémenter l'héritage (voir section 1.1). Ce constructeur est ouvert, bien que suffisant pour être sécurisé. Si dans la classe d'interface le constructeur copiant est déclaré supprimé ( =delete ), alors la génération par le compilateur du constructeur est supprimée par défaut, et un tel constructeur doit être explicitement déclaré. Il est naturel de le sécuriser avec une définition par défaut ( =default ). En principe, la déclaration d'un tel constructeur protégé peut toujours se faire. Un exemple est dans la section 4.4.

3.7. Interaction bidirectionnelle

Les classes d'interface sont pratiques pour utiliser la communication bidirectionnelle. Si certains modules sont accessibles via des classes d'interface, le client peut également créer des implémentations de certaines classes d'interface et leur transmettre des pointeurs dans le module. Grâce à ces pointeurs, le module peut recevoir des services du client et également transmettre des données ou des notifications au client.

3.8. Pointeurs intelligents

Étant donné que l'accès aux objets de la classe d'implémentation se fait généralement via un pointeur, il est naturel d'utiliser des pointeurs intelligents pour contrôler leur durée de vie. Mais il faut garder à l'esprit que si la deuxième option pour supprimer des objets est utilisée, alors avec le pointeur intelligent standard, il est nécessaire de transférer un suppresseur utilisateur (type) ou une instance de ce type. Si cela n'est pas fait, le pointeur intelligent utilisera l'opérateur de suppression pour supprimer l'objet, et le code ne sera tout simplement pas compilé (grâce au destructeur protégé). Les pointeurs intelligents standard (y compris l'utilisation de dissolvants personnalisés) sont discutés en détail dans [Josuttis], [Meyers3]. Un exemple d'utilisation d'un décapant personnalisé peut être trouvé dans la section 4.3.1.

, , , .

3.9. -

- const. , , -, .

3.10. COM-

COM- , , COM — , COM- , C, , . COM- C++ , COM.

3.11.

(API) (SDK). . -, -, . , (Windows DLL), : -. . , , . LoadLibrary() , -, .

4.

4.1.

, .

 class IBase { protected:    virtual ~IBase() = default; //   public:    virtual void Delete() = 0; //      IBase& operator=(const IBase&) = delete; //   }; 

.

 class IActivatable : public IBase { protected:    ~IActivatable() = default; //   public:    virtual void Activate(bool activate) = 0;    static IActivatable* CreateInstance(); // - }; 

, , . , IBase . , (. 1.3). , .

4.2.

 class Activator : private IActivatable { // ... private:    Activator(); protected:    ~Activator(); public:    void Delete() override;    void Activate(bool activate) override;    friend IActivatable* IActivatable::CreateInstance(); }; Activator::Activator() {/* ... */} Activator::~Activator() {/* ... */} void Activator::Delete() { delete this; } void Activator::Activate(bool activate) {/* ... */} IActivatable* IActivatable::CreateInstance() {    return static_cast<IActivatable*>(new Activator()); } 

, , , - , .

4.3.

4.3.1.

. - ( IBase ):

 struct BaseDeleter {    void operator()(IBase* p) const { p->Delete(); } }; 

std::unique_ptr<> - :

 template <class I> // I —  IBase using UniquePtr = std::unique_ptr<I, BaseDeleter>; 

, , - , UniquePtr .

-:

 template <class I> // I —  - CreateInstance() UniquePtr<I> CreateInstance() {    return UniquePtr<I>(I::CreateInstance()); } 

:

 template <class I> // I —  IBase UniquePtr<I> ToPtr(I* p) {    return UniquePtr<I>(p); } 

std::shared_ptr<> std::unique_ptr<> , , std::shared_ptr<> . Activator .

 auto un1 = CreateInstance<IActivatable>(); un1->Activate(true); auto un2 = ToPtr(IActivatable::CreateInstance()); un2->Activate(true); std::shared_ptr<IActivatable> sh = CreateInstance<IActivatable>(); sh->Activate(true); 

( — -):

 std::shared_ptr<IActivatable> sh2(IActivatable::CreateInstance()); 

std::make_shared<>() , ( ).

: , . : , - . 4.4.

4.3.2.

. -. std::shared_ptr<> , , ( ). std::shared_ptr<> ( ) - , delete . std::shared_ptr<> - ( ) - . .

 #include <memory> class IActivatable; using ActPtr = std::shared_ptr<IActivatable>; //   class IActivatable { protected:    virtual ~IActivatable() = default; //      IActivatable& operator=(const IActivatable&) = default; //   public:    virtual void Activate(bool activate) = 0;    static ActPtr CreateInstance(); // - }; //   class Activator : public IActivatable { // ... public:    Activator();  //      ~Activator(); //      void Activate(bool activate) override; }; Activator::Activator() {/* ... */} Activator::~Activator() {/* ... */} void Activator::Activate(bool activate) {/* ... */} ActPtr IActivatable::CreateInstance() {    return ActPtr(new Activator()); } 

- std::make_shared<>() :

 ActPtr IActivatable::CreateInstance() {    return std::make_shared<Activator>(); } 

std::unique_ptr<> , , - , .

4.4.

C# Java C++ «», . . IBase .

 class IBase { protected:    IBase() = default;    virtual ~IBase() = 0; // ,       virtual void Delete(); //   public:    IBase(const IBase&) = delete;            //      IBase& operator=(const IBase&) = delete; //      struct Deleter        // -    {        void operator()(IBase* p) const { p->Delete(); }    };    friend struct IBase::Deleter; }; 

, Delete() , .

 IBase::~IBase() = default; void IBase::Delete() { delete this; } 

IBase . Delete() , . - IBase . Delete() , - . Delete() , . , 4.3.1.

5. ,

5.1

, , , , .

, , IException Exception .

 class IException {    friend class Exception;    virtual IException* Clone() const = 0;    virtual void Delete() = 0; protected:    virtual ~IException() = default; public:    virtual const char* What() const = 0;    virtual int Code() const = 0;    IException& operator=(const IException&) = delete; }; class Exception {    IException* const m_Ptr; public:    Exception(const char* what, int code);    Exception(const Exception& src) : m_Ptr(src.m_Ptr->Clone()) {}    ~Exception() { m_Ptr->Delete(); }    const IException* Ptr() const { return m_Ptr; } }; 

Exception , IException . , throw , . Exception , . - , .

Exception , , .

IException :

 class ExcImpl : IException {    friend class Exception;    const std::string m_What;    const int m_Code;    ExcImpl(const char* what, int code);    ExcImpl(const ExcImpl&) = default;    IException* Clone() const override;    void Delete() override; protected:    ~ExcImpl() = default; public:    const char* What() const override;    int Code() const override; }; ExcImpl::ExcImpl(const char* what, int code)    : m_What(what), m_Code(code) {} IException* ExcImpl::Clone() const { return new ExcImpl(*this); } void ExcImpl::Delete() { delete this; } const char* ExcImpl::What() const { return m_What.c_str(); } int ExcImpl::Code() const { return m_Code; } 

Exception :

 Exception::Exception(const char* what, int code)    : m_Ptr(new ExcImpl(what, code)) {} 

, — .NET — , — , C++/CLI. , , , C++/CLI.

5.2

- :

 template <typename T> class ICollect { protected:    virtual ~ICollect() = default; public:    virtual ICollect<T>* Clone() const = 0;    virtual void Delete() = 0;    virtual bool IsEmpty() const = 0;    virtual int GetCount() const = 0;    virtual T& GetItem(int ind) = 0;    virtual const T& GetItem(int ind) const = 0;    ICollect<T>& operator=(const ICollect<T>&) = delete; }; 

, -, .

 template <typename T> class ICollect; template <typename T> class Iterator; template <typename T> class Contain {    typedef ICollect<T> CollType;    CollType* m_Coll; public:    typedef T value_type;    Contain(CollType* coll);    ~Contain(); //     Contain(const Contain& src);    Contain& operator=(const Contain& src); //     Contain(Contain&& src);    Contain& operator=(Contain&& src);    bool mpty() const;    int size() const;    T& operator[](int ind);    const T& operator[](int ind) const;    Iterator<T> begin();    Iterator<T> end(); }; 

. , . , , , , - begin() end() , . (. [Josuttis]), for . . , , .

6. -

. -, . . , ++. , .NET, Java Pyton. . , , . .NET Framework C++/CLI C++. .

7.

-, .

.

1. delete .
2. .
3. .

.

, delete . , .

- , . , , delete .

.

, , , , .

Les références