Ich habe eine Template-Klasse, welche allerdings nur char und wchar_t zulassen darf. Wie kann ich fehlerhafte Eingaben des Nutzers abfangen?

Naja, und meine nächste Frage. Ich möchte einen konstanten Zeiger auf eine Zeichenkette zurückgeben...

const char_t* getDescription() //char_t ist ein typedef auf char bzw wchar_t
{
    return "Description"; //Wie kann ich im Falle von wchar_t das ganze als Widechar-Zeichenkette zurückgeben?
}

Danke schonmal
Grüße

Beim zweiten kannst du ein L vor die Zeichenkonste setzen.

const char_t* getDescription() //char_t ist ein typedef auf char bzw wchar_t
{
    return L"Description";
}

Was darin resultieren wird, dass der Compiler jammert wenn char_t ein char ist

Im Prinzip möchte ich so ein Verhalten (Pseudocode, ich möchte das vom Compiler aufgelöst haben) :

const char_t* getDescription() //char_t ist ein typedef auf char bzw wchar_t
{
    if(char_t == char)
        return "Description";
    else if(char_t == wchar_t)
        return L"Description";
}

.... enable_if werde ich mir mal ansehen, danke.

Grüße

template <typename CharType>
class DescriptionImpl;

template <>
class DescriptionImpl<char>
{
	public:
		const char* getDescription() const
		{
			return "Description";
		}
};

template <>
class DescriptionImpl<wchar_t>
{
	public:
		const wchar_t* getDescription() const
		{
			return L"Description";
		}
};

template <typename CharType>
class MyClass : public DescriptionImpl<CharType>
{
};

Ansonsten dürfte BOOST_STATIC_ASSERT vielleicht etwas schönere Fehlermeldungen geben.

Ist etwas mühsam, dass du hier Code duplizieren musst, aber ich sehe keinen Weg, zur Kompilierzeit Stringliterale an den Typen anzupassen.

const char_t* getDescription() //char_t ist ein typedef auf char bzw wchar_t
{
    if(char_t == char)
        return "Description";
    else if(char_t == wchar_t)
        return L"Description";
}

Was spricht gegen genau diesen Code? Statt "==" halt ein TypesEqual<char_t,char>::equal oder so und vor die Zeichenketten noch casts, dann steht das. Müsste "sicher" sein, verbraucht weniger Code und ist imo hübscher als solche ausgelagerten Dingsis.

PS: Mit

template<typename T, typename U>
struct TypesEqual
{
	enum {equal=false};
};

template<typename T>
struct TypesEqual<T,T>
{
	enum {equal=true};
};

Müsste "sicher" sein, verbraucht weniger Code und ist imo hübscher als solche ausgelagerten Dingsis.

Jetzt interessiert mich aber, wie deine getDescription aussieht. Du kannst nämlich nicht beide return -Statements im Code haben, auch wenn eines davon mit Sicherheit nie erreicht wird.

Abgesehen davon finde ich es unnötig, Performance für ein if zu verschwenden, wenn die Bedingung zur Kompilierzeit bekannt ist.

Okay, aber ob reinterpret_cast so viel schöner ist...

7 statt 20 Zeilen Code und einmal Vererbung weniger, ich finde das schon ein Argument...

Nexus schrieb:

Abgesehen davon finde ich es unnötig, Performance für ein if zu verschwenden, wenn die Bedingung zur Kompilierzeit bekannt ist.

Also mich würde es wirklich wundern, wenn das nicht rausoptimiert wird

Naja, ist wohl etwas Geschmackssache. Wenn ich den Code anschauen würde, wäre mir sicher nicht sofort klar, warum ein Cast verwendet wurde. Aber ein Kommentar könnte da sicher helfen.

Vielleicht schaue ich solche Templatemetaprogrammierungs-Techniken auch etwas zu konservativ an.

Auf Jedenfall ist Badestrand-Lösung sehr teuer.

Ja, leider schon. Ich würde schätzen, dass man schon so mit 2 bis 3 Sekunden Delay (Ausführungszeit) rechnen muss, auf aktuellen PCs. Gerade die if-Schleife und das teure reinterpret_cast, was ja bekanntlich zur Compilezeit wirkt, düften ziemlich viel fressen. Vielleicht kannst du mal ein wenig benchmarken, dann wissen wir mehr!

Du meinst zu Laufzeit.

Nein, er meint schon zur Compilezeit. Um Speicherbereiche anders zu interpretieren, braucht es keinen dynamischen Code.

Und er meinte sicher auch If-Abfrage. :p

Das hat VC++ daraus gemacht:

mov     eax, offset aDescription ; "Description"
retn

Danke dafür, die Lösung ist echt nicht schlecht.

Und er meinte sicher auch If-Abfrage. :p

Hihi, ich dachte, das fällt zwischen dem ganzen Unsinn gar nicht auf

Um das mal aufzuklären: Das if ( TypesEqual<char_t,char>::equal ) zerfällt beim "Auflösen" der Templates zu if ( true ) bzw if ( false ) ; was schlicht und ergreifend wegoptimiert wird. Der reinterpret-cast hat genau 0 Kosten, da er nur die Typinformation verändert (zur Compilerzeit), bleibt nur das return . Das brauchst du in jedem Fall, wodurch die Laufzeit irrelevant wird. Falls sie trotzdem jemand wissen will: Sie wird auf aktuellen Systemen ungefähr bei 0,0000000008 Sekunden liegen.