int testi = Settings::get<int>("settingA");

Der Compiler versucht natürlich str_data in ein int zu casten, was nicht gelingt. Jedoch wird er bei typename int diese Code Stelle nie erreichen. Dennoch muss sie type safe sein. Wie kann ich das mittels templates auf die Reihe kriegen um nicht für jeden Typ eine eigene get Methode bauen zu müssen?

Wenn ich typename QString verwende habe ich grundsätzlich das gleiche Problem, jedoch kann der Compiler hier ein int in einen QString casten.

setting->data ist ein int und setting->str_data ist ein QString

template<typename T> static T get(QString name) {
        Settings* setting = findSetting(name);
        if (typeid(T) == typeid(QString)) {
            return (T)setting->str_data;
        } else if (typeid(T) == typeid(int)) {
            return (T)setting->data;
        } else if (typeid(T) == typeid(bool)) {
            return (T)(setting->data == 0 ? false : true);
        }
        throw Exception("unsupported type of setting");
    }

ich hoffe folgendes hilft dir weiter:

#include <string>

template<typename T> class type_info{};

static int get(type_info<int> t, const std::string& s){
	return 0;
}

static std::string get(type_info<std::string> t, const std::string& s){
	return "string";
}

template<typename T>
static T get(type_info<T> t, const std::string& s){
	throw std::string("Oops");
}

template<typename T> static T get(const std::string& name) {
	return get(type_info<T>(), name);
}

int main(){
	int i = get<int>(std::string("Hallo"));
	std::string s = get<std::string>(std::string("Hallo"));
	double d = get<double>(std::string("Hallo"));
}

Ich denke, es ist genau das, was du suchst.

Gruß,
XSpille

template<typename T> class type_info{};

    static int get(type_info<int> t, const QString& name){
        Settings* setting = findSetting(name);
        return setting->data;
    }

    static void set(type_info<int> t, const QString& name, int value){
        Settings* setting = findSetting(name);
        setting->data = value;
    }

    static int get(type_info<bool> t, const QString& name){
        Settings* setting = findSetting(name);
        return setting->data == 0 ? false : true;
    }

    static void set(type_info<bool> t, const QString& name, bool value){
        Settings* setting = findSetting(name);
        setting->data = !value ? 0 : 1;
    }

    static QString get(type_info<QString> t, const QString& name){
        Settings* setting = findSetting(name);
        return setting->str_data;
    }

    static void set(type_info<QString> t, const QString& name, QString value){
        Settings* setting = findSetting(name);
        setting->str_data = value;
    }

    template<typename T>
    static T get(type_info<T> t, const QString& name){
        throw Exception("unsupported type of setting");
    }

    template<typename T>
    static void set(type_info<T> t, const QString& name, T value){
        throw Exception("unsupported type of setting");
    }

    template<typename T> static T get(const QString& name) {
        return get(type_info<T>(), name);
    }

    template<typename T> static void set(const QString& name, T value) {
        set(type_info<T>(), name, value);
    }

@XSpille: Was genau ist an deiner Lösung besser als an Spezialisierung? Machst du das, weil Spezialisierung angeblich "böse" ist?

Liegt wahrscheinlich daran, dass ich template-Funktionen eigentlich nie spezialisiere. Ich poste dann PiCiJi mal, was du meintest:

#include <string> 

template<typename T> class type_info{}; 

template<typename T> 
static T get(type_info<T> t, const std::string& s){ 
    throw std::string("Oops"); 
} 

template<>
int get<>(type_info<int> t, const std::string& s){ 
    return 0; 
} 

template<>
std::string get<>(type_info<std::string> t, const std::string& s){ 
    return "string"; 
} 

template<typename T> static T get(const std::string& name) { 
    return get(type_info<T>(), name); 
} 

int main(){ 
    int i = get<int>(std::string("Hallo")); 
    std::string s = get<std::string>(std::string("Hallo")); 
    double d = get<double>(std::string("Hallo")); 
}

camper schrieb:

Ist das nicht sowieso ein Fall für einen Variant-Container?

Sehe ich absolut nicht so...

cooky451 schrieb:

Nein, das ist ein klassischer Fall für verschiedene Funktionen. Das Template bringt hier nur Nachteile.

Wahrscheinlich hast du recht, aber in Template-Funktionen macht sowas schon manchmal Sinn...

Nein, das ist ein klassischer Fall für verschiedene Funktionen. Das Template bringt hier nur Nachteile.

Außer, er will es aus einem anderen Template heraus benutzen.

template< class T >
T get( const std::string & )
{
    static_assert( sizeof( T ) == 0 , "get< T > - unsupported Type" );
}
template<>
int get< int >( const std::string & )
{
    //...
}
template<>
bool get< bool >( const std::string & )
{
    //...
}

Warum Funktionstemplates nicht spezialisieren sollte hängt mit der overload resolution zu tun, und die spielt hier ja keine Rolle.

cooky451 schrieb:

Nein, das ist ein klassischer Fall für verschiedene Funktionen. Das Template bringt hier nur Nachteile.

Außer, er will es aus einem anderen Template heraus benutzen.

Ok, dann ist eine Spezialisierung wie bei GorbGorb aber immer noch sinnvoller.

(Außer dass ich nicht ganz verstehe, warum er nicht gleich static_assert(false, ..) schreibt. ;))

Solange nicht noch extra Umwandlungen im Spiel sind, wird hier nur eine Zuordnung Typ->Member benötigt.

(Außer dass ich nicht ganz verstehe, warum er nicht gleich static_assert(false, ..) schreibt. ;))

Weil der static_assert dann auch ausgelöst wird, wenn man gar nichts instanziert.

type_info ist hier ja mal sowas von falsch...

Qualitativ hochwertiger Kommentar

Es gibt Gründe, warum ich die Spezialisierung von Template-Funktionen meide...
Wenn Experten, die fast so viel Ahnung von C++ haben wie du , davon abraten, dann nehm ich mir das zu Herzen: http://www.gotw.ca/publications/mill17.htm

Also halt einfach die Fresse, solange keiner "Arsch öffne dich" sagt oder begründe deine Ansichten...

type_info ist hier ja mal sowas von falsch...

314159265358979 schrieb:

Weil du ein vollständig zur Kompilezeit bekanntes Problem zur Laufzeit erst löst. Sowas hätte selbst dir auffallen können, Schlaumeier.

Wobei das eine nichts mit dem anderen zu tun hat.

Weil du ein vollständig zur Kompilezeit bekanntes Problem zur Laufzeit erst löst. Sowas hätte selbst dir auffallen können, Schlaumeier.

314159265358979 schrieb:

Blahblah, du weißt ganz genau wie's gemeint ist. Stell dich nicht dumm.

Ich jedenfalls stelle mich nicht dumm, sondern weiß wirklich nicht, wie es gemeint ist.

Wieso wird die type_info zur Laufzeit ausgewertet? (Ernst gemeinte Frage...)

Das assert statt Exception sehe ich absolut ein. Ich hab die Exception nur aus seinem Code übernommen ohne mir darüber Gedanken zu machen.
Aber wenn man ein Vorgehen kritisiert und als Argument eine andere Sache nimmt, die nichts damit zu tun hat, dann stimmt irgendwas nicht.

Ich bin eigentlich fest davon überzeugt, dass die type_info zur Kompilierzeit ausgewertet wird, lasse mich aber gerne eines Besseren belehren.

Alles andere würde mich jedoch sehr wundern...

Ich bin eigentlich fest davon überzeugt, dass die type_info zur Kompilierzeit ausgewertet wird, lasse mich aber gerne eines Besseren belehren.

Der typeid -Operator ist Bestandteil von RTTI = Runtime Type Identification. Er wird schliesslich primär eingesetzt, um an den dynamischen Typen hinter Basisklassenverweisen zu kommen, welche per Definition erst zur Laufzeit feststehen.

XSpille schrieb:

Ich bin eigentlich fest davon überzeugt, dass die type_info zur Kompilierzeit ausgewertet wird, lasse mich aber gerne eines Besseren belehren.

Der typeid -Operator ist Bestandteil von RTTI = Runtime Type Identification. Er wird schliesslich primär eingesetzt, um an den dynamischen Typen hinter Basisklassenverweisen zu kommen, welche per Definition erst zur Laufzeit feststehen.

type_info != std::type_info
Der Name mag etwas ungünstig gewählt sein für ein tag, mit RTTI hat es jedenfalls nichts zu tun.

XSpille schrieb:

Ich bin eigentlich fest davon überzeugt, dass die type_info zur Kompilierzeit ausgewertet wird, lasse mich aber gerne eines Besseren belehren.

Der typeid -Operator ist Bestandteil von RTTI = Runtime Type Identification. Er wird schliesslich primär eingesetzt, um an den dynamischen Typen hinter Basisklassenverweisen zu kommen, welche per Definition erst zur Laufzeit feststehen.

Hi Nexus,
das weiß ich.

@PI: Geht deine Kritik an die typeid oder an das typeinfo-Template, das ich gepostet habe?

Ich dachte der Kommentar hatte sich auf das Template bezogen.

EDIT: OK, alle Unklarheiten beseitigt. Dann gebe ich dir absolut recht.

2

Also doch an das Template?

Ich hab die Exception nur aus seinem Code übernommen ohne mir darüber Gedanken zu machen.

nu ja möglicherweise ist die exception da nicht geeignet. Grundsätzlich soll diese mich schnell über einen Programmierfehler informieren. ich habe die komplette app in ein try gelegt.

also so:

#include "main.h"
#include <QString>
#include <QApplication>
#include "app.h"
#include "exception.h"

int main(int argc, char** argv) {
    QApplication app(argc, argv);
    app.setWindowIcon(QIcon(":/tmb.ico"));

    QString app_style =
    "QMenuBar::item {background-color: rgb(255,255,255);}"
    "QMenuBar::item:selected {border: 1px solid rgb(121,152,241);}"
    "QMenu::item {padding: 2px 25px 2px 20px;background: #FFFFFF;border: 1px solid transparent;}"
    "QMenu::item:selected  {border: 1px solid rgb(121,152,241);background-color: rgb(226,233,254);color: #000000;}"
    "QMenu::separator { width: 1px; height: 1px;}";

    app.setStyleSheet(app_style);

    QString app_dir = QApplication::applicationFilePath();
    app_dir = app_dir.left(app_dir.lastIndexOf( '/' ) + 1);

    try {
        return App(app, app_dir).Run();
    } catch (const Exception& exception) {
        return exception.handle();
    }
}