ah bon????? C'est pourtant à ça que serve les cast (ahhh les joies du void* ); ce qui est quand même pratique car s'il le compilo râlait dès qu'on faisait un malloc, y aurait un bon paquet de truc inutile à chaque compile ^^
C'est bien ce que je dis : tu es obligé de faire un cast explicite pour convertir un type dans un autre avant de le passer à ta fonction. Dans ce cas, tu ne pourras pas dire que le compilateur ne t'as pas prévenu. C'est bien toi qui lui dit alors « Non, mais c'est bon, je sais ce que je fais ». Et encore, ça passe quand tu fais un cast sur un pointeur de structure. Si tu passes la structure elle-même, tu ne peux pas la transtyper directement vers une autre, et ça ne compilera pas du tout.
A contrario, tu peux caster de la même façon les instances de variables d'un langage orienté objet. Donc l'argument ne tient pas, ici.
Mon petit doigt me dit que union vient foutre la merde dans ce souhait pieux :D
Absolument pas.
« union » permet de passer une instance de quelque chose dont le type est l'un de ceux énumérés par « union ». Un exemple assez parlant de combinaison struct/union sont les XEvent de X-Window. XEvent est une union de structures plus spécialisées comme XKeyEvent, XButtonEvent, XMotionEvent, XExposeEvent, etc. et qui partagent toutes un membre commun initial en début de déclaration , «int type », qui en plus est lui-même inclus par l'union. Et comme le C garantit que les adresses des membres d'une structure progressent dans l'ordre où ils ont été déclarés et que le padding ne peut se trouver qu'après un membre (C99 6.7.2.1§13), alors on est sûr que ce membre sera bien commun à XEvent et toutes les autres structures unies en dessous, quel que soit le compilateur.
À ce stade,
— la totalité de l'objet est donc transmis lorsque X-Window émet un événement ;
— il contient la totalité des informations qui le décrivent (comprendre : ce n'est pas un message qui invite le programme à aller se renseigner) ;
— « XEvent » contiendra toujours l'événement en entier même si la norme évolue (il faudra recompiler le programme mais pas le réécrire) ;
— même s'il faut consulter « type », le programme peut savoir de façon déterministe quel objet il a reçu ;
— Une fonction faite pour traiter un événement en particulier aura besoin que tu lui passes, non pas XEvent, mais l'un de ses membres explicitement, qui lui a le type qui correspond à la signature de la fonction. Donc, tout le contrôle peut être fait à la compilation, et il n'y aucun magic cast qui entre en jeu pour faire fonctionner le modèle.
À lire un autre de tes commentaires, il semblerait que, pour toi, un objet est une classe qui dérive de Object, par opposition, donc, aux types natifs. Si c'est bien le cas et que c'est là, pour toi, le dogme central de la programmation orientée objet, alors il faudrait au moins que tu pratiques d'autres langages de manière sérieuse pour te faire une idée objective... (sans mauvais jeu de mot).
[^] # Re: Quelqu'un dans l'assemblée saurait "vendre" le concept de POO ?
Posté par Obsidian . En réponse au journal Le problème de la POO pratiquée par des étudiants. Évalué à 3.
C'est bien ce que je dis : tu es obligé de faire un cast explicite pour convertir un type dans un autre avant de le passer à ta fonction. Dans ce cas, tu ne pourras pas dire que le compilateur ne t'as pas prévenu. C'est bien toi qui lui dit alors « Non, mais c'est bon, je sais ce que je fais ». Et encore, ça passe quand tu fais un cast sur un pointeur de structure. Si tu passes la structure elle-même, tu ne peux pas la transtyper directement vers une autre, et ça ne compilera pas du tout.
A contrario, tu peux caster de la même façon les instances de variables d'un langage orienté objet. Donc l'argument ne tient pas, ici.
Absolument pas.
« union » permet de passer une instance de quelque chose dont le type est l'un de ceux énumérés par « union ». Un exemple assez parlant de combinaison struct/union sont les XEvent de X-Window. XEvent est une union de structures plus spécialisées comme XKeyEvent, XButtonEvent, XMotionEvent, XExposeEvent, etc. et qui partagent toutes un membre commun initial en début de déclaration , «int type », qui en plus est lui-même inclus par l'union. Et comme le C garantit que les adresses des membres d'une structure progressent dans l'ordre où ils ont été déclarés et que le padding ne peut se trouver qu'après un membre (C99 6.7.2.1§13), alors on est sûr que ce membre sera bien commun à XEvent et toutes les autres structures unies en dessous, quel que soit le compilateur.
À ce stade,
— la totalité de l'objet est donc transmis lorsque X-Window émet un événement ;
— il contient la totalité des informations qui le décrivent (comprendre : ce n'est pas un message qui invite le programme à aller se renseigner) ;
— « XEvent » contiendra toujours l'événement en entier même si la norme évolue (il faudra recompiler le programme mais pas le réécrire) ;
— même s'il faut consulter « type », le programme peut savoir de façon déterministe quel objet il a reçu ;
— Une fonction faite pour traiter un événement en particulier aura besoin que tu lui passes, non pas XEvent, mais l'un de ses membres explicitement, qui lui a le type qui correspond à la signature de la fonction. Donc, tout le contrôle peut être fait à la compilation, et il n'y aucun magic cast qui entre en jeu pour faire fonctionner le modèle.
À lire un autre de tes commentaires, il semblerait que, pour toi, un objet est une classe qui dérive de Object, par opposition, donc, aux types natifs. Si c'est bien le cas et que c'est là, pour toi, le dogme central de la programmation orientée objet, alors il faudrait au moins que tu pratiques d'autres langages de manière sérieuse pour te faire une idée objective... (sans mauvais jeu de mot).