3. Problem mit template-Klasse

Problem mit template-Klasse

  • ?
     

    template<typename char_t>
struct X
{
	const char_t* getDescription()
	{
		if ( TypesEqual<char_t,char>::equal )
			return reinterpret_cast<char_t*>( "Description" );
		else if ( TypesEqual<char_t,wchar_t>::equal )
			return reinterpret_cast<char_t*>( L"Description" );
	}
};
    0
  • N

    Okay, aber ob reinterpret_cast so viel schöner ist... Edit: Ah, die Casts habe ich in deinem ersten Post überlesen und erst jetzt gesehen. Sorry für die sinnlose Frage, wie du das implementieren würdest.

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

    0
  • ?

    Nexus schrieb:

    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 😕

    0
  • N

    Hm, stimmt eigentlich schon. 🙂

    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. 😉

    0
  • Z

    Auf Jedenfall ist Badestrand-Lösung sehr teuer. Obwohl er Template benutzt :s Eigentlich frag ich mich, wieso in C++ String kein typedef auf basic_string<char> oder basic_string<wchar_t> jenachdem ob UNICODE definiert ist. Sowie mit entsprechend T Macro, der den Stringliteral entsprechend ersetzt.

    0
  • ?

    Zeus schrieb:

    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!

    0
  • Z

    Du meinst zu Laufzeit.

    0
  • N

    Zeus schrieb:

    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

    0
  • I

    Unglaublich teuer *g*

    Das hat VC++ daraus gemacht:

    mov     eax, offset aDescription ; "Description"
retn

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

    0
  • ?

    Nexus schrieb:

    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.

    0
Anmelden zum Antworten