tout d'abord, merci à tous pour ce newsgroup très instructif, c'est la
première fois que je poste, alors je vais essayer de ne pas me faire
incendier par Fabien ;) :p
Voila mon problème : j'ai un client qui souhaite que toutes les classes
définies dans le projet sur lequel je travaille soient sous la forme
canonique de Coplien (pour ceux qui ne connaissent pas : constructeur
par défaut, constructeur par copie, operateur d'affectation et
destructeur virtuel ou non). Pour que ce soit plus clean (selon eux), le
client demande que toutes les classes dérivent d'une classe de base...
Sauf que je ne vois pas du tout l'intéret de faire ca car je ne vois pas
en quoi ca force à respecter la forme canonique de Coplien.
Concernant l'operateur d'affectation, si je le met virtuel (est ce
quelque chose de propre ?!) comment puis je faire en sorte que les
classes filles utilisent un opérateur correct ? cast dynamique ?
Concernant l'operateur de recopie, là, je vois pas du tout du tout du
tout :)
Bref, je comprends pas du tout cette demande, si quelqu'un pense que
c'est raisonable ou explicable, je veux bien une précision sur l'utilité...
Pour terminer, il faut aussi déporter le code du constructeur et du
destructeur dans une fonction séparée, et là, je comprends plus du
tout... genre quelque chose comme ca :
T::T(void)
{
construct();
}
T::~T(void)
{
destruct();
}
void T::construct(void)
{
// ...
}
void T::destruct(void)
{
// ...
}
Voila voila, votre avis est le bienvenu :)
Merci d'avance,
| Grande question : | Comment un programme conforme peut-il examiner le type dynamique du | sous-objet "B" pendant la durée de vie de l'objet complet (puisque | cela d'après toi n'est pas possible en regardant le type dynamique | de *pB1, bien que ce pointeur pointe sur ledit sous-objet "B") ?
Ta « grande » question contient sa propre réponse.
Le type d'un objet ne change pas, juste parce que la résolution d'une fonction virtuelle change en deux points différents. Mais tu as préféré enlever les passages qui décrivent comment les fonctions virtuelles sont résolues.
| Grande question :
| Comment un programme conforme peut-il examiner le type dynamique du
| sous-objet "B" pendant la durée de vie de l'objet complet (puisque
| cela d'après toi n'est pas possible en regardant le type dynamique
| de *pB1, bien que ce pointeur pointe sur ledit sous-objet "B") ?
Ta « grande » question contient sa propre réponse.
Le type d'un objet ne change pas, juste parce que la résolution d'une
fonction virtuelle change en deux points différents. Mais tu as
préféré enlever les passages qui décrivent comment les fonctions
virtuelles sont résolues.
| Grande question : | Comment un programme conforme peut-il examiner le type dynamique du | sous-objet "B" pendant la durée de vie de l'objet complet (puisque | cela d'après toi n'est pas possible en regardant le type dynamique | de *pB1, bien que ce pointeur pointe sur ledit sous-objet "B") ?
Ta « grande » question contient sa propre réponse.
Le type d'un objet ne change pas, juste parce que la résolution d'une fonction virtuelle change en deux points différents. Mais tu as préféré enlever les passages qui décrivent comment les fonctions virtuelles sont résolues.
-- Gaby
Laurent Deniau
Gabriel Dos Reis wrote:
Laurent Deniau writes:
[...]
| Meme si oopc ne fonctionne pas comme C++, tu peux regarder les schemas | du modele objet qui donne une idee des liens entre objet, sous-objet | et vtbl. | | http://cern.ch/Laurent.Deniau/html/oopc/oopc.html
Tu en fais une proposition d'entrée pour la fAQ ? Je suis trop fatigué pour re-expliquer tout ça en détail, mais je veux bien écrire des bouts.
Ok. J'essaye de preparer ca d'ici la fin de la semaine. Je te post ca en prive.
a+, ld.
Gabriel Dos Reis wrote:
Laurent Deniau <Laurent.Deniau@cern.ch> writes:
[...]
| Meme si oopc ne fonctionne pas comme C++, tu peux regarder les schemas
| du modele objet qui donne une idee des liens entre objet, sous-objet
| et vtbl.
|
| http://cern.ch/Laurent.Deniau/html/oopc/oopc.html
Tu en fais une proposition d'entrée pour la fAQ ? Je suis trop fatigué
pour re-expliquer tout ça en détail, mais je veux bien écrire des
bouts.
Ok. J'essaye de preparer ca d'ici la fin de la semaine. Je te post ca en
prive.
| Meme si oopc ne fonctionne pas comme C++, tu peux regarder les schemas | du modele objet qui donne une idee des liens entre objet, sous-objet | et vtbl. | | http://cern.ch/Laurent.Deniau/html/oopc/oopc.html
Tu en fais une proposition d'entrée pour la fAQ ? Je suis trop fatigué pour re-expliquer tout ça en détail, mais je veux bien écrire des bouts.
Ok. J'essaye de preparer ca d'ici la fin de la semaine. Je te post ca en prive.
a+, ld.
Arnaud Meurgues
Gabriel Dos Reis wrote:
Un constructeur d'une classe de base construit le sous-objet de la classe de base, et non l'objet complet le plus dérivé. Et le type dynamique de ce sous-objet reste, tout au long de sa vie, le type statique vu par le constructeur. Il n'y a jamais de changement
Toute cette discussion me fait me poser une question.
Quel est le sens de "type statique" d'un objet ou de "type dynamique" d'un objet ?
Un objet a toujours le même type. En revanche, on peut parler du type statique d'une variable et du type dynamique d'une variable. Une variable pA définie par A* pA; a un type statique A* et un type dynamique qui dépend de l'exécution, qui pourra être A* ou un pointeur sur une sous-classe quelconque de A.
Mais parler de "type dynamique d'un objet" ne me semble pas avoir grande signification.
-- Arnaud (Supprimez les geneurs pour me répondre)
Gabriel Dos Reis wrote:
Un constructeur d'une classe de base construit le sous-objet de la
classe de base, et non l'objet complet le plus dérivé. Et le type
dynamique de ce sous-objet reste, tout au long de sa vie, le type
statique vu par le constructeur. Il n'y a jamais de changement
Toute cette discussion me fait me poser une question.
Quel est le sens de "type statique" d'un objet ou de "type dynamique"
d'un objet ?
Un objet a toujours le même type. En revanche, on peut parler du type
statique d'une variable et du type dynamique d'une variable.
Une variable pA définie par
A* pA;
a un type statique A*
et un type dynamique qui dépend de l'exécution, qui pourra être A* ou un
pointeur sur une sous-classe quelconque de A.
Mais parler de "type dynamique d'un objet" ne me semble pas avoir grande
signification.
--
Arnaud
(Supprimez les geneurs pour me répondre)
Un constructeur d'une classe de base construit le sous-objet de la classe de base, et non l'objet complet le plus dérivé. Et le type dynamique de ce sous-objet reste, tout au long de sa vie, le type statique vu par le constructeur. Il n'y a jamais de changement
Toute cette discussion me fait me poser une question.
Quel est le sens de "type statique" d'un objet ou de "type dynamique" d'un objet ?
Un objet a toujours le même type. En revanche, on peut parler du type statique d'une variable et du type dynamique d'une variable. Une variable pA définie par A* pA; a un type statique A* et un type dynamique qui dépend de l'exécution, qui pourra être A* ou un pointeur sur une sous-classe quelconque de A.
Mais parler de "type dynamique d'un objet" ne me semble pas avoir grande signification.
-- Arnaud (Supprimez les geneurs pour me répondre)
drkm
Arnaud Meurgues writes:
Gabriel Dos Reis wrote:
Un constructeur d'une classe de base construit le sous-objet de la classe de base, et non l'objet complet le plus dérivé. Et le type dynamique de ce sous-objet reste, tout au long de sa vie, le type statique vu par le constructeur. Il n'y a jamais de changement
Toute cette discussion me fait me poser une question.
Quel est le sens de "type statique" d'un objet ou de "type dynamique" d'un objet ?
Un objet a toujours le même type. En revanche, on peut parler du type statique d'une variable et du type dynamique d'une variable.
Si je me souviens bien, la définition de type dynamique (1.3.8, je pense) se réfère au type le plus dérivé d'une *expression* lvalue. Dans le cas d'une rvalue, elle définit le type dynamique comme égal au type statique. Remarque la différence entre « this » et « * this ».
Un constructeur d'une classe de base construit le sous-objet de la
classe de base, et non l'objet complet le plus dérivé. Et le type
dynamique de ce sous-objet reste, tout au long de sa vie, le type
statique vu par le constructeur. Il n'y a jamais de changement
Toute cette discussion me fait me poser une question.
Quel est le sens de "type statique" d'un objet ou de "type dynamique"
d'un objet ?
Un objet a toujours le même type. En revanche, on peut parler du type
statique d'une variable et du type dynamique d'une variable.
Si je me souviens bien, la définition de type dynamique (1.3.8, je
pense) se réfère au type le plus dérivé d'une *expression* lvalue.
Dans le cas d'une rvalue, elle définit le type dynamique comme égal au
type statique. Remarque la différence entre « this » et « * this ».
Un constructeur d'une classe de base construit le sous-objet de la classe de base, et non l'objet complet le plus dérivé. Et le type dynamique de ce sous-objet reste, tout au long de sa vie, le type statique vu par le constructeur. Il n'y a jamais de changement
Toute cette discussion me fait me poser une question.
Quel est le sens de "type statique" d'un objet ou de "type dynamique" d'un objet ?
Un objet a toujours le même type. En revanche, on peut parler du type statique d'une variable et du type dynamique d'une variable.
Si je me souviens bien, la définition de type dynamique (1.3.8, je pense) se réfère au type le plus dérivé d'une *expression* lvalue. Dans le cas d'une rvalue, elle définit le type dynamique comme égal au type statique. Remarque la différence entre « this » et « * this ».
À confirmer, je n'ai pas vérifié.
--drkm
drkm
Laurent Deniau writes:
drkm wrote:
Je ne comprends pas bien l'introduction de __vtbl_C.
Dans le cas de l'heritage simple, par exemple D : B et B : A, l'objet le plus derive et les sous-objets partage le meme pointeur __vtbl. Quand tu construis un D, tu as la relation A est inclus dans B qui est inclus dans D. Il en est de meme pour les __vtbl des classes. Donc tu n'as besoin que d'un seul pointeur __vtbl dans ton objet.
Dans le cas de l'heritage multiple, par exemple D : B, C et B : A, l'objet le plus derive D et le sous-objet C ne partage pas le meme pointeur __vtbl. D contient un deuxieme pointeur que j'ai appelle __vtbl_C qui pointe sur la copie dela __vtbl de C dans celle de D.
Évidemment. Je ne suis sans doute pas assez à l'aise avec l'héritage multiple ...
[...]
Pour ce sujet, il ne faut lire que la partie "modele objet"
Dans le premier schéma, « Object Model Representation », j'ai d'abord été étonné que la « class » semble ne pas fournir les « object methods » du type statique de la classe, afin de pouvoir outre-passer la résolution dynamique.
Mais si je comprend bien, il faut lire le schéma comme « Les types "object" et "class" pointent chacun vers un objet de type "vtbl", éventuellement différent. Il y a donc un objet "vtbl" par "class", "object" pointant vers celui correspondant à son type le plus dérivé ». Et l'on peut soit utiliser la résolution dynamique, soit utiliser directement les définitions de fonctions membres d'une classe particulière.
Exact ?
Cela correspond assez, il me semble, à l'idée que je me fais de ce qui se passe en C++, y compris pour l'héritage multiple. Avec, j'imagine, dans ce dernier cas, l'absence de transtypage implicite en OOPC vers une classe de base, et donc de calcul de déplacement, cela devant être demandé explicitement par l'utilisateur.
--drkm
Laurent Deniau <Laurent.Deniau@cern.ch> writes:
drkm wrote:
Je ne comprends pas bien l'introduction de __vtbl_C.
Dans le cas de l'heritage simple, par exemple D : B et B : A, l'objet le
plus derive et les sous-objets partage le meme pointeur __vtbl. Quand tu
construis un D, tu as la relation A est inclus dans B qui est inclus
dans D. Il en est de meme pour les __vtbl des classes. Donc tu n'as
besoin que d'un seul pointeur __vtbl dans ton objet.
Dans le cas de l'heritage multiple, par exemple D : B, C et B : A,
l'objet le plus derive D et le sous-objet C ne partage pas le meme
pointeur __vtbl. D contient un deuxieme pointeur que j'ai appelle
__vtbl_C qui pointe sur la copie dela __vtbl de C dans celle de D.
Évidemment. Je ne suis sans doute pas assez à l'aise avec
l'héritage multiple ...
[...]
Pour ce sujet, il ne faut lire que la partie "modele objet"
Dans le premier schéma, « Object Model Representation », j'ai
d'abord été étonné que la « class » semble ne pas fournir les « object
methods » du type statique de la classe, afin de pouvoir outre-passer
la résolution dynamique.
Mais si je comprend bien, il faut lire le schéma comme « Les types
"object" et "class" pointent chacun vers un objet de type "vtbl",
éventuellement différent. Il y a donc un objet "vtbl" par "class",
"object" pointant vers celui correspondant à son type le plus
dérivé ». Et l'on peut soit utiliser la résolution dynamique, soit
utiliser directement les définitions de fonctions membres d'une classe
particulière.
Exact ?
Cela correspond assez, il me semble, à l'idée que je me fais de ce
qui se passe en C++, y compris pour l'héritage multiple. Avec,
j'imagine, dans ce dernier cas, l'absence de transtypage implicite en
OOPC vers une classe de base, et donc de calcul de déplacement, cela
devant être demandé explicitement par l'utilisateur.
Je ne comprends pas bien l'introduction de __vtbl_C.
Dans le cas de l'heritage simple, par exemple D : B et B : A, l'objet le plus derive et les sous-objets partage le meme pointeur __vtbl. Quand tu construis un D, tu as la relation A est inclus dans B qui est inclus dans D. Il en est de meme pour les __vtbl des classes. Donc tu n'as besoin que d'un seul pointeur __vtbl dans ton objet.
Dans le cas de l'heritage multiple, par exemple D : B, C et B : A, l'objet le plus derive D et le sous-objet C ne partage pas le meme pointeur __vtbl. D contient un deuxieme pointeur que j'ai appelle __vtbl_C qui pointe sur la copie dela __vtbl de C dans celle de D.
Évidemment. Je ne suis sans doute pas assez à l'aise avec l'héritage multiple ...
[...]
Pour ce sujet, il ne faut lire que la partie "modele objet"
Dans le premier schéma, « Object Model Representation », j'ai d'abord été étonné que la « class » semble ne pas fournir les « object methods » du type statique de la classe, afin de pouvoir outre-passer la résolution dynamique.
Mais si je comprend bien, il faut lire le schéma comme « Les types "object" et "class" pointent chacun vers un objet de type "vtbl", éventuellement différent. Il y a donc un objet "vtbl" par "class", "object" pointant vers celui correspondant à son type le plus dérivé ». Et l'on peut soit utiliser la résolution dynamique, soit utiliser directement les définitions de fonctions membres d'une classe particulière.
Exact ?
Cela correspond assez, il me semble, à l'idée que je me fais de ce qui se passe en C++, y compris pour l'héritage multiple. Avec, j'imagine, dans ce dernier cas, l'absence de transtypage implicite en OOPC vers une classe de base, et donc de calcul de déplacement, cela devant être demandé explicitement par l'utilisateur.
--drkm
drkm
Laurent Deniau writes:
Ok. J'essaye de preparer ca d'ici la fin de la semaine. Je te post ca en prive.
Pourrais-tu également poster ta proposition ici ? Cela serait intéressant, même s'il ne s'agit pas d'une version définitive.
--drkm
Laurent Deniau <Laurent.Deniau@cern.ch> writes:
Ok. J'essaye de preparer ca d'ici la fin de la semaine. Je te post ca en
prive.
Pourrais-tu également poster ta proposition ici ? Cela serait
intéressant, même s'il ne s'agit pas d'une version définitive.
Ok. J'essaye de preparer ca d'ici la fin de la semaine. Je te post ca en prive.
Pourrais-tu également poster ta proposition ici ? Cela serait intéressant, même s'il ne s'agit pas d'une version définitive.
--drkm
drkm
Arnaud Meurgues writes:
drkm wrote:
Remarque la différence entre « this » et « * this ».
Vi. Mais les deux sont des expressions et peuvent donc avoir un type dynamique. Mais parler du type dynamique de this ne me gène pas. Au contraire, c'est nécessaire (par le principe même des fonctions virtuelles).
Mais le type dynamique de « this » est égal à son type statique. Pas celui de « * this ».
Remarque la différence entre « this » et « * this ».
Vi. Mais les deux sont des expressions et peuvent donc avoir un type
dynamique. Mais parler du type dynamique de this ne me gène pas. Au
contraire, c'est nécessaire (par le principe même des fonctions virtuelles).
Mais le type dynamique de « this » est égal à son type statique.
Pas celui de « * this ».
Remarque la différence entre « this » et « * this ».
Vi. Mais les deux sont des expressions et peuvent donc avoir un type dynamique. Mais parler du type dynamique de this ne me gène pas. Au contraire, c'est nécessaire (par le principe même des fonctions virtuelles).
Mais le type dynamique de « this » est égal à son type statique. Pas celui de « * this ».
--drkm
Gabriel Dos Reis
Arnaud Meurgues writes:
| Gabriel Dos Reis wrote: | | > Un constructeur d'une classe de base construit le sous-objet de la | > classe de base, et non l'objet complet le plus dérivé. Et le type | > dynamique de ce sous-objet reste, tout au long de sa vie, le type | > statique vu par le constructeur. Il n'y a jamais de changement | | Toute cette discussion me fait me poser une question. | | Quel est le sens de "type statique" d'un objet ou de "type dynamique" | d'un objet ?
Les expressions « type statique » et « type dynamique » ne sont formellement définies que pour les « object expressions », i.e. les expressions qui désignent des objets. Dans cette discussion, je crois (du moins c'est comme cela que je les utilise) qu'elles sont utilisées pour désigner les type des objets tels que déterminés par une analyse statique (à la compilation) ou dynamique (pendant l'exécution).
| Un objet a toujours le même type. En revanche, on peut parler du type | statique d'une variable et du type dynamique d'une variable. | Une variable pA définie par | A* pA; | a un type statique A* | et un type dynamique qui dépend de l'exécution, qui pourra être A* ou | un pointeur sur une sous-classe quelconque de A.
Non, pA aura toujours comme type dynamique "A*", mais l'expression "*pA" pourrait avoir un type différent -- je suppose que c'est ce qu tu as voulu dire.
| Mais parler de "type dynamique d'un objet" ne me semble pas avoir | grande signification.
| Gabriel Dos Reis wrote:
|
| > Un constructeur d'une classe de base construit le sous-objet de la
| > classe de base, et non l'objet complet le plus dérivé. Et le type
| > dynamique de ce sous-objet reste, tout au long de sa vie, le type
| > statique vu par le constructeur. Il n'y a jamais de changement
|
| Toute cette discussion me fait me poser une question.
|
| Quel est le sens de "type statique" d'un objet ou de "type dynamique"
| d'un objet ?
Les expressions « type statique » et « type dynamique » ne sont
formellement définies que pour les « object expressions », i.e. les
expressions qui désignent des objets.
Dans cette discussion, je crois (du moins c'est comme cela que je
les utilise) qu'elles sont utilisées pour désigner les type des objets
tels que déterminés par une analyse statique (à la compilation) ou
dynamique (pendant l'exécution).
| Un objet a toujours le même type. En revanche, on peut parler du type
| statique d'une variable et du type dynamique d'une variable.
| Une variable pA définie par
| A* pA;
| a un type statique A*
| et un type dynamique qui dépend de l'exécution, qui pourra être A* ou
| un pointeur sur une sous-classe quelconque de A.
Non, pA aura toujours comme type dynamique "A*", mais l'expression
"*pA" pourrait avoir un type différent -- je suppose que c'est ce qu
tu as voulu dire.
| Mais parler de "type dynamique d'un objet" ne me semble pas avoir
| grande signification.
| Gabriel Dos Reis wrote: | | > Un constructeur d'une classe de base construit le sous-objet de la | > classe de base, et non l'objet complet le plus dérivé. Et le type | > dynamique de ce sous-objet reste, tout au long de sa vie, le type | > statique vu par le constructeur. Il n'y a jamais de changement | | Toute cette discussion me fait me poser une question. | | Quel est le sens de "type statique" d'un objet ou de "type dynamique" | d'un objet ?
Les expressions « type statique » et « type dynamique » ne sont formellement définies que pour les « object expressions », i.e. les expressions qui désignent des objets. Dans cette discussion, je crois (du moins c'est comme cela que je les utilise) qu'elles sont utilisées pour désigner les type des objets tels que déterminés par une analyse statique (à la compilation) ou dynamique (pendant l'exécution).
| Un objet a toujours le même type. En revanche, on peut parler du type | statique d'une variable et du type dynamique d'une variable. | Une variable pA définie par | A* pA; | a un type statique A* | et un type dynamique qui dépend de l'exécution, qui pourra être A* ou | un pointeur sur une sous-classe quelconque de A.
Non, pA aura toujours comme type dynamique "A*", mais l'expression "*pA" pourrait avoir un type différent -- je suppose que c'est ce qu tu as voulu dire.
| Mais parler de "type dynamique d'un objet" ne me semble pas avoir | grande signification.
-- Gaby
Gabriel Dos Reis
drkm writes:
| Arnaud Meurgues writes: | | > Gabriel Dos Reis wrote: | | >> Un constructeur d'une classe de base construit le sous-objet de la | >> classe de base, et non l'objet complet le plus dérivé. Et le type | >> dynamique de ce sous-objet reste, tout au long de sa vie, le type | >> statique vu par le constructeur. Il n'y a jamais de changement | | > Toute cette discussion me fait me poser une question. | | > Quel est le sens de "type statique" d'un objet ou de "type dynamique" | > d'un objet ? | | > Un objet a toujours le même type. En revanche, on peut parler du type | > statique d'une variable et du type dynamique d'une variable. | | Si je me souviens bien, la définition de type dynamique (1.3.8, je | pense) se réfère au type le plus dérivé d'une *expression* lvalue. | Dans le cas d'une rvalue, elle définit le type dynamique comme égal au | type statique. Remarque la différence entre « this » et « * this ».
Exact.
-- Gaby
drkm <usenet.fclcxx@fgeorges.org> writes:
| Arnaud Meurgues <arnaud@meurgues.non.fr.invalid> writes:
|
| > Gabriel Dos Reis wrote:
|
| >> Un constructeur d'une classe de base construit le sous-objet de la
| >> classe de base, et non l'objet complet le plus dérivé. Et le type
| >> dynamique de ce sous-objet reste, tout au long de sa vie, le type
| >> statique vu par le constructeur. Il n'y a jamais de changement
|
| > Toute cette discussion me fait me poser une question.
|
| > Quel est le sens de "type statique" d'un objet ou de "type dynamique"
| > d'un objet ?
|
| > Un objet a toujours le même type. En revanche, on peut parler du type
| > statique d'une variable et du type dynamique d'une variable.
|
| Si je me souviens bien, la définition de type dynamique (1.3.8, je
| pense) se réfère au type le plus dérivé d'une *expression* lvalue.
| Dans le cas d'une rvalue, elle définit le type dynamique comme égal au
| type statique. Remarque la différence entre « this » et « * this ».
| Arnaud Meurgues writes: | | > Gabriel Dos Reis wrote: | | >> Un constructeur d'une classe de base construit le sous-objet de la | >> classe de base, et non l'objet complet le plus dérivé. Et le type | >> dynamique de ce sous-objet reste, tout au long de sa vie, le type | >> statique vu par le constructeur. Il n'y a jamais de changement | | > Toute cette discussion me fait me poser une question. | | > Quel est le sens de "type statique" d'un objet ou de "type dynamique" | > d'un objet ? | | > Un objet a toujours le même type. En revanche, on peut parler du type | > statique d'une variable et du type dynamique d'une variable. | | Si je me souviens bien, la définition de type dynamique (1.3.8, je | pense) se réfère au type le plus dérivé d'une *expression* lvalue. | Dans le cas d'une rvalue, elle définit le type dynamique comme égal au | type statique. Remarque la différence entre « this » et « * this ».
Exact.
-- Gaby
Gabriel Dos Reis
Arnaud Meurgues writes:
| drkm wrote: | | > Si je me souviens bien, la définition de type dynamique (1.3.8, je | > pense) se réfère au type le plus dérivé d'une *expression* lvalue. | > Dans le cas d'une rvalue, elle définit le type dynamique comme égal au | > type statique. | | D'accord. Parler du type dynamique d'un objet n'a donc pas de sens. | | > Remarque la différence entre « this » et « * this ». | | Vi. Mais les deux sont des expressions et peuvent donc avoir un type | dynamique. Mais parler du type dynamique de this ne me gène pas. Au | contraire, c'est nécessaire (par le principe même des fonctions | virtuelles).
Pourquoi ? « this » est une rvalue et donc son type statique est son type dynamique.
| drkm wrote:
|
| > Si je me souviens bien, la définition de type dynamique (1.3.8, je
| > pense) se réfère au type le plus dérivé d'une *expression* lvalue.
| > Dans le cas d'une rvalue, elle définit le type dynamique comme égal au
| > type statique.
|
| D'accord. Parler du type dynamique d'un objet n'a donc pas de sens.
|
| > Remarque la différence entre « this » et « * this ».
|
| Vi. Mais les deux sont des expressions et peuvent donc avoir un type
| dynamique. Mais parler du type dynamique de this ne me gène pas. Au
| contraire, c'est nécessaire (par le principe même des fonctions
| virtuelles).
Pourquoi ? « this » est une rvalue et donc son type statique est son
type dynamique.
| drkm wrote: | | > Si je me souviens bien, la définition de type dynamique (1.3.8, je | > pense) se réfère au type le plus dérivé d'une *expression* lvalue. | > Dans le cas d'une rvalue, elle définit le type dynamique comme égal au | > type statique. | | D'accord. Parler du type dynamique d'un objet n'a donc pas de sens. | | > Remarque la différence entre « this » et « * this ». | | Vi. Mais les deux sont des expressions et peuvent donc avoir un type | dynamique. Mais parler du type dynamique de this ne me gène pas. Au | contraire, c'est nécessaire (par le principe même des fonctions | virtuelles).
Pourquoi ? « this » est une rvalue et donc son type statique est son type dynamique.
