La question du RTTI en C++ est souvent assez chaude, on entend de tous les avis, et moi-même je suis passé dernièrement du “ah non jamais” au “c’est fantastique”. Avez-vous des expériences positives et/ou négatives à relater ?
[quote name=‘Drealmer’ date=’ 25 Mar 2005, 14:15’]La question du RTTI en C++ est souvent assez chaude, on entend de tous les avis, et moi-même je suis passé dernièrement du “ah non jamais” au “c’est fantastique”. Avez-vous des expériences positives et/ou négatives à relater ?
[right][post=“344129”]<{POST_SNAPBACK}>[/post][/right][/quote]
C’est fantastique!!
Et pour la plupart des applications, le temps nécessaire pour effectuer un dynamic_cast est vraiment négligeable.
Maintenant pour une application critique temps réel peut etre que ca n’est pas la bonne solution, mais pour moi c’est vraiment top!!!
c’est quo…ah euh oui ask google d’abord.
Run-Time Type Information. Informations de type ajoutées aux objets en mémoire par certains compilateurs de langage de haut niveau (à commencer par C++) et permettant de vérifier le typage des données lors de l’exécution du programme.
en gros, ce sont des infos de debug c’est bien ca?
mais on s’en sert comment?
[quote name=‘Berzehk’ date=’ 25 Mar 2005, 14:47’]en gros, ce sont des infos de debug c’est bien ca?
mais on s’en sert comment?
[right][post=“344139”]<{POST_SNAPBACK}>[/post][/right][/quote]
Non c’est pas du debug. Regarde l’exemple suivant, tu vas tout de suite comprendre:
[code]class A {};
class B : public A {};
void foo(A * pa) {
B * pb = dynamic_cast<B*>(pa);
if(pb) {
// on a reçu un pointeur vers une instance de la classe B
} else {
// on a reçu un pointeur vers une instance de la classe A
}
}[/code]
Ca demande des ressources supplementaires. Il faut donc s’en passer autant que possible.
Comme le dit si bien mon bouquin de cpp, mettre tout en dynamic_cast pour commencer et une fois que l’on a quelque chose de fonctionnel on ramene tous les dynamic cast que l’on peut en static_cast.
Tres bon bouquin que je conseille et qui parle de tout ce qui est interessant (STL, RTTI, design patterns) : http://www.amazon.fr/exec/obidos/ASIN/2100…6244947-9053810
On peut egalement faire des tests directement avec le type d’un objet en utilisant typeid mais ca c’est a priori fort deconseille.
PS: avis base sur de petits codes pas bien pretentieux, etudiant oblige.
[quote name=‹ Asarnil › date=’ 25 Mar 2005, 15:50’]Comme le dit si bien mon bouquin de cpp, mettre tout en dynamic_cast pour commencer et une fois que l’on a quelque chose de fonctionnel on ramene tous les dynamic cast que l’on peut en static_cast.
[right][post=« 344156 »]<{POST_SNAPBACK}>[/post][/right][/quote]
Le dynamic_cast n’est pas très coûteux, mais faut savoir où l’utiliser. Au milieu d’une boucle exécutée 500 fois par frame par exemple, c’est pas une bonne idée 
Pour les tools, les convertisseurs et tout ce qui est offline, j’aurais tendance a bien aime, voir a trouver ca pratique de temps en temps…
Pour l’embarque : je prefererais mourir !! j’(enfin on…) utilise soit une version maison, souvent plus efficace et plus petites en memoire, soit on se debrouille pour ne pas en avoir besoin (ce qui permet bien souvent, en fait, d’avoir des belles mains loop groupe par type, avec tout l’interet que ca a au nivo gestion de la memoire, cache et parallelisme !). Mais bon, je suis old skool aussi
Je suis assez d’accord avec c0unt0, mais j’irai même plus loin. Pour le runtime, je préfére le proscrire (parce qu’il génére du code et des données mémoire que je ne peux pas contrôler précisément et qui dépendent en grande partie du compilateur), pour les outils… ben je préfére le C# Et la le RTTI est embedded donc même plus la peine d’en parler
J’aurais aimé répondre au sondage, mais euh c’est quoi le RTTI?
[quote name=’[PERE]Cil’ date=’ 29 Mar 2005, 07:45’]J’aurais aimé répondre au sondage, mais euh c’est quoi le RTTI?
[right][post=« 344950 »]<{POST_SNAPBACK}>[/post][/right][/quote]
Ben… lis les posts du thread, c’est expliqué Et sinon Google est ton ami
En fait je voullais dire comme Tuo, mais j’etait de bonne humeur, donc plutot que mon classique « RTTI? Moi Vivant JAMAIS !!! » j’ai ecrit un plus diplomatique « Oui, faut voir, mais non »
[quote name=‹ c0unt0 › date=’ 29 Mar 2005, 20:08’]En fait je voullais dire comme Tuo, mais j’etait de bonne humeur, donc plutot que mon classique « RTTI? Moi Vivant JAMAIS !!! » j’ai ecrit un plus diplomatique « Oui, faut voir, mais non »
[right][post=« 345265 »]<{POST_SNAPBACK}>[/post][/right][/quote]
C’est rigolo je t’ai trouvé plus extremiste que moi pourtant
Vous me faites douter, et comme je sais que tuo et c0unt0 ne sont pas vraiment des petits nouveaux dans le domaine, j’ai tendance à vous croire
Mais voilà, le RTTI c’est très pratique. Pas seulement pour tester, mais aussi pour la logique même du programme. Un scenegraph sans RTTI par exemple, j’ai du mal à concevoir, car soit on a 35 types de listes de descendants pour chaque noeud, soit on a des noeuds bardés de fonctions virutelles jusqu’à la moelle qui font qu’au final on n’est plus trop sûr de ce qu’on fait en appelant une fonction.
Et même en règle générale, tout ce qui nécessite une hiérarchie relativement compliquée me semble délicat à gérer sans RTTI. Comment faites-vous ?
Une autre question, c’est que d’un côté (ici) j’entends « le RTTI maison est mieux, car le RTTI du C++ est trop lourd » et d’un autre côté (plein de livres) « le RTTI du C++ est mieux car il existe déjà, il est fiable, et réinventer la poudre à chaque fois ne sert qu’à perdre du temps et perturber les programmeurs qui doivent sans cesse passer d’un système à l’autre ». A quel point est-ce plus lourd ?
Mais d’un autre côté, tous les SDK que j’utilise et qui tirent parti du RTTI ont leur propre « homebrewd » RTTI… Et c’est pas du petit freeware en version alpha 0.1 trouvé sur sourceforge, c’est des gros bouts qu’on retrouve dans pas mal de gros jeux actuels et à venir. (peux pas en dire trop, NDA et tout ça)
Il doit y avoir une raison… Un support du RTTI du C++ différent selon les compilateurs ? Ca marche moins bien sur consoles ? Ou bien y’a vraiment une grosse surchage ? Et niveau performances ?
Quelqu’un a-t-il un lien vers un article critique sur le RTTI du C++ ?
edit : en réfléchissant un peu, je me demande si la principale critique du RTTI du C++ n’est pas que quand on l’active, on l’a partout, et pas seulement là où on en a vraiment besoin.
Aucun liens, c’est plus de l’experience.
Je pense que tout les examples (compilos, marche moins bien, moins de controles, occupation memoire, onl’active-onl’apartout) sont vrais, et des cas que j’ai rencontre.
L’interet d’avoir une solution propre a un SDK/namespace est que tu controle exactement comment ca marche, ou ca s’applique, et surtout comment : si ta platforme n’aime pas les virtual functions, tu fais sans, si elle aime pas les bytes ou les short, tu fais sans, etc… etc…
Ta remarque sur le scenegraph est valide, mais non.
Peut etre dans un cas generique, ou tu ne sais pas ce que tu va rendre, mais dans la plus part des jeux, tu as grands maximum une 10aine de type d’objet utilisable pour composer ta scene (genre lumiere, pietons, perso, voitures, building, et accessoires… et la deja je commence a secher…).
Ne pas avoir de RTTI te force a organise ta render loop de maniere plus propre et plus precise, car effectivement, sans RTTI tu risques de faire un truc pas tres jolis et surtout pas rapide !
C’est épouvantable, je n’arrive pas à formuler une réponse correcte. Ca fait dix fois que je relis ton post, c0unt0, et ça fait trois fois que je tape une réponse sans parvenir à quoi que ce soit de satisfaisant.
Je suis toujours tiraillé entre des idées contradictoires qui se bousculent dans ma petite tête. Je bénis le jour où je trouverai enfin une idée que me satisfera plus de quelques mois. Je reviens peu à peu de mon enthousiasme pour le RTTI, tout en le considérant comme un allié de poids lorsqu’il s’agit de trucs qui ne sont pas frame based (et y’a trois mois, j’aurais juré ne jamais toucher à cet engance démoniaque).
Merde, je veux un baxter d’expérience, tout de suite !
(quoi qu’il en soit, merci pour tes interventions, elles m’ont bien fait cogiter)
A priori, les problèmes des RTTI sont un peu tous ceux que tu cite, plus la méconnaissance par nombre de codeurs C++ de ces mécanismes. Quand je vois le niveau du codeur de jeu moyen en C++ (et a priori, pas uniquement de jeu en fait ), je me dis qu’il vaut mieux éviter d’employer ce genre de choses. Parce qu’on pourrait trop vite se dire, quand un nouveau programmeur arrive par exemple, que vu que ça fait partie du langage, c’est un « acquis ». Le problème c’est que c’est pas forcément bien acquis par tout le monde.
Du coup, je préfére en fait me faire mon propre système de « RTTI maison », qui de toute façon est assez vite fait vu l’usage relativement basique qu’on en fait.
Concernant ton scenegraph, je ne vois pas ce qu’apporte le RTTI que l’on ne peut pas faire manuellement : a priori, si tu utilises les RTTI, c’est qu’à un moment tu as utilisé tes types de manière explicite. A partir de ce moment là, je ne vois rien qu’un système de RTTI maison ne puisse faire. Une chtite hiérarchie de classes et on n’en parle plus.
Et puis pour les outils, je vais faire mon lourd insistant, mais C# pawah, et la tout est over-RTTI-tisé, donc pas de soucis