3. type_info::name für unterschiedliche Klassen immer verschieden?

type_info::name für unterschiedliche Klassen immer verschieden?

  • B

    Folgendes geht:

    class Base{
public:
  virtual unsigned get_id()const=0;
};

template<class T>
class DeriveFromBase:public Base{
public:
  virtual unsigned get_id()const{
    return get_type_id<T>();
  }
};

class Child:public DeriveFromBase<Child>{

};

    Dadurch, dass man this nach T* in DeriveFromBase castet kann man noch viele schöne Sachen machen. Zum Beispiel eine Clonefunktion welche den (möglicherweise implizit erzeugten) Kopiekonstruktor der Kindklasse verwendet.

    Alternativ kann man auch eine Makro DEFAULT_METHODS definieren und in jede Childklasse reinpacken. Dieser Ansatz erlaubt es zusätzlich den Klassennamen portabel aber nicht eindeutig in einen String zu kriegen.

    0
  • ?

    Dravere schrieb:

    TypeInfo(std::type_info const& type)
    : m_type(&type)
  {
  }

    hmm, hier sehe ich das problem, dass der zeiger zu einem späteren zeitpunkt ins leere verweisen kann, nämlich nachdem der block verlassen wurde, in dem dieser konstruktor aufgerufen wurde. oder garantiert mir der standard, dass die adresse des von typeid zurückgegebenen objektes immer gültig bleibt? wäre schön...

    0
  • Administrator

    C++ Standard 98:
    Kapitel 5.2.8 Type Identification
    Abschnitt 1

    The result of a typeid expression is an lvalue of static type const std::type_info (18.5.1) and dynamic type const std::type_info or const name where name is an implementation-defined class derived from std::type_info which preserves the behavior described in 18.5.1. The lifetime of the object referred to by the lvalue extends to the end of the program. Whether or not the destructor is called for the type_info object at the end of the program is unspecified.

    Grüssli

    0
  • N

    Du kannst auch gleich Boost.Pointer Container verwenden, die stellen keine Anforderungen bezüglich Kopierbarkeit. Oder Standardcontainer mit shared_ptr .

    0
  • Administrator

    Nexus schrieb:

    Du kannst auch gleich Boost.Pointer Container verwenden, die stellen keine Anforderungen bezüglich Kopierbarkeit. Oder Standardcontainer mit shared_ptr .

    Welche dann ein delete auf den Zeiger von std::type_info durchführen. Huiiiii, schöööönes Feuerwerk 🙂
    Ok, beim shared_ptr könnte man das abschalten. Aber der Overhead vom shared_ptr ist völlig unnötig. Es muss keine Referenzzählung stattfinden. Die Verwendung von Boost.PtrContainer oder Boost.SmartPointer ist hier völlig fehl am Platz.

    Grüssli

    0
  • N

    Oh sorry, ich hab deinen Beitrag vorhin zu wenig genau gelesen...

    Dann sollte es eigentlich auch ein einfacher Zeiger tun, oder?

    0
  • Administrator

    Nexus schrieb:

    Dann sollte es eigentlich auch ein einfacher Zeiger tun, oder?

    Ja, nur hast du dann Probleme diesen Zeiger zu vergleichen. Es ist nicht garantiert, dass immer das gleiche Objekt für den gleichen Typen zurückgeliefert wird. Der Vergleich muss also über das Objekt gehen, auf welches der Zeiger zeigt. Dafür ist eben der Wrapper da.

    Grüssli

    0
  • N

    Ja, der Wrapper ist halt bequem anzuwenden, weil du dir das Zeiger-Dereferenzieren sparen kannst. 😉

    Aber die Lebensdauer von std::type_info -Objekten ist schon etwas merkwürdig. Ich hätte nicht gedacht, dass die so eine Ausnahme darstellen. Das lädt ja direkt zu Memory Leaks ein...

    0
  • B

    Nexus schrieb:

    Das lädt ja direkt zu Memory Leaks ein...

    Ist glaube ich sogar legal, nur macht das keiner. In der Regel gibt es genau ein type_info Objekt per Typ und in jede vtable wird ein Zeiger darauf reingepackt. Wenn Dlls ins Spiel kommen, dann kann es mehrere type_info Objekt per Typ geben. Halt einen in jedem Modul. Da der Standard keine Dlls kennt greift er halt auf eine so wage Formulierung zurück.

    0
  • ?

    Dravere schrieb:

    C++ Standard 98:
    Kapitel 5.2.8 Type Identification
    Abschnitt 1

    The result of a typeid expression is an lvalue of static type const std::type_info (18.5.1) and dynamic type const std::type_info or const name where name is an implementation-defined class derived from std::type_info which preserves the behavior described in 18.5.1. The lifetime of the object referred to by the lvalue extends to the end of the program. Whether or not the destructor is called for the type_info object at the end of the program is unspecified.

    Grüssli

    okay, vielen dank! 🙂 die lebensdauer der rückgabe von typeid hat mich doch etwas irritiert, aber damit wäre das problem jetzt für mich gelöst. die idee mit dem template von ben04 ist auch nicht schlecht, aber so ist das vorerst doch etwas unkomplizierter. 🤡

    0
Anmelden zum Antworten