"Alain Naigeon" writes:
| "Gabriel Dos Reis" a écrit dans le
message
| news:
| > "Michel Michaud" writes:
| >
| > | Dans news:3fdd9c5a$0$17120$, Frédéric
| > | >> D'autre part, dynamic_cast marche quand tu as au moins une
fonction
| > | >> virtuelle.
| > | >
| > | > Il y a une raison à cela ? Je ne comprends pas trop pourquoi...
| > |
| > | Mécaniquement, c'est que le code du dynamic_cast doit pouvoir
| > | regarder quelque part pour vérifier la légalité de la conversion
| > | que tu demandes (sinon tu peux prendre un static_cast). Et c'est
| > | dans l'équivalent de la v-table que l'information sera mise et
| > | il n'y de v-table que pour les classes ayant un semblant de
| > | polymorphisme (i.e. au moins une fonction virtuelle). Si on avait
| > | permis de faire dynamic_cast sur n'importe quelle classe, donc
| > | mettre l'information dans toutes les classes (et struct), on aurait
| > | perdu la compatibilité C (POD).
| >
| > Autrement, on peut la question suivante :
| >
| > Qu'est-ce que cela veut dire de faire un cast dynamique lorsqu'il
| > n'y a aucune chance que le type dynamique de l'objet pointé ou
référé
| > soit différent de ce que donne une analyse statique basé sur le
| > type du pointeur ou de la réféerence ?
|
| En exprimant les choses comme ci-dessus, il est tout de même
| facile de trouver une réponse : fonction constante.
Je ne comprends pas la réponse. Dis-moi en un peu plus.
Tu vois maintenant ce que tu exiges de nous, parfois :-)
"Alain Naigeon" <anaigeon@free.fr> writes:
| "Gabriel Dos Reis" <gdr@integrable-solutions.net> a écrit dans le
message
| news: m3wu8y89yp.fsf@uniton.integrable-solutions.net...
| > "Michel Michaud" <mm@gdzid.com> writes:
| >
| > | Dans news:3fdd9c5a$0$17120$626a54ce@news.free.fr, Frédéric
| > | >> D'autre part, dynamic_cast marche quand tu as au moins une
fonction
| > | >> virtuelle.
| > | >
| > | > Il y a une raison à cela ? Je ne comprends pas trop pourquoi...
| > |
| > | Mécaniquement, c'est que le code du dynamic_cast doit pouvoir
| > | regarder quelque part pour vérifier la légalité de la conversion
| > | que tu demandes (sinon tu peux prendre un static_cast). Et c'est
| > | dans l'équivalent de la v-table que l'information sera mise et
| > | il n'y de v-table que pour les classes ayant un semblant de
| > | polymorphisme (i.e. au moins une fonction virtuelle). Si on avait
| > | permis de faire dynamic_cast sur n'importe quelle classe, donc
| > | mettre l'information dans toutes les classes (et struct), on aurait
| > | perdu la compatibilité C (POD).
| >
| > Autrement, on peut la question suivante :
| >
| > Qu'est-ce que cela veut dire de faire un cast dynamique lorsqu'il
| > n'y a aucune chance que le type dynamique de l'objet pointé ou
référé
| > soit différent de ce que donne une analyse statique basé sur le
| > type du pointeur ou de la réféerence ?
|
| En exprimant les choses comme ci-dessus, il est tout de même
| facile de trouver une réponse : fonction constante.
Je ne comprends pas la réponse. Dis-moi en un peu plus.
Tu vois maintenant ce que tu exiges de nous, parfois :-)
"Alain Naigeon" writes:
| "Gabriel Dos Reis" a écrit dans le
message
| news:
| > "Michel Michaud" writes:
| >
| > | Dans news:3fdd9c5a$0$17120$, Frédéric
| > | >> D'autre part, dynamic_cast marche quand tu as au moins une
fonction
| > | >> virtuelle.
| > | >
| > | > Il y a une raison à cela ? Je ne comprends pas trop pourquoi...
| > |
| > | Mécaniquement, c'est que le code du dynamic_cast doit pouvoir
| > | regarder quelque part pour vérifier la légalité de la conversion
| > | que tu demandes (sinon tu peux prendre un static_cast). Et c'est
| > | dans l'équivalent de la v-table que l'information sera mise et
| > | il n'y de v-table que pour les classes ayant un semblant de
| > | polymorphisme (i.e. au moins une fonction virtuelle). Si on avait
| > | permis de faire dynamic_cast sur n'importe quelle classe, donc
| > | mettre l'information dans toutes les classes (et struct), on aurait
| > | perdu la compatibilité C (POD).
| >
| > Autrement, on peut la question suivante :
| >
| > Qu'est-ce que cela veut dire de faire un cast dynamique lorsqu'il
| > n'y a aucune chance que le type dynamique de l'objet pointé ou
référé
| > soit différent de ce que donne une analyse statique basé sur le
| > type du pointeur ou de la réféerence ?
|
| En exprimant les choses comme ci-dessus, il est tout de même
| facile de trouver une réponse : fonction constante.
Je ne comprends pas la réponse. Dis-moi en un peu plus.
Tu vois maintenant ce que tu exiges de nous, parfois :-)
"Alain Naigeon" writes:
| "Gabriel Dos Reis" a écrit dans le
message
| news:
| > | > Qu'est-ce que cela veut dire de faire un cast dynamique
lorsqu'il
| > | > n'y a aucune chance que le type dynamique de l'objet pointé ou
| référé
| > | > soit différent de ce que donne une analyse statique basé sur le
| > | > type du pointeur ou de la réféerence ?
| > |
| > | En exprimant les choses comme ci-dessus, il est tout de même
| > | facile de trouver une réponse : fonction constante.
|
| Eh bien : la première idée qui vient en réponse au dernier paragraphe,
| c'est : lorsque le type est connu à l'avance, le dynamic_cast pourrait
| avoir la politesse de renvoyer identiquement ce type, au lieu de faire
| "bêtement" une erreur.
Mais, ce n'est pas ce qu'on appelle une fonction constante ; tout
au plus, ce serait la fonction identité sur ce sous-ensemble là ;-)
| On peut, à la rigueur, envisager un warning
| sur l'inefficacité (?) de cet emploi, mais je ne vois pas pour quelle
| raison le refuser..?
(1) la norme ne définit pas de warning. Elle définit ce qu'elle
appelle un diagnstic. Si elle demander une diagnostic, c'est
qu'elle pense que la construction n'est pas valide.
(2) c'est déjà le boulot de static_cast -- on peut arguer que les
deux opérateurs ont des sémantiques qui se recouvrent des fois,
mais vois le point suivant ;
(3) dynamic_cast est vraiment conçu pour s'occuper des cast pour des
objets polymorphes ; s'il est utilisé pour des objets non
polymorphes, il y a erreur de « type ». C'est un critère de
conception, le but aboué étant de minimiser le plus possible, le
recours aux casts (ainsi éviter « bof, le compilateur fera
l'identité ici, donc c'est pas la même de se casser la tête pour
un design propre de mon programme »)
| > Je ne comprends pas la réponse. Dis-moi en un peu plus.
| Tu vois maintenant ce que tu exiges de nous, parfois :-)
Hmm, tu es scientifique ; tu sais ce que c'est :-)
| [en te paraphrasant : qu'est-ce que ça veut dire de définir f(x)
| pour tout x dans D, alors que, cette fonction étant constante,
| il n'y a aucune chance pour qu'elle vaille jamais autre chose
| que f(x0) ?]
C'est vraiment une paraphrase ça ?
"Alain Naigeon" <anaigeon@free.fr> writes:
| "Gabriel Dos Reis" <gdr@integrable-solutions.net> a écrit dans le
message
| news: m33cblsk9y.fsf@uniton.integrable-solutions.net...
| > | > Qu'est-ce que cela veut dire de faire un cast dynamique
lorsqu'il
| > | > n'y a aucune chance que le type dynamique de l'objet pointé ou
| référé
| > | > soit différent de ce que donne une analyse statique basé sur le
| > | > type du pointeur ou de la réféerence ?
| > |
| > | En exprimant les choses comme ci-dessus, il est tout de même
| > | facile de trouver une réponse : fonction constante.
|
| Eh bien : la première idée qui vient en réponse au dernier paragraphe,
| c'est : lorsque le type est connu à l'avance, le dynamic_cast pourrait
| avoir la politesse de renvoyer identiquement ce type, au lieu de faire
| "bêtement" une erreur.
Mais, ce n'est pas ce qu'on appelle une fonction constante ; tout
au plus, ce serait la fonction identité sur ce sous-ensemble là ;-)
| On peut, à la rigueur, envisager un warning
| sur l'inefficacité (?) de cet emploi, mais je ne vois pas pour quelle
| raison le refuser..?
(1) la norme ne définit pas de warning. Elle définit ce qu'elle
appelle un diagnstic. Si elle demander une diagnostic, c'est
qu'elle pense que la construction n'est pas valide.
(2) c'est déjà le boulot de static_cast -- on peut arguer que les
deux opérateurs ont des sémantiques qui se recouvrent des fois,
mais vois le point suivant ;
(3) dynamic_cast est vraiment conçu pour s'occuper des cast pour des
objets polymorphes ; s'il est utilisé pour des objets non
polymorphes, il y a erreur de « type ». C'est un critère de
conception, le but aboué étant de minimiser le plus possible, le
recours aux casts (ainsi éviter « bof, le compilateur fera
l'identité ici, donc c'est pas la même de se casser la tête pour
un design propre de mon programme »)
| > Je ne comprends pas la réponse. Dis-moi en un peu plus.
| Tu vois maintenant ce que tu exiges de nous, parfois :-)
Hmm, tu es scientifique ; tu sais ce que c'est :-)
| [en te paraphrasant : qu'est-ce que ça veut dire de définir f(x)
| pour tout x dans D, alors que, cette fonction étant constante,
| il n'y a aucune chance pour qu'elle vaille jamais autre chose
| que f(x0) ?]
C'est vraiment une paraphrase ça ?
"Alain Naigeon" writes:
| "Gabriel Dos Reis" a écrit dans le
message
| news:
| > | > Qu'est-ce que cela veut dire de faire un cast dynamique
lorsqu'il
| > | > n'y a aucune chance que le type dynamique de l'objet pointé ou
| référé
| > | > soit différent de ce que donne une analyse statique basé sur le
| > | > type du pointeur ou de la réféerence ?
| > |
| > | En exprimant les choses comme ci-dessus, il est tout de même
| > | facile de trouver une réponse : fonction constante.
|
| Eh bien : la première idée qui vient en réponse au dernier paragraphe,
| c'est : lorsque le type est connu à l'avance, le dynamic_cast pourrait
| avoir la politesse de renvoyer identiquement ce type, au lieu de faire
| "bêtement" une erreur.
Mais, ce n'est pas ce qu'on appelle une fonction constante ; tout
au plus, ce serait la fonction identité sur ce sous-ensemble là ;-)
| On peut, à la rigueur, envisager un warning
| sur l'inefficacité (?) de cet emploi, mais je ne vois pas pour quelle
| raison le refuser..?
(1) la norme ne définit pas de warning. Elle définit ce qu'elle
appelle un diagnstic. Si elle demander une diagnostic, c'est
qu'elle pense que la construction n'est pas valide.
(2) c'est déjà le boulot de static_cast -- on peut arguer que les
deux opérateurs ont des sémantiques qui se recouvrent des fois,
mais vois le point suivant ;
(3) dynamic_cast est vraiment conçu pour s'occuper des cast pour des
objets polymorphes ; s'il est utilisé pour des objets non
polymorphes, il y a erreur de « type ». C'est un critère de
conception, le but aboué étant de minimiser le plus possible, le
recours aux casts (ainsi éviter « bof, le compilateur fera
l'identité ici, donc c'est pas la même de se casser la tête pour
un design propre de mon programme »)
| > Je ne comprends pas la réponse. Dis-moi en un peu plus.
| Tu vois maintenant ce que tu exiges de nous, parfois :-)
Hmm, tu es scientifique ; tu sais ce que c'est :-)
| [en te paraphrasant : qu'est-ce que ça veut dire de définir f(x)
| pour tout x dans D, alors que, cette fonction étant constante,
| il n'y a aucune chance pour qu'elle vaille jamais autre chose
| que f(x0) ?]
C'est vraiment une paraphrase ça ?
