Discussion :

[poukill]

Bonjour à tous,

Ce matin, je me suis retrouvé face à un problème où le typeid m'arrange franchement bien. Je voudrais avoir votre avis sur ce tout petit bout de code:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
 
void CEventRecognitionEngine::AddEvent(const std::string& str)
{
	BOOST_FOREACH(boost::shared_ptr<IDescriptor> ptr, m_all_events)
	{
		if (typeid(*ptr).name() == str)
		{
			descriptor_ptr ptr = CObjectFactory<IDescriptor>::Instance().Create(str);
			m_vector_vision_chain.push_back(boost::static_pointer_cast<IEventDescriptor>(ptr)->GetVisionChain());
		}
	}
}

Si vous voyez ça dans un projet :
a) Vous fuyez. Ce code est horrible.
b) Vous vous dites que c'est une partie mal écrite
c) Ca dépend du contexte, parfois le typeid est utile.

pour vos éclaircissements.

[loufoque]

c) est vrai dans le cas général, mais là c'est vraiment a) et b).

[buzzkaido]

réponse d)

Si je vois ça dans un projet :
- je cherche les specs techniques du projet, en particulier le diagramme UML ou le diagramme de classes

- si un tel diagramme n'existe pas, ceci explique surement cela

- si ce diagramme existe, j'essaie de comprendre comment on en est arrivé là et comment faire autrement (emploi d'un visiteur ? emploi d'une fonction virtuelle ? emploi d'une factory ? en general 1 de ces 3 proposition regle le probleme)

- si effectivement, l'emploi de "typeid" est justifié, j'essaie de le "rationnaliser" afin d'eviter de faire n'importe quoi sous pretexte que c'est pratique : en l'encapsulant dans une fonction ou dans un pattern, par exemple.

[Davidbrcz]

typeid et typeof n'ont aucune constance garantie, c'est totalement dépendant du compilateur, des options et bien sur du code (héritage,....) .

Pour être sûr du résultat, il faut comparer à un objet de référence dont on est sûr du type.

[poukill]

OK, merci à tous, je vais donc changer mon fusil d'épaule...

[buzzkaido]

J'ajouterais une chose :

Si tu a une architecture du type :

class A
class B : public A
class C : public B

alors dans ton cas, le test

typeid(class B) == typeid(class C)

renvoit faux.

Alors que les deux (B et C) héritent de A. Selon les besoins, on pourrait vouloir que le test renvoi true.

En gros, il faut retenir que typeid renvoi le type concret de l'objet, et si on dérive l'objet, on a donc plus la même valeur.

Dans ce cas, il faut utiliser les propriétés du polymorphisme

[poukill]

Oui bien sûr.
D'ailleurs, dans mon projet j'ai déjà une factory, mais là c'était différent comme problème...
Je vais m'en sortir en rajoutant une méthode GetName() const

EDIT : Ok j'ai viré le typeid, c'est tout bon !

[hiura]

typeid et typeof n'ont aucune constance garantie, c'est totalement dépendant du compilateur [...]

Je me demande : est-ce que le prochain standard prévoit qqch là dessus ? ( Histoire que tous les compilateurs fassent parreil. )

[loufoque]

C'est pas le typeid qui est le plus gênant, c'est plutôt le fait que tu utilises std::type_info::name de cette manière...

Sinon typeof, qui est une extension GCC, n'a rien à voir avec typeid.