classe qui ne s'instancie que comme pointeur??

**yashiro** · 03/04/2006, 21h09

Comment procède-t-on pour créer des classe qui ne peuvent être instanciée que sous forme de pointeur?

J'ai essayé de rendre privé tous ses constructeurs et surcharger l'opérateur "new", ça m'a permi de restreindre la déclaration de cette classe à un pointeur mais lorsque j'appèle le "new" k'ai des erreur d'accès
voici ce que j'ai pu faire:

L'interface de la classe

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
nonpublic.h
 
// Une classe qui n'a pas de constructeur public
#include<stddef.h>
 
class nonpublic
 { nonpublic(int = 0);
   int x;
   public:
    void Print();
    void* operator new(size_t);
 };

La définition de la classe

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
nonpublic.cpp
 
#include<stdlib.h>
#include<iostream>
#include<stddef.h>
#include"nonpublic.h"
 
nonpublic::nonpublic(int i): x(i) {} 
 
void nonpublic::Print() { std::cout<<x<<std::endl; }
 
void* nonpublic::operator new(size_t size) 
 { 
   char* chn = ::new char[size];
   void* var=static_cast<void*>(chn);
   nonpublic* val= static_cast<nonpublic* >(var); 
   return val;
 }

Mais lorsque je met cette instruction dans le main

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

nonpublic* n = new nonpublic;

le compilo me renvoie

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

C:\Dev-Cpp\Projet\nonpublic\nonpublic.h `nonpublic::nonpublic(int = 0)' is private

**la drogue c'est mal** · 03/04/2006, 21h15

tu crées une classe factory.
tu mets en private le contructeur de ta classe avec le factory en friend
tu crées une methode "GetInstanceMaClass" dans ta factory.

**Luc Hermitte** · 03/04/2006, 23h26

On peut en plus planquer le destructeur et renvoyer des handle-intelligents (comme les pointeurs) amis qui seront les seuls à même de détruire les objets.
La factory renvoie des handles, les handles en fin de portée (extensible avec telle ou telle autre sémantique de copie) s'occupent de libérer.

Mais ... pourquoi faire une telle chose ?

**Edouard Kaiser** · 03/04/2006, 23h28

Peut être qu'il souhaite implémenter le design pattern factory.

**Luc Hermitte** · 03/04/2006, 23h36

Je ne trouve pas qu'il soit besoin de s'interdire les objets automatiques pour autant. Interdire les copie sur les objets qui sont sensés avoir une sémantique d'entité suffit amplement je trouve. On voit vite que ce sont des pointeurs qui sont attendus en sortie de la factory.

**Jan Rendek** · 04/04/2006, 08h32

Un cas ou interdire l'allocation des objets sur la pile est intéressant, c'est lorsque l'on souhaite qu'ils possèdent un comportement "suicidaire", c-à-d que l'objet à un moment de sa vie effectue lui même un delete this.
Dans ce cas, il est inutile de déclarer tous les constructeurs comme fonctions membre privées, déclarer le destructeur en partie privée suffit.

Sinon, la solution brutale pour forcer l'allocation sur le tas, c'est comme indiqué : mettre tous les constructeurs en partie privée et fournir une fonction de type usine.

**Matthieu Brucher** · 04/04/2006, 09h08

Si une classe fait un delete this, je me poserai des questions sur le gars qui l'a programmée.

**JolyLoic** · 04/04/2006, 09h11

Si quelqu'un se pose des question sur moi parce que je fais delete this, je me poserai des questions sur lui

**Matthieu Brucher** · 04/04/2006, 09h26

On ne sait jamais

Plus sérieusement, à part si on sait exactement ce qu'on fait - ce qui a l'air d'être ton cas -, vaut mieux de pas le faire - il y a tellement de possibilités qui pourraient aml se passer -

**Luc Hermitte** · 04/04/2006, 09h57

Il y a des frameworks qui obligent pratiquement à faire cela. Au début c'est dérangeant, après on comprend pourquoi et on s'y fait.

**la drogue c'est mal** · 04/04/2006, 10h33

Envoyé par JolyLoic

Si quelqu'un se pose des question sur moi parce que je fais delete this, je me poserai des questions sur lui

les MFC le font

**Matthieu Brucher** · 04/04/2006, 11h05

Envoyé par Luc Hermitte

Il y a des frameworks qui obligent pratiquement à faire cela. Au début c'est dérangeant, après on comprend pourquoi et on s'y fait.

Ah ?
C'est pourquoi alors les raisons ? - c'est vraiment pour me renseigner, hein

-

**Jan Rendek** · 04/04/2006, 11h08

Envoyé par Miles

Si une classe fait un delete this, je me poserai des questions sur le gars qui l'a programmée.

C'est pourtant un classique. Je ne suis pas un exemple, mais j'ai 7 ans de métier et je l'utilise parfois. Des API entières sont construites en se basant sur ce modèle, conçues par des gens dont j'estime la compétence bien au dela de la mienne.

Si je me rappelle bien, il me semble que dans COM/DCOM les objets sont construits via une usine propre et incluent un comptage de référence, les clients ne peuvent ni construire ni détruire directement un objet. Lorsqu'ils n'utilisent plus une instance, ils la libère via une fonction membre. Cette instance detecte si elle est encore utilisée, et ce n'est pas le cas, elle se suicide.

Un autre exemple, minimaliste et discutable. Tu fais du client/serveur. Quand un client se connecte, une tâche (thread) est crée pour satisfaire sa demande. Cette tâche est implantée par une instance d'une classe TâcheClient.
La destruction de cette instance doit être effectuée lorsque la requête du client est satisfaite. Le suicide permet de créer cette sous tâche et de la laisser vivre sa vie, sans s'en occuper. Cela évite un système de communication compliqué où cette sous tâche devrait avertir un tiers que le travail est terminé afin qu'il la détruise.

**Matthieu Brucher** · 04/04/2006, 11h52

D'accord, je vois pourquoi c'est utilisé. Effectivement, dans ce cas, ça passe

Certains l'utilisent malheureusement pour faire des copies ou des bestioles du genre, et là ça peut faire très mal.

**adel_dz** · 04/04/2006, 13h03

soit une finction:

void f()
{

T1 t1 = new T1; //1
T2 t2 = new T2; //2

}

le standard dit que si dans 2 une exception est emise le compilateur doit detruire l'objet t1 (delete t1).

donc si ~T1() est prive le compilateur ne peut pas proceder a la destruction de l'objet t1 et je connais certain compilteur qui refuserait de compiler un tel code
a+

**Jan Rendek** · 04/04/2006, 13h50

Le compilateur doit détruire les objets en sortie de bloc ou lors d'un départ en exception donc dans

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
void f()
{
  T1 t1;
  T2 t2;
}

~T1() et ~T2() sont appelés respectivement sur t1 et t2. Ce qui fait que si ces fonctions
sont privées, ce code ne compile pas. Ca tombe bien, justement on voulait interdire l'allocation d'objet sur la pile.

Maintenant si les objets sont alloué sur le tas,

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
void f()
{
  T1 * t1 = new T1();
  T2 * t2 = new T2();
}

t1 et t2 sont des pointeurs et comme tout type scalaire, le compilateur n'appelera aucun destructeur.

@adel_dz
Je vois mal ce quelle position ton post défend. En tout cas, l'exemple fourni ne compilera sur aucun compilo connu

**adel_dz** · 04/04/2006, 16h01

Ce que j'essais d'expliquer c'est qu'un destructeur prive c'est "evil"

dans le code:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
void f() 
{ 
  T1 * t1 = new T1(); 
  T2 * t2 = new T2(); 
}

si le constructeur T2() emet une exception le compileteur doit inserer du code pour detruire t1 (le standard le stipule) et si le destructeur de T1 est prive le compilateur DOIT s'en plaindre.
a+

**JolyLoic** · 04/04/2006, 16h44

Envoyé par adel_dz

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
void f() 
{ 
  T1 * t1 = new T1(); 
  T2 * t2 = new T2(); 
}

si le constructeur T2() emet une exception le compileteur doit inserer du code pour detruire t1 (le standard le stipule)

Non.

Si tu remplace T1* par un pointeur intelligent, alors ok, mais ce pointeur intelligent a alors toutes les chances :
- D'être ami de T1
ou
- D'appeler une fonction de destruction de T1, et non pas son destructeur.

**Jan Rendek** · 04/04/2006, 17h21

Envoyé par adel_dz

Ce que j'essais d'expliquer c'est qu'un destructeur prive c'est "evil"

C'est faux, et tu continues à confondre objet et pointeur. Il te suffirait d'écrire un exemple pour t'en rendre compte. Lorsque tu écris

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
void f()
{
  int i =10;
  throw runtime_error("error");
}

Le compilateur génère-t'il un code spécifique pour la destruction de i ?
Il en va de même si i est un pointeur, car un pointeur même s'il pointe sur un objet reste un type scalaire.

Ensuite, le coup du destructeur privé ce n'est pas une bidouille de programmeur, mais bel et bien une technique connue et éprouvée pour forcer l'allocation des instances d'une classe sur le tas. Cette technique est présentée entre autre dans "More Effective C++" de Scott Meyer chez Addison-Wesley (item 26) qui AMA fait référence en terme d'ouvrage de programmation.

Merci à l'avenir de tester ce que tu avances avant de te répéter.

**Matthieu Brucher** · 04/04/2006, 17h32

Tout à fait d'accord, d'ailleurs Meyers n'est pas le seul partisan de cette manière de faire. Certains préconisent même destructeur (public et virtuel) ou privé.

classe qui ne s'instancie que comme pointeur??

C++

Discussions similaires

Partager

Partager