Comment puis-je vérifier si un objet est une sous-classe donnée en C++?

Je pensais le long des lignes de l'aide typeid() mais je ne sais pas comment faire pour demander si ce type est une sous-classe d'une autre classe (qui, au passage, est abstraite)

InformationsquelleAutor Chad | 2008-11-21
  1. 41

    Vous ne devriez vraiment pas. Si votre programme doit connaître la classe d'un objet, qui indique généralement un défaut de conception. Voir si vous pouvez obtenir le comportement que vous souhaitez à l'aide de fonctions virtuelles. Aussi, plus d'informations sur ce que vous essayez d'aider.

    Je suis en supposant que vous avez une situation comme celle-ci:

    class Base;
class A : public Base {...};
class B : public Base {...};

void foo(Base *p)
{
  if(/* p is A */) /* do X */
  else /* do Y */
}

    Si c'est ce que vous avez, alors essayez de faire quelque chose comme ceci:

    class Base
{
  virtual void bar() = 0;
};

class A : public Base
{
  void bar() {/* do X */}
};

class B : public Base
{
  void bar() {/* do Y */}
};

void foo(Base *p)
{
  p->bar();
}

    Edit: Depuis le débat à propos de cette réponse se poursuit encore après tant d'années, j'ai pensé que je devrais jeter un peu de références. Si vous avez un pointeur ou une référence à une classe de base, et que votre code doit connaître la classe dérivée de l'objet, alors elle viole Principe de substitution de Liskov. Oncle Bob appelle cela un "de l'anathème à la Conception Orientée Objet".

    • +1. Je pense que le nom exact c'est "Dire, ne demandez pas". Fondamentalement, toujours en faveur de polymorphisme (le fait de Dire d'un objet qu'à faire, de laisser la mise en œuvre de prendre soin d'elle) sur un cas/si l'état où vous DEMANDEZ de trouver ce type d'objet que vous travaillez avec.
    • hé oui, c'est une bonne chose - mais le gars voulait savoir sur la façon de résoudre type
    • JohnIdol, je l'obtiens. Et c'est toujours une mauvaise idée.
    • et si quelqu'un veut connaître la syntaxe juste à des fins d'apprentissage (disons qu'ils vont par le biais d'un livre écrit en Java, à propos des défauts de conception, et ils ont besoin de traduire que de C++)?
    • J'ai besoin de savoir le type d'un objet à des fins de débogage, parce que j'ai besoin de savoir ce que les objets étranges sont s'insérer dans mon dictionnaire et de le rendre crash. Est-il aucun espoir? dynamic_cast semble impossible, parce que le type de l'objet pourrait être presque n'importe quoi.
    • Une commune de cas d'utilisation pour ce faire (au moins en Java), c'est quand on compare deux objets pour l'égalité. Habituellement, vous voulez vérifier si elles sont de la même sous-classe avant de vérifier les propriétés requises pour l'égalité.
    • Corriger tout cela ne répond pas à la question.
    • Jamais travaillé avec une bibliothèque externe qui définit des super-classes? Essayez d'appliquer votre réponse s'il vous plaît.
    • vous pouvez certainement trouver des cas où vous voudrez peut-être savoir le type réel de l'objet. Toutefois, cela signifie quand même que vous vous battez la langue, et qu'il n'y est sous-jacente d'un défaut de conception. La faille peut-être bien dans une bibliothèque tierce, mais c'est toujours une faille. Si vous n'avez aucun contrôle sur elle, alors vous avez à vivre avec elle. Si vous avez le contrôle, alors vous devriez penser à propos de la fixation de la conception sous-jacente.
    • C'est juste votre opinion personnelle, sans offense. J'ai, au contraire, ne pas voir quelque chose de mal avec la coulée aux supertypes de leurs classes dérivées lorsque cela est nécessaire. En fait, c'est énorme partie de la programmation orientée objet utilisez - le pipelining des données similaires par le biais de certains processus générique, mais de les traiter individuellement à la fin.
    • C'est plus que juste mon opinion personnelle. Si vous avez besoin de connaître le type dérivé de l'objet, alors votre conception viole le principe de substitution de Liskov: en.wikipedia.org/wiki/Liskov_substitution_principle Voici un papier par Robert C. Martin, où il a spécifiquement parle de pourquoi en demandant le type de l'objet de la violation de LSP, et pourquoi c'est un "anathème à la Conception Orientée Objet": objectmentor.com/resources/articles/lsp.pdf
    • Cette réponse est plutôt le énorme en supposant que vous avez un contrôle sur les types de vous avez besoin pour lancer et peut réécrire... Par exemple, je vais ajouter une fonctionnalité à une bibliothèque d'interface graphique basée sur un autre bibliothèque d'interface graphique, et j'ai besoin de savoir si le parent d'un widget scrollable. La bibliothèque d'origine n'offre aucun moyen de tester cela j'ai donc essayer et jeté mes widgets parent de la classe de base de défilement des widgets, qui aspire vraiment. De toute façon, le point est que vous avez quitté le réel réponse à la question à portée de main.
    • Une utilisation valide est lors de l'essai que l'usine qui retourne un pointeur sur une interface à une instance d'une sous-classe pour un ensemble donné d'intrants.
    • avec tout le respect dû, c'est incorrect. Si une usine renvoie un pointeur sur une interface, et vous avez encore besoin de connaître la sous-classe, alors il n'est pas une très bonne interface. Le point de l'ensemble de l'interface est de faire abstraction du sous-jacent sous-classe, j'. e. pour vous permettre de l'utiliser sans savoir ce que le sous-jacent sous-classe est.
    • Pour la production de code, je suis d'accord avec vous. Mais le travail de l'usine est de faire le bon sous-classe en fonction de ses entrées. Il est possible de tester l'usine et chaque sous-classe ensemble en vérifiant que les propriétés de la sous-classe sont compatibles avec les entrées. Mais si il y a un bug, alors qu'un tel test ne va pas aider quelqu'un dire si le problème est dans l'usine ou dans la sous-classe, il s'appuie. Vérifier le type de la sous-classe est une façon de réaliser la séparation dans ce genre de tests.
    • Pourquoi ne pas séparer les tests pour les sous-classes, où les objets sont créés sans l'usine? Qui séparerait les bugs dans la sous-classe de bugs dans l'usine.
    • Qui pourrait fonctionner, mais pour la maintenabilité, vous voulez un moyen de garder la couverture de combiné usine+sous-classes identiques avec des sous-classes sur leur propre, de sorte que l'échec du test combiné serait clairement identifier l'usine. Qui pourrait facilement être que le code de test séparément, en particulier si l'usine fait la même sous-classe pour les différentes combinaisons de facteurs, mais vous avez à faire valoir sur tous les comportements de cette sous-classe. Donc je pense qu'il est utile de reconnaître que le travail de l'usine est de rendre les sous-classes, et c'est valable pour vérifier le béton sous-classe type.
    • Je ne suis pas sûr que je suis... Les tests pour la sous-classe de comportement n'ont pas besoin de l'usine, si vous pouvez créer leurs objets directement. D'autre part, les tests de l'usine devrait être d'essais qu'il réussit à créer le bon type de l'objet. Il devrait être possible de vérifier avec un test simple, sans vérification de tous les comportements possibles de l'objet, et sans avoir à interroger l'objet de type sous-jacent. Je pense qu'il fait beaucoup de sens pour séparer les tests pour l'usine et pour les objets qu'elle produit.
    • Oui, les sous-classes doivent généralement être testable dans l'isolement de l'usine, et l'usine devrait être vérifié avec un test simple. C'est là vérifier le type est utile. Imaginer la fabrication d'un ensemble de neuf sous-classes, chacune avec trois comportements, chaque de ce qui se déclinent en trois saveurs. Je ne peux pas penser à un simple test de l'usine d'autre que le type de la sous-classe. Les tests tous les trois comportements, pour l'ensemble des neuf sous-classes des risques de re-mise en œuvre de l'usine de la logique.
    • Depuis quand les coproduits est devenu un défaut de conception? Et non, ce ne sont pas nécessairement rompre le principe de Liskov. E. g. J'ai une classe de l'Arbre, et les sous-classes de Nœud et de Feuilles, et je veux le branche sur si je suis arrivé à la Feuille. Comment dois-je viole Liskov de la règle?
    • Downvoted parce qu'il ne répond pas à la question. Le monde n'a pas la liberté de travailler avec parfaitement conçu de code.

    InformationsquelleAutor Dima
  2. 91

     

    class Base
{
  public: virtual ~Base() {}
};

class D1: public Base {};

class D2: public Base {};

int main(int argc,char* argv[]);
{
  D1   d1;
  D2   d2;

  Base*  x = (argc > 2)?&d1:&d2;

  if (dynamic_cast<D2*>(x) == nullptr)
  {
    std::cout << "NOT A D2" << std::endl;
  }
  if (dynamic_cast<D1*>(x) == nullptr)
  {
    std::cout << "NOT A D1" << std::endl;
  }
}
    • Avez-vous vraiment besoin d'un dynamic_cast<> ici? N'est-ce pas static_cast<> être assez?
    • Pouvez-vous dire le type de x au moment de la compilation? Si oui, alors static_cast<>() serait de travailler. Si vous ne pouvez pas dire le type de x jusqu'à l'exécution, alors vous devez dynamic_cast<>()
    • Merci. Je suis en utilisant downcasts principalement dans le PROGRAMME de formation itinérante, je garde d'oublier les autres cas d'utilisation 😉
    InformationsquelleAutor Martin York
  3. 21

    Vous pouvez le faire avec dynamic_cast (au moins pour les types polymorphes).

    En fait, à bien y penser, on ne peut dire si c'est SPÉCIFIQUEMENT un type particulier avec dynamic_cast--mais vous pouvez dire si c'est ce type ou d'une sous-classe de celle-ci.

    template <class DstType, class SrcType>
bool IsType(const SrcType* src)
{
  return dynamic_cast<const DstType*>(src) != nullptr;
}
    • Quand est une sous-classe pas un type polymorphe?
    • quand il n'y a pas de fonctions virtuelles.
    • Agh oh pinaise. Merci.
    InformationsquelleAutor Drew Hall
  4. 6

    dynamic_cast pouvez déterminer si le type contient le type de cible n'importe où dans la hiérarchie d'héritage (oui, c'est une fonctionnalité peu connue que si B hérite de A et C, il peut tourner un A* directement dans un C*). typeid() pouvez déterminer le type exact de l'objet. Toutefois, ceux-ci devraient à la fois être utilisé très rarement. Comme il a été déjà mentionné, vous devriez toujours être en évitant de type dynamique d'identification, car il indique un défaut de conception. (aussi, si vous savez que l'objet est à coup sûr du type de cible, vous pouvez faire un abattu avec une static_cast. Boost offre un polymorphic_downcast, qui sera abattu avec dynamic_cast et assert en mode debug, et en mode release, il suffit d'utiliser un static_cast).

    InformationsquelleAutor coppro
  5. 4

    Je suis en désaccord que vous ne devriez jamais vous voulez vérifier le type de l'objet en C++. Si vous pouvez l'éviter, je suis d'accord que vous devriez. Dire que vous ne devriez JAMAIS faire cela en toute circonstance est aller trop loin cependant. Vous pouvez le faire dans un grand nombre de langues, et il peut rendre votre vie beaucoup plus facile. Howard Pinsley, par exemple, nous a montré comment, dans son post sur le C#.

    Je fais beaucoup de travail avec le Framework Qt. En général, j'ai le modèle de ce que je fais après la manière de faire les choses (au moins quand travail dans leur cadre). La classe QObject est la classe de base de tous les objets Qt. Cette classe a pour fonctions isWidgetType() et isWindowType() comme sous-classe de la vérifier. Alors pourquoi ne pas être en mesure de vérifier vos propres classes dérivées, ce qui est comparable dans la nature? Voici un QObject spin-off de certains de ces autres postes:

    class MyQObject : public QObject
{
public:
    MyQObject( QObject *parent = 0 ) : QObject( parent ){}
    ~MyQObject(){}

    static bool isThisType( const QObject *qObj )
    { return ( dynamic_cast<const MyQObject*>(qObj) != NULL ); }
};

    Et puis, quand vous êtes de passage autour d'un pointeur vers un QObject, vous pouvez vérifier si il des points à votre classe dérivée par l'appel de la fonction membre statique:

    if( MyQObject::isThisType( qObjPtr ) ) qDebug() << "This is a MyQObject!";
    InformationsquelleAutor BuvinJ
  6. 4

    Je ne sais pas si j'ai bien compris votre problème correctement, alors permettez-moi de reformuler dans mes propres mots...

    Problème: étant Donné classes B et D, de déterminer si D est une sous-classe de B (ou vice-versa?)

    Solution: Utilisation de certains modèles de la magie! Bon, sérieusement vous avez besoin de prendre un coup d'oeil à LOKI, un excellent modèle de méta-programmation de la bibliothèque produit par le légendaire C++ auteur Andrei Alexandrescu.

    Plus précisément, télécharger LOKI et inclure l'en-tête TypeManip.h dans votre code source puis utilisez le SuperSubclass modèle de classe comme suit:

    if(SuperSubClass<B,D>::value)
{
...
}

    Selon la documentation, SuperSubClass<B,D>::value sera vrai si B est une base publique de D, ou si B et D sont des alias du même type.

    c'est à dire soit D est une sous-classe de B ou D est le même que B.

    J'espère que cette aide.

    edit:

    Veuillez noter que l'évaluation de SuperSubClass<B,D>::value qui se passe au moment de la compilation contrairement à certaines méthodes qui utilisent dynamic_cast, donc il n'y a pas de pénalité pour l'utilisation de ce système lors de l'exécution.

    InformationsquelleAutor Autodidact
  7. 2
    #include <stdio.h>
#include <iostream.h>

class Base
{
  public: virtual ~Base() {}

  template<typename T>
  bool isA() {
    return (dynamic_cast<T*>(this) != NULL);
  }
};

class D1: public Base {};
class D2: public Base {};
class D22: public D2 {};

int main(int argc,char* argv[]);
{
  D1*   d1  = new D1();
  D2*   d2  = new D2();
  D22*  d22 = new D22();

  Base*  x = d22;

  if( x->isA<D22>() )
  {
    std::cout << "IS A D22" << std::endl;
  }
  if( x->isA<D2>() )
  {
    std::cout << "IS A D2" << std::endl;
  }
  if( x->isA<D1>() )
  {
    std::cout << "IS A D1" << std::endl;
  }
  if(x->isA<Base>() )
  {
    std::cout << "IS A Base" << std::endl;
  }
}

    Résultat:

    IS A D22
IS A D2
IS A Base
    InformationsquelleAutor Reinaldo Guedes
  8. 1

    Vous ne pouvez le faire qu'au moment de la compilation à l'aide de modèles, sauf si vous utilisez RTTI.

    Elle permet d'utiliser le typeid fonction qui donnera un pointeur vers un type_info structure qui contient des informations sur le type.

    Lire à Wikipédia

    • Voté pour mentionner RTTI dans ce contexte, que tout le monde, tout simplement ignorés.
    InformationsquelleAutor user32141
  9. 1

    En c# vous pouvez simplement dire:

    if (myObj is Car) {

}
    • J'ai répondu à cette question, l'affiche édition-ed sa question et a indiqué que son choix de langue.
    • Je suis upvoting, c'est de ne pas répondre de la faute de l'OP précisé sa demande.
    • Eh bien, maintenant il a précisé c++ si cette réponse est fausse
    InformationsquelleAutor Howard Pinsley
  10. 0

    Je pensais le long des lignes de l'aide typeid()...

    Bien, oui, ça pourrait être fait en comparant: typeid().name(). Si nous prenons les déjà décrit la situation où:

    class Base;
class A : public Base {...};
class B : public Base {...};

void foo(Base *p)
{
  if(/* p is A */) /* do X */
  else /* do Y */
}

    Une possible mise en œuvre de foo(Base *p) serait:

    #include <typeinfo>

void foo(Base *p)
{
    if(typeid(*p) == typeid(A))
    {
        //the pointer is pointing to the derived class A
    }  
    else if (typeid(*p).name() == typeid(B).name()) 
    {
        //the pointer is pointing to the derived class B
    }
}
    InformationsquelleAutor Ziezi
  11. 0

    Le code ci-dessous montre 3 différentes façons de le faire:

    • fonction virtuelle
    • typeid
    • dynamic_cast
    #include <iostream>
#include <typeinfo>
#include <typeindex>
enum class Type {Base, A, B};
class Base {
public:
virtual ~Base() = default;
virtual Type type() const {
return Type::Base;
}
};
class A : public Base {
Type type() const override {
return Type::A;
}
};
class B : public Base {
Type type() const override {
return Type::B;
}
};
int main()
{
const char *typemsg;
A a;
B b;
Base *base = &a;             //= &b;    !!!!!!!!!!!!!!!!!
Base &bbb = *base;
//below you can replace    base    with  &bbb    and get the same results
//USING virtual function
//======================
//classes need to be in your control
switch(base->type()) {
case Type::A:
typemsg = "type A";
break;
case Type::B:
typemsg = "type B";
break;
default:
typemsg = "unknown";
}
std::cout << typemsg << std::endl;
//USING typeid
//======================
//needs RTTI. under gcc, avoid -fno-rtti
std::type_index ti(typeid(*base));
if (ti == std::type_index(typeid(A))) {
typemsg = "type A";
} else if (ti == std::type_index(typeid(B))) {
typemsg = "type B";
} else {
typemsg = "unknown";
}
std::cout << typemsg << std::endl;
//USING dynamic_cast
//======================
//needs RTTI. under gcc, avoid -fno-rtti
if (dynamic_cast</*const*/ A*>(base)) {
typemsg = "type A";
} else if (dynamic_cast</*const*/ B*>(base)) {
typemsg = "type B";
} else {
typemsg = "unknown";
}
std::cout << typemsg << std::endl;
}

    Le programme ci-dessus affiche le:

    type A
type A
type A
    InformationsquelleAutor ajneu