RECONNAISSANCE DE TYPES D'OBJETS EN C++
cosmobob
Messages postés
700
Date d'inscription
mardi 30 décembre 2003
Statut
Membre
Dernière intervention
27 janvier 2009
-
18 janv. 2006 à 11:00
profringo666 Messages postés 6 Date d'inscription lundi 30 juin 2003 Statut Membre Dernière intervention 5 janvier 2007 - 5 janv. 2007 à 18:09
profringo666 Messages postés 6 Date d'inscription lundi 30 juin 2003 Statut Membre Dernière intervention 5 janvier 2007 - 5 janv. 2007 à 18:09
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/35631-reconnaissance-de-types-d-objets-en-c
https://codes-sources.commentcamarche.net/source/35631-reconnaissance-de-types-d-objets-en-c
5 janv. 2007 à 18:09
Ca pourrait etre pratique d'avoir direcment le type de l'objet qui n'est pas correctement desalloue quand on utilise un memory manager.
Car tres souvent on oublie de detruit les Singletons.
10 déc. 2006 à 09:58
c'est quand même pas exactement ça le résultat produit (au moins avec gcc).
Cela affiche le nom de la classe avec des chiffres.
Par exemple :
1A
Ceci car il faut differencier les objets.
23 janv. 2006 à 17:56
admettons qu'on veuille écrire une classe de qui écrive des traces et des logs redirigés vers une sortie standard.
on veut quelque chose du type:
maclasse::MaMethodeQuiPlante()
{
MaTrace.Screen("maclasse::MaMethodeQuiPlante");
InstructionQuiPlante();
MaTrace.out();
}
il serait pratique de ne pas avoir à recopier à chaque fois ::MaMethodeQuiPlante
combinée à la surcharge d'opérateur cette astuce serait bien pratique si on pouvait récupérer le nom de la méthode
19 janv. 2006 à 18:51
Pour la 3ième fois -> une astuce est une astuce. Si des programmeurs ont créé cette bilbliothèque, c'est qu'il y avait un besoin. Mais je suis entièrement d'accord pour dire que la conception polymorphe est largement plus avantageuse.
Pour conclure, c'est une ASTUCE (et de 4!).
19 janv. 2006 à 18:10
Cordialement,
Xter.
19 janv. 2006 à 17:38
19 janv. 2006 à 16:10
Tu as aussi le droit de lire l'explication, je cite:
"Les puristes vous diront que le langage objet est fait pour se délester des problèmes de typage grâce aux fonctions virtuelles. Certes, mais une astuce reste une astuce et des fois ça peut nous sortir du pétrin donc autant en faire profiter !"
Et par ailleurs je suis du même avis que toi ^^ mais une astuce reste une astuce.
19 janv. 2006 à 15:13
18 janv. 2006 à 11:18
Merci
18 janv. 2006 à 11:00
ton exemple n'a pas beaucoup d'interet, car l'information de typage est ici connu a la compilation et pas a l'execution (pas pendant le runtime) puisque tes objets sont pas alloués dynamiquement.
Pour faire quelque chose d'un peu plus malin:
class A
{
public:
virtual ~A(){}; // au moins une fonction virtual necessaire pour que le compilo utilise une table de typage dynamique a l'execution
};
class B : public A
{
};
A* ptr1 = new A;
A* ptr2 = new B; // licite car B derive de A
cout << "ptr1 est de type : " << typeid(*ptr1).name() << endl;
cout << "ptr2 est de type : " << typeid(*ptr2).name() << endl;
on voit que pour bien obtenir ce qu'il faut ( ptr1 de class A, ptr2 de class B), il faut avoir activé enable RunTime Type Info dans vs7.
et voila ... update ta source avec cette remarque
a+