Discussion :

[JEG]

Bonjour,

J'ai une classe B héritant d'une classe A de la VCL :

Code :

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

1
2
3
4
5
6
class B : public A
{
         public:
         void __closure * methodeB1();
         void methodeB2();
};

methodeB2 contenant:

Code :

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

1
2
3
ShowMessage("avantB1");
methodeB1();
ShowMessage("apresB1");

(ne tenez pas compte des erreurs de syntaxe, j'écris en simplifiant)

maintenant imaginons que A soit par exemple un TreeView, qui a été instancié dans une forme l'outil de création de forme.
(On appelera "a" l'instance de A)

dans mon code j'ai qqc de la sorte:

Code :

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

1
2
3
B * b = (B *)a;
b->methodeB1 = maMethode;
b->methodeB2();

et à l'exécution il se trouve que la méthode B2 est belle et bien appelée, que tout s'y déroule bien si ce n'est lors de l'appel à methodeB1 qui déclenche une erreur de type "erreur à l'adresse bidulle" et donc ne rentre jamais dans le corps de maMethode.

D'où ma question :
un closure est-il traité comme une variable de classe (ce qui expliquerait que b doive obligatoirement être une instance de B) ou bien comme une vraie méthode (dans ce cas b peut etre un transtypage d'une instance de A, et je ne vois pas pourquoi ca ne marche pas)

D'avance merci

[ubu]

Salut, un __closure est effectivement traité comme un attribut (variable de classe?!?) dans ton cas.
Il s'agit d'un pointeur 64 bits (@methode: 32 bits et @classe: 32 bits).

[JEG]

Ok ca confirme ce que je pensais, merci !

[ubu]

J'aurais par contre une question qui me turlupine depuis que j'ai vu ce bout de code:

Code :

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

1
2
3
B * b = (B *)a; 
b->methodeB1 = maMethode; 
b->methodeB2();

Le pointeur a considéré ici est il de type A (Treeview ou autre) ?

[JEG]

Affirmatif (j'ai corrigé mon texte)

[ubu]

OK, c'est bien ce que je pensais. J'aurai une question alors:

Est ce que Borland à prévu officiellement dans l'implémentation de son compilo qu'un downcasting brutal de ce type soit géré ?
Car logiquement, on devrait faire un safe-downcasting en utilisant un dynamic_cast, non ?
Quel est l'intérêt de ce downcasting brutal, et surtout, qu'est ce qui se passe à l'éxecution ?
Normalement, les attributs et les méthodes déclarés dans B et non hérités de A devraient poser un gros problème, non ?

[JEG]

OK, c'est bien ce que je pensais. J'aurai une question alors:

Est ce que Borland à prévu officiellement dans l'implémentation de son compilo qu'un downcasting brutal de ce type soit géré ?
Car logiquement, on devrait faire un safe-downcasting en utilisant un dynamic_cast, non ?
Quel est l'intérêt de ce downcasting brutal, et surtout, qu'est ce qui se passe à l'éxecution ?
Normalement, les attributs et les méthodes déclarés dans B et non hérités de A devraient poser un gros problème, non ?

l'intérêt de ce transtypage réside dans le fait d'enrichir les foncitonanlités du TreeView tout en conservant la création du composant par l'éditeur de fiche. Tout marche bien à partir du moment il la classe B ne comporte aucun attribut dont on se serve, si il n'y a que des méthodes par exemple ca marche très bien étant donnée que les méthodes sont gérées de façon statiques donc qu'elles existent à partir du moment là classe est déclarée (a contrario des attributs qui n'existe que dans le cas d'une instanciation)
donc si l'on n'enrichit la classe qu'avec des méthodes cette sorte de transtypage est géré par (je crois) la totalité des compilateurs C++.

Bien sur n'est pas très une méthode très "Object Oriented" au sens puriste du terme, mais ca me permet une certaine souplesse dans mes développement.

dynamic_cast, je ne connais pas bien. Quel est la différence avec le cast normal ?

[Luc Hermitte]

dynamic_cast, je ne connais pas bien. Quel est la différence avec le cast normal ?

GOTW #17
Le cast normal n'est pas adapté au C++. C'est plus un reliquat de compatibilité avec le C qu'autre chose.

[ubu]

cette sorte de transtypage est géré par (je crois) la totalité des compilateurs C++.

Je ne suis pas sur du tout de cela. En tout cas, il n'existe pas de norme pour ce transtypage. Le résultat n'est donc jamais assuré. Cependant, il est tout a fait possible que, rien n'étant spécifié, Borland ai pris le parti de le supporter (d'ou ma question précédente).

Le dynamic_cast permet d'effectuer ce type de transtypage en se basant sur le RTTI, et donc d'une manière très sure (typesafe). Par ex:

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
class A {};
class B: public A {};
 
A* a1,a2;
B* b1,b2;
 
a1=new A();
b1=new B();
 
a2=b; // <= aucun problème, upcast implicite
 
b2=dynamic_cast<B*>(a2); // équivalent à b2=(B*)a2; mais avec vérification du type. On peut alors tester le résultat
 
if (b2!=NULL)
  ... // si b2 existe, alors ce downcasting était autorisé (ce A était un B)
else
  ... // sinon, ce A n'était pas un B
 
b2=dynamic_cast<B*>(a1); // b2 vaudra NULL, puisqu'il s'agit d'un A

[JEG]

En tout cas, il n'existe pas de norme pour ce transtypage.

Vu qu'il s'agit juste d'une conversion de pointeur, ca reviendrait à dire que le cast utilisant les parenthèse "()" n'est pas normalisé, et ca me parait étrange à vrai dire...

[ubu]

Je voulais dire que le résultat effectif (comportement de l'instance pointée)de ce trantypage n'est pas normalisé. Par contre effectivement, le pointeur sur A est bel et bien typé en B, mais sans contrôle de type. En gros c'est comme faire:

Code :

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

1
2
3
int i;
B *b;
b=(B*)i;

Ca doit fonctionner, mais alors à l'execution, ben heu...

[JEG]

A mon avis, je pense que tout compilo C++ qui gère le concept d'interface basée sur classes abstraites doit pouvoir gérer ce que j'ai fait. Si l'on part du principe que tous les compilo C++ gèrent le système d'interface, ca me laissait penser que ce que j'ai fait marchait sur tous les compilo. A tester donc...