Im Groben geht es darum, für einen zur Compilierzeit bekannten Typ herauszufinden, ob er von einem anderen Typ abgeleitet ist. Ist das der Fall, soll eine Methode dieses anderen Typs aufgerufen werden. Der andere Typ liegt aber zu dem Zeitpunkt schon in einer virtuellen Klasse als type_info Objekt vor, da ich diese Information als Tabelle anlegen will. Diese Tabelle ist eigentlich eine Map, die einen Namen (als String) dieser Information gegenüberstellt, das wurde aber fürs Beispiel weggelassen.

Der relevante Code:

#include <typeinfo>

namespace detail {

    struct InfoImpl
    {
        virtual ~InfoImpl() {}
        virtual std::type_info const& Type() const = 0;
    };

    template< typename Class >
    struct InfoImplClass : public InfoImpl
    {
        InfoImplClass( void (Class::*func)() ) {}

        void Apply( Class* object )
        {
            // hier wird die im Ctor übergebene Methode aufgerufen
            std::cout << "Apply()" << std::endl;
        }

        virtual std::type_info const& Type() const { return typeid( Class ); }
    };

} // namespace detail

class Info
{
public:
    template< typename Class >
    Info( std::string const& name, void (Class::*func)() ) 
        : m_name( name )
        , m_impl( new detail::InfoImplClass< Class >( func ) ) {}

    std::string const& Name() const { return m_name; }

    template< typename Class >
    void Apply( Class* object )
    {
        if ( m_impl->Type() == typeid( Class ) ) {
            static_cast< detail::InfoImplClass< Class >* >( m_impl )->Apply( object );
        }
    }

private:
    std::string m_name;
    detail::InfoImpl* m_impl;
};

Beispielprogramm:

#include <iostream>
#include <functional>

struct Control
{
    void SetWidth() { std::cout << "SetWidth" << std::endl; }
};

struct Label : public ControlWithLabel
{
    void SetText() { std::cout << "SetText" << std::endl; }
};

struct CheckBox : public ControlWithLabel
{
    void SetChecked() { std::cout << "SetChecked" << std::endl; }
};

int main()
{
    Info infos[] = {
        Info( "width", &Control::SetWidth ),
        Info( "value", &Label::SetText ),
        Info( "value", &CheckBox::SetChecked )
    };

    // Eingaben aus z.B. einer Datei 
    std::string name1 = "value", value1 = "true";
    std::string name2 = "width", value2 = "120";

    CheckBox cb;
    for ( Info* i = infos ; i != infos + 3 ; ++i ) {
        if ( i->Name() == name1 ) {
            i->Apply( &cb );
        }
        else if ( i->Name() == name2 ) {
            i->Apply( &cb );
        }
    }
}

Das Beispielprogramm soll "SetChecked" und "SetWidth" ausgeben. Für ein Label sollte das gleiche Beispielprogramm "SetLabel" und "SetWidth" ausgeben. Die gezeigte Implementierung zeigt natürlich nur einmal "SetChecked" an, wegen des Typvergleichs.

Hintergrund ist, dass ich viele Controls in einer Vererbungsstruktur habe, deren Eigenschaften aus einer Datei eingelesen werden sollen. Dabei können Eigenschaften auf alle Controls (z.B. "width") auftreten, andere Eigenschaften haben bei unterschiedlichen Controls unterschiedliche Bedeutungen (wie "value"). Erschwerend kommt hinzu, dass in dieser Tabelle auch Typen stehen können, die nicht miteinander verwandt sind, sonst könnte ich den Templates die gemeinsame Basisklasse als Parametertyp von Apply() mitgeben und einen dynamic_cast probieren.

Gibt es eine Möglichkeit, in Info::Apply festzustellen, ob m_impl->Type() eine Basis von Class ist? Sieht jemand eine Alternative, die ich übersehe? Die notwendigen Informationen müssten m.E. alle zur Compilezeit vorliegen...

Im Prinzip reicht dir aber normale Funktionsüberladung, denke ich.

Oder willst du das ganze wirklich erst zur Laufzeit zusammen bauen? Dann wird es sehr sehr häßlich...

Inwiefern kann mir Funktionsüberladung helfen? (Vielleicht denke ich zu kompliziert :)).

Ich habe das Beispielprogramm mal etwas geändert und einen Abschnitt ergänzt, vielleicht wird dann klarer, was ich möchte. Ich vermute so langsam, ich denke wirklich zu kompliziert.

Die notwendigen Informationen müssten m.E. alle zur Compilezeit vorliegen...

Sehe ich auch so. Ich habe auch lange über dieses Problem (DoubleDispatch mit Erkennung von Vererbung) gegrübelt, eine Lösung dazu ist mir allerdings nicht eingefallen.

Die einzige Idee, die mir überhaupt einfallen würde, wäre die beteiligten Klassen zu modifizieren (was im Falle einer vorgegebenen GUI-Bibliothek i.a. nicht möglich ist).

Eine Möglichkeit wäre dann noch, eine parallele Klassenhierarchie aufzuziehen, aber auch das ist normalerweise Overkill und wider dem Konzept, da man das ja genau dafür baut um nicht alle beteiligten Klassen zu benennen oder überhaupt kennen zu müssen.

Falls es dir selber nicht klar sein sollte - was du hier willst und brauchst (für die völlig allgemeine Eierlegendewollmilschau-Lösung) ist ein Double-Dispatch mit Erkennung von Vererbungsbeziehungen und ohne gemeinsame Basisklasse, also der schwierigste überhaupt mögliche Fall.

Im Prinzip soll ja folgendes passieren:
dispatch( Control, Value)
->
functor mit Kenntnis der konkreten Methode( Control, Value) (Control->*Methode)( Value)

Ich stand vor einem ähnlichen Problem. Bei mir haben nun Control und Value jeweils eine gemeinsame Basisklasse.

Das Vererbungsproblem konnte ich nicht lösen - stattdessen habe ich einen "Forward-Funktor" eingerichtet, bei dem ich alle beteiligten Klassen zusammen mit der minimal benötigten Basisklasse (also die, die die Methode unterstützt) registriere.
Dadurch muss ich zwar alle konkreten Controls benennen (die Anzahl ist überschaubar), habe aber nur eine konkrete Basisklasse zur Implementierung.

Einen Double-Dispatcher mit Funktoren und dem automatischen dynamic_casten auf den konkreten Typ kannst du dir in Loki bzw. Modern C++ Design abgucken.

Zu dem Problem mit den nicht-verwandten Klassen, insbesondere der Values, wenn es z.B. triviale Klassen bzw. integrale Typen sind, habe ich mal über folgendes zumindest nachgedacht (keine Ahnung, ob es funktioniert, bzw. es war nicht zuende gedacht):
Jeder Value wird per Template-Kapselung von einer gemeinsamen Value-Basisklasse abgeleitet. Diese ist in der Lage, Values korrekt ein- und wieder auszupacken. Sowohl beim registrieren als auch beim Dispatch müssen dann aber die konkreten Typen bekannt sein. Das kann auf jeden Fall beim Dispatch wieder nachteilig sein.

Ansonsten musst du wohl darüber nachdenken, bei deinem Design Abstriche zu machen. Alternativ könnte es noch von deiner konkreten GUI-Bibliothek abhängen. Vielleicht bietet diese wiederum spezielle Möglichkeiten für deine Zwecke, auch wenn die Lösung dann nicht mehr 100% allgemein wäre.

Du solltest einfach die Infos genauso hierarchisch anordnen wie die echten Klassen, d.h. hierarchisch. Nun kannst du einfach die Info-Subarrays rekursiv durchlaufen.

typedef std::pair< std::vector<Info>, Infos* base_class_infos > Infos;

// und diese Infos steckst du dann in eine Map (zwecks Klassennamensvergleich)

So kannst du sogar ein Überschreiben von Eigenschaften ermöglichen.

Ein komplexes System dieser Art habe ich selbst schon als ein Propertysystem implementiert (mit Templates und Makros), welches die Daten aus einer XML-Datei parst.

@Th69:
Das werde ich mir noch anschauen. Übrigens geht es genau um sowas, nämlich in einer (XML-)Datei abgelegte Attribute anhand ihres Namens den richtigen Settern der Klassen zuzuweisen.

Edit: Die Ordnung ist implementierungsabhängig, keine Garantien oder weitere Aussagen.