Discussion :

[Steph_ng8]

Bonjour,

J'aimerais savoir si ces bouts de code sont sûrs :

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
19
20
21
22
23
24
25
26
27
28
29
30
// Partie non accessible
uneClasse obj;
 
(...)
 
// Partie accessible
obj.~uneClasse();
new(&obj) uneSousClasse();
(...)
reinterpret_cast<uneSousClasse *>( &obj )->~uneSousClasse();
new(&obj) uneClasse();
 
//==================================//
 
// Partie non accessible
uneClasse *obj = new uneClasse();
 
(...)
 
// Partie accessible
obj->~uneClasse()
new(obj) uneSousClasse();
(...)
reinterpret_cast<uneSousClasse *>( obj )->~uneSousClasse();
new(obj) uneClasse();
 
(...)
 
// Partie non accessible
delete obj;

sachant que :

• uneSousClasse et une sous-classe de uneClasse ;
• uneSousClasse ne définit aucun attribut membre ni aucun membre statique (attribut ou fonction) ;
• le destructeur de la classe uneClasse n'est pas (forcément) virtuel ;
• je n'ai pas accès à la classe uneClasse ;
• je n'ai pas forcément accès à la classe uneSousClasse ;
• je n'ai pas accès à la création de l'objet (ni à sa destruction).

Je sais que ce n'est pas propre, mais je n'ai pas vraiment le choix...

Merci d'avance.

Edit : J'ai ajouté la gestion de la destruction des objets.

[koala01]

Salut,

J'ai l'impression que tu es mur pour... foncer dans le mur

Tu ne nous donnes pas assez d'information concernant tes classes, mais, étant donné que tu utilise ne placement new, tu cours le gros risque de voir certains membre de ta classe UneSousClasse se retrouver à une adresse mémoire qui n'est pas réservée, étant donné que sizeof(UneSousClasse) sera, très vraisemblablement plus grand que sizeof(UneClasse).

Désolé

[Steph_ng8]

Arf...
Moi qui pensait que comme la sous-classe ne définit que des fonctions membres non statiques, les instances auraient la même taille...

Concernant les informations sur les classes, d'après ce que j'ai lu (et compris...) sur l'alignement et le placement new, je pensais avoir mis tout ce qui était nécessaire...
Qu'est-ce qui manque ?

Au passage, la question m'est venue avec des classes de la STL.
Bah quoi ? je voulais juste adapter une classe prédéfinie à mes besoins, sans pour autant réinventer la roue...

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
19
20
21
22
23
24
25
26
27
28
29
30
namespace std
{
 
  class uneClasse
  {
 
    public:
        ~uneClasse() {...}
 
    (...)
 
  };
 
  class uneSousClasse : public uneClasse
  {
    (...)
  };
 
 
  class uneAutreClasse
  {
 
    protected:
        uneClasse _attribut;
 
    (...)
 
  };
 
}

J'ai besoin des fonctionnalités de la classe uneAutreClasse, sauf que _attribut doit être une instance de uneSousClasse.

Bon, je pourrais réécrire la classe uneAutreClasse, mais bon, hum...
Ceci dit, si vous avez une meilleure idée, je suis preneur.

[Flob90]

le destructeur de la classe uneClasse n'est pas (forcément) virtuel ;

Ceci couplé avec l'exemple 2, conduit à un code qui peut potentiellement faire n'importe quoi.

[JolyLoic]

Il est difficile de donner un avis dans l'abstrait ainsi, mais voici quelques remarques en vrac :

- Je pense que le code 1 a des chances de "marcher" sur pas mal d'implémentations, tant que tu ne copies pas obj, mais il y a des chances que ce ne soit pas formellement autorisé (je n'ai pas eu le courage de regarder dans le standard).
- Comme dit Flob, le 2 pose problème.
- Meilleure idée 1 (?) : A quoi sert vraiment uneSousClasse, sans données, sans fonctions, sans rien ? Ne serait-il pas possible de la remplacer par des fonctions libres prenant un uneClasse& en paramètre ?
- Meilleure idée 2 (?) : Tu es propriétaire de uneAutreClasse ? Peut-être pourrais-tu la templater ? Ou lui passer en argument une fonction de factory (et utiliser un pointeur) ?

[gb_68]

- Je pense que le code 1 a des chances de "marcher" sur pas mal d'implémentations, tant que tu ne copies pas obj, mais il y a des chances que ce ne soit pas formellement autorisé (je n'ai pas eu le courage de regarder dans le standard).
- Comme dit Flob, le 2 pose problème.

Le cas 1 posera au moins autant de problèmes que le cas 2 au niveau de l'appel du destructeur , car avec ou sans destructeur virtuel, le compilateur utilisera dans tous les cas uneClasse::~uneClasse lorsque l'on sortira de la portée de uneClasse obj;.