Ich hab mir im Zusammenhang mit dem Thread "sind templates von template-spezialisierungen möglich?" überlegt, wie man ein Interface für eine Klasse bauen kann, die selbst Objekte verschiedenen Typs verwaltet und wie man dann darauf zugreifen könnte.
Das ganze im Zusammenhang z.B. mit einer Klasse zur Verwaltung von User Settings, also einer Klasse a la boost program_options. Da gibt es eine Methode as<T>() mit der eine Variable aus dem Container geladen werden kann und die eine Exception wirft, falls man den Zugriff über einen falschen Typen versucht.
Wie geht sowas, aufbauend auf den Sprachelementen von C++?

Der Test der Typen könnte ja im Direktzugriff auf die Templateklasse, die die Variablen enthält noch einfach vonstatten gehn, wie z.B. wxSkip im anderen Thread gezeigt hat.
Nur wie pappe ich jetzt diese Templateklasse, die Variablen unterschiedlichen Typs halten kann in einen Container rein? Ich kann für meinen Container schliesslich nicht definieren, dass er Objekte des Typs Templateklasse<T> enthalten soll, da dieses T ja eben unterschiedlich ist. Und wenn ich eine Parentklasse TemplateParent der Templateklasse erstelle, die selber kein Template ist, dann kann ich diese zwar im Container ablegen, aber wie soll dann der Zugriff über as<T>() erfolgen? Schliesslich sind virtuelle template Funktionen nicht möglich?

Ich blick da überhaupt nicht durch wie sowas möglich sein soll.

Gruss

void*

Und wie überprüfst du dann, um welchen Typen dass es sich handelt? Da hast du doch sämtliche Informationen verloren...

Hallo zusammen

Ich hab mir im Zusammenhang mit dem Thread "sind templates von template-spezialisierungen möglich?" überlegt, wie man ein Interface für eine Klasse bauen kann, die selbst Objekte verschiedenen Typs verwaltet und wie man dann darauf zugreifen könnte.

Sinnvoll geht das nur mit einer Root Class von der alle zuspeichernden Klassen abgeleitet sind. void* hat so seine Nachteile. C++ ist allerdings für ein solches Vorgehen mangels Unterstützung im Laufzeitsystem (es gibt nicht die eine Root Class) nicht so gut geeignet. Trotzdem kann man das durch Disziplin erreichen.

Ich habe keine Information bei void* verloren, das Objekt ist genauso vorhanden wie vorher. Ich kann mit dynamic_cast auf den gesuchten Typen casten und das Ergebnis pruefen.

Wirklich? Soviel mir bekannt ist, arbeitet dynamic_cast auf RTTI, void* fehlen aber jegliche Typinformation. Ich würde hier eher ein reinterpret_cast erwarten.

knivil schrieb:

Ich habe keine Information bei void* verloren, das Objekt ist genauso vorhanden wie vorher. Ich kann mit dynamic_cast auf den gesuchten Typen casten und das Ergebnis pruefen.

Wirklich? Soviel mir bekannt ist, arbeitet dynamic_cast auf RTTI, void* fehlen aber jegliche Typinformation. Ich würde hier eher ein reinterpret_cast erwarten.

Lustig. Ich einen static_cast

Die korrekte Antwort hat pumuckl ja schon gesagt: boost::any (bzw etwas äquivalentes)

Ich habe keine Information bei void* verloren, das Objekt ist genauso vorhanden wie vorher. Ich kann mit dynamic_cast auf den gesuchten Typen casten und das Ergebnis pruefen. Nichts anderes wird boost::any machen, es kapselt void* einfach nur.

Dass dynamic_cast so nicht funktioniert wurde ja schon geschrieben (void erfüllt die Voraussetzungen für einen dynamic_cast Source Typ nicht).

Eine Möglichkeit sowas wie boost::any zu implementieren ist Funktionszeiger zu verwenden um die Typinformation zu erhalten. D.h. du machst ein Funktionstemplate, das den "any_cast" für "seinen" Typ implementiert, und "seinen" Typ als void* entgegennimmt.

Bei der Zuweisung (wo der Typ ja noch bekannt ist), holst du dir den Zeiger auf die passende Spezialisierung.

template <class T>
void DoSomething(void* obj)
{
    static_cast<T*>(obj)->DoSomething();
}

template <class T>
void DeleteIt(void* obj)
{
    delete static_cast<T*>(obj);
}

template <class T>
void* CloneIt(void const* obj)
{
    return new T(*static_cast<T const*>(obj));
}

class Foo
{
public:
    template <class T>
    explicit Foo(T t)
        : m_obj(0),
        m_doSomething(&DoSomething<T>),
        m_deleter(&DeleteIt<T>),
        m_cloner(&CloneIt<T>)
    {
        m_obj = new T(t);
    }

    ~Foo()
    {
        m_deleter(m_obj);
    }

    void DoSomething()
    {
        m_doSomething(m_obj);
    }

    Foo(Foo const&);
    Foo& operator = (Foo const&);

    // ...

private:
    void* m_obj;
    void (*m_doSomething)(void*);
    void (*m_deleter)(void*);
    void* (*m_cloner)(void const*);
};

Die ganzen Zeiger kann man natürlich in einer statischen Instanz einer Templateklasse sammeln.

Oder man verwendet gleich virtuelle Funktionen. Also (non-template) Basisklasse mit den virtuellen Funktionen, Klassen-Template welches diese implementiert und eine statische Instanz von sich selbst enthält. Auf diese statische Instanz holt man sich den Zeiger (als Basisklassen-Zeiger), und über den ruft man die virtuellen Funktionen auf.

Im Prinzip alles das selbe, Variationen in Form und Farbe sozusagen.

EDIT: Fehler im Code beseitigt /EDIT

#include <iostream>
#include <stdexcept>
#include <typeinfo>

class rtti_holder {
public:
  template<typename T>
  rtti_holder(T &ref) : ptr_(&ref), tinfo_(typeid(ref)) { }

  template<typename T>
  T &as() {
    if(tinfo_ == typeid(T)) {
      return *static_cast<T*>(ptr_);
    }

    throw std::logic_error("Falscher Typ");
  }

private:
  void *ptr_;
  std::type_info const &tinfo_;
};

int main() {
  int i = 2;

  rtti_holder r(i);

  std::cout << r.as<int >() << std::endl; // Funktioniert
  std::cout << r.as<char>() << std::endl; // Wirft Exception
}

Wobei natürlich Besitzansprüche gesondert zu regeln sind und im Zweifel auf etwas hinauslaufen, wie es hustbaer vorschlägt.

class any
{
    struct any_impl_base
    {
        virtual ~any_impl_base() {}
    };

    template <typename T>
    struct any_impl : any_impl_base
    {
        T object;
        any_impl(T obj) : object(obj) {}
    };

    any_impl_base* impl;

public:

    template <typename T>
    any(T obj) : impl(new any_impl<T>(obj)) {}

    ~any() { delete impl; }

    template <typename T>
    T& get() { return dynamic_cast<any_impl<T>&>(*impl).object; }

    template <typename T>
    any& operator = (T obj)
    {
        any_impl<T>* ptr = new any_impl<T>(obj);
        delete impl;
        impl = ptr;
        return *this;
    }
};

template <typename T>
T& any_cast(any& a)
{
    return a.get<T>();
}

Fehlen natürlich noch einige Sachen, aber vom Prinzip her würde ich das so lösen.

Type Erasure ist da meiner Meinung nach schöner.

Schöner als was?
Sowohl dein Beispiel als auch meins als auch das von seldon machen Type Erasure.

void* hat nicht viel mit Type Erasure zu tun, imo.

In Java ist das der Standard Weg. Da macht man überall void* wie in seldon Besipiel und nennt sie halt Object-Referenz.

Wieso sollte es also in C++ keine type erasure mehr sein.

(unabhängig jetzt davon welche implementierung hier die schönste ist)

Ungeachtet dessen sehe ich eine gewisse Ironie darin, im Zusammenhang mit dieser Anforderung über die Schönheit der Implementation zu sprechen. Allein die Tatsache, dass man etwas derartiges benötigt, deutet auf wichtigere Designprobleme hin.

Wie ist das mit Runtime Type Information in Bezug auf typeid respektive dynamic_cast? Ich habe mich da bis jetzt nicht weiter damit beschäftigt, soweit ich weiss wird aber der Compiler bei beiden Varianten RTTI brauchen, also überall im Code, auch wo gar nicht benötigt zusätzlichen Code einfügen, was dann tendenziell die Performance ziemlich beeinträchtigen kann, typeid noch weniger als dynamic_cast?

Wärs da nicht effizienter, da ich die Typeninformationen nur hier lokal benötige im Container für den generischen Typ in den vom Compiler erstellten Templateklassen, diese selber zu implementieren? Also etwas in der Art wie:

class TypeInfo
{
 public:
   TypeInfo():Number(++OverallNumber){};

   const int id() const{ return Number; };
 private:
   const int Number;
   static int OverallNumber;
};

int TypeInfo::OverallNumber=0;

class GenericType
{
  class Object
  {
    public:
      virtual const int getTypeId() const =0;
  };

  template<class T>
  class ObjectInstance:public Object
  {
    public:
      ObjectInstance( T _value ):Value(_value),TypeId(*ClassTypeId){};

      T Value;

      const int getTypeId() const { return TypeId.id();};
      static const int typeId(){ return ClassTypeId->id();};
    private:
      const TypeInfo TypeId;
      static const TypeInfo* const ClassTypeId;
  };

  public:
    template<class T>
    GenericType( T _value ){
      Content=new ObjectInstance<T>( _value );
    };
    ~GenericType() 
    { 
      delete Content; 
    };
    GenericType( const GenericType& _toCopy ){ /*...*/};

    template<class T>
    T& as()
    {
      if( GenericType::ObjectInstance<T>::typeId()==Content->getTypeId() )
      {
        return static_cast< ObjectInstance<T>* >(Content)->Value;
      }
      // else throw an exception
    };

  private:
    Object* Content;
};

template<class T>
const TypeInfo* const GenericType::ObjectInstance<T>::ClassTypeId=new TypeInfo();

?

seldon schrieb:

Ungeachtet dessen sehe ich eine gewisse Ironie darin, im Zusammenhang mit dieser Anforderung über die Schönheit der Implementation zu sprechen. Allein die Tatsache, dass man etwas derartiges benötigt, deutet auf wichtigere Designprobleme hin.

Inwiefern? Scheint mir die optimale Methode um veränderbare Settings, die ganz natürlicherweise unterschiedliche Typen haben können in einer gemeinsamen Klasse mit identischem Zugriff speichern zu können?
Btw. Gäbs boost::any wohl kaum, wenn sowas nur benötigt wird, wenn beim Design was schief gelaufen ist..

void* hat nicht viel mit Type Erasure zu tun, imo.

Wieso nicht?
void* ist IMO die ultimative Type-Erasure, viel weniger "Typ" als void* kann man wohl nicht haben

@ccquestions:
Die Performance spielt bei dem was du da machen willst IMO keine grosse Rolle.

Das ist auch die Frage bezüglich des RTTI: Ich weis nicht wie das genau umgesetzt wird vom Compiler etc. Hab ich da nicht, sobald irgendwo mal der typeid header auftaucht im ganzen Programm das Runtime Type Tracing drin, was ja dann völlig idiotisch wäre, da ichs ja wirklich nur an der Stelle da benötige, notabene mit Typen, die bei der Kompilierung ja eigentlich dem Compiler sogar bekannt sind?

hustbaer schrieb:

Ich würde dafür auf jeden Fall keinen Type-Info Code selbst schreiben.

Wenn der typeid der std library das schön umsetzt ja klar, auf der anderen Seite reicht mir hier ja eine simple Integer Id ohne das ganze Getöse rundherum völlig aus, also so wie im Code oben funktioniert das perfekt...

Hab ich da nicht, sobald irgendwo mal der typeid header auftaucht im ganzen Programm das Runtime Type Tracing drin, was ja dann völlig idiotisch wäre, da ichs ja wirklich nur an der Stelle da benötige, notabene mit Typen, die bei der Kompilierung ja eigentlich dem Compiler sogar bekannt sind?

Runtime type information. Das ist ohnehin standardmässig aktiviert (wegen Exceptions) und normalerweise kein Problem.

ccquestions schrieb:

auf der anderen Seite reicht mir hier ja eine simple Integer Id ohne das ganze Getöse rundherum völlig aus, also so wie im Code oben funktioniert das perfekt...

Warum selbst basteln, warten und konsistent halten? Hast du Angst vor dem Overhead?

Runtime type information.

Weiss ich danke. Mir gehts nur aufn Sack immer die gleichen Wörter zu verwenden Grundsatz Nr. 1 beim Schreiben

Nexus schrieb:

Das ist ohnehin standardmässig aktiviert (wegen Exceptions) und normalerweise kein Problem.

Genau hierauf bezog sich die Frage. Das bedeutet also, dass dynamic_cast nur zu Overhead führen kann, weil dann bei Einsatz die ganzen Vererbungen etc durchgegangen werden müssen? Die Informationen sind sowieso alle schon da?

Nexus schrieb:

Warum selbst basteln, warten und konsistent halten? Hast du Angst vor dem Overhead?

Wenn die Informationen sowieso da sind, ist dies natürlich unnötig.

hustbaer schrieb:

@ccquestions:
Die Performance spielt bei dem was du da machen willst IMO keine grosse Rolle.

Das ist auch die Frage bezüglich des RTTI: Ich weis nicht wie das genau umgesetzt wird vom Compiler etc. Hab ich da nicht, sobald irgendwo mal der typeid header auftaucht im ganzen Programm das Runtime Type Tracing drin, was ja dann völlig idiotisch wäre, da ichs ja wirklich nur an der Stelle da benötige, notabene mit Typen, die bei der Kompilierung ja eigentlich dem Compiler sogar bekannt sind?

RTTI hat nur dort Performance-Overhead, wo du es auch verwendest. "Getraced" wird da nix. Normalerweise geht das über den VTable-Zeiger, und den muss es sowieso geben, sobald man virtuelle Funktionen verwendet. Da virtuelle Funktionen Voraussetzung für RTTI sind -> kein Overhead. Ausser eben dort wo man Dinge wie typeid() oder dynamic_cast auch wirklich verwendet.

Beide, also typeid und dynamic_cast, können zwar ein gutes Stück langsamer sein als selbstgebastelte Lösungen, nur da das an der Stelle mMn. wirklich vernachlässigt werden kann -> egal.

EDIT: typeid() selbst ist normalerweise sehr sehr schnell. Was ein Bisschen langsam sein kann ist dann der Vergleich zweier type_info Instanzen. Sollte aber auch nur einen spürbaren Impact haben wenn die Typen nicht gleich sind, oder die type_info Instanzen aus unterschiedlichen Programmteilen kommen (z.B. verschiedenen DLLs). /EDIT

Inwiefern? Scheint mir die optimale Methode um veränderbare Settings, die ganz natürlicherweise unterschiedliche Typen haben können in einer gemeinsamen Klasse mit identischem Zugriff speichern zu können?
Btw. Gäbs boost::any wohl kaum, wenn sowas nur benötigt wird, wenn beim Design was schief gelaufen ist..

Das Problem ist, dass du auf verschiedene Typen keinen identischen Zugriff bekommst, sofern diese nicht von der selben Basisklasse erben, die das Interface bereitstellt - und in diesem Fall ist die ganze Apparatur eh unnötig.

Überleg dir, wie der benutzende Code am Ende aussehen soll bzw. muss - ich habe Schwierigkeiten, mir ein anderes Vorgehen vorzustellen als "Versuch's mit dem Typ. Funzt nicht? Probier's mit dem nächsten.", und das ist alles andere als sauber.

Wie man Konfigurationsdaten (wenn ich jetzt richtig verstehe, was du damit vorhast) am sinnvollsten verwaltet, hängt natürlich von der Applikation ab. Meiner Erfahrung nach - aber die ist nicht allumfassend - macht es wenig Sinn, die Konfigurationsdatei in verwursteter Form aber praktisch unverändert vorzuhalten; habe ich beispielsweise eine Einstellung "calculation_backend = foo", halte ich mir nicht "foo" in einem String vor, um später die damit verbundene Funktion rauszukramen, sondern setze gleich beim Einlesen der Konfiguration einen entsprechenden Funktionszeiger (oder wie auch immer ich das gerade verwalte). Jedenfalls unternehme ich alles sinnvoll mögliche, damit sich kein Stück Client-Code damit rumschlagen muss, den Typ einer Variable zu erraten. Selbst, wenn die Einstellungen zur Laufzeit änderbar sein sollen, macht ein Event-basierter Ansatz da für mein Verständnis mehr Sinn - bring es gleich in eine vernünftig maschinenlesbare Form, und reich die Verarbeitung von Einstellungen nicht nach außen an Code weiter, der sich mit anderen Problemen rumschlagen will.

Ausnahmen gibt es im Wesentlichen da, wo man sich mit...naja, es läuft in gewisser Weise auf Laufzeitprogrammiersprachen raus. Nicht notwendigerweise so hochgestochen wie Script-Engines; ich denke da beispielsweise an Tabellenkalkulationen. Ich fluche zwar jedes mal über XLOPER, wenn ich an einem Excel-Plugin schreibe, aber ich sehe da tatsächlich keine sinnvolle Möglichkeit, das anders zu machen.

ccquestions schrieb:

Hab ich da nicht, sobald irgendwo mal der typeid header auftaucht im ganzen Programm das Runtime Type Tracing drin, was ja dann völlig idiotisch wäre, da ichs ja wirklich nur an der Stelle da benötige, notabene mit Typen, die bei der Kompilierung ja eigentlich dem Compiler sogar bekannt sind?

Runtime type information. Das ist ohnehin standardmässig aktiviert (wegen Exceptions) und normalerweise kein Problem.

Ist das wirklich so? Zumindest beim MSVC kann man Exceptions und RTTI getrennt von einander ein- und ausschalten. Mir ist auch nicht klar, was das Eine genau mit dem Anderen zu tun haben soll.

...Exceptions und RTTI ... Mir ist auch nicht klar, was das Eine genau mit dem Anderen zu tun haben soll.

Naja wie soll denn die Runtime checken ob ein Catch-Handler passt, wenn sie über die Typen nichts mehr weiss?