Falls nicht, würde ich drüber nachdenken einige Sachen mit Templates nach zu rüsten.

Grüssli

template<class T>
void ausgabe(T var)
{
	std::cout << var;
}

int main()
{
	ausgabe(0);
	ausgabe("Hallo");
}

macht der Compiler vom Prinzip her folgendes:

void ausgabe_int(int var)
{
	std::cout << var;
}

void ausgabe_constcharptr(const char *var)
{
	std::cout << var;
}

int main()
{
	ausgabe_int(0);
	ausgabe_constcharptr("Hallo");
}

Template heißt übersetzt Schablone und genau das ist es auch. Eine Schablone für Funktionen oder Klassen, aus der der Compiler selbstständig konkrete Funktionen und Klassen generieren kann. Zur Laufzeit gibt es deshalb die Templates gar nicht mehr, sondern nur noch die generierten Funktionen und Klassen (wobei die ja zur Laufzeit auch nicht mehr existieren).

Es werden im Endeffekt ganz normale Klassen oder Funktionen erstellt, die ganz genau so funktionieren, als ob man sie mit Hand geschrieben hätte.

Was allerdings zu schlechterer Performance führen kann, ist, wenn man zu viel Code über Templates erzeugt. Dadurch wird das Programm grösser, und die Chancen dass die viel genutzten Bereiche nicht mehr in den CPU Cache passen steigen. Hat allerdings nur indirekt mit Templates zu tun. Den Effekt hätte man genau so, wenn man die gleiche Menge Code mit Hand schreiben müsste.

Stichwort: Template Bloat

Und natürlich muss man, wenn man alles schön generisch halten möchte, manchmal einige Dinge komplizierter schreiben, als wenn man nur mit einem exakt definierten Typ zu tun hat. Viel davon kann der Compiler so optimieren, dass der komplizierter aussehende generische Code im Endeffekt gleich schnell läuft wie die einfachere nicht-generische Variante. Einiges aber auch nicht.

dazu steht was bei wikipedia unter dem punkt metaprogrammierung oder ähnlichem

man kann allerdings auch viel optimieren weil man gewisse sachen dazu bringen kann schon zur compilezeit ausgerechent zu werden

dazu steht was bei wikipedia unter dem punkt metaprogrammierung oder ähnlichem

Ich würde da so gerne mal ein praxistaugliches Beispiel zu sehen. Alles was ich dazu kenne sind akademische Szenarien oder gelangweilte Programmierer die das zum Spaß machen.

ich schreib morgen mal das beispiel rein
hab nur jetzt keine zeit mehr...

mh es gab da mal was zum error zur compile zeit ausgeben oder so

ich schreib morgen mal das beispiel rein
hab nur jetzt keine zeit mehr...

Ja, oswas kenne ich. Ich meine aber wo man tatsächlich Sachen zur Compilezeit vorausberechnet und das tatsächlich praktisch relevant ist. Zum Beispiel schreibt niemand eine TMP-Fakultät um dann fakultaet<6> anstatt 720 schreiben zu können. Und selbst wenn man eine Fakultätsfunktion schreibt und fakultaet(6) schreibt, würde das jeder Compiler auch ohne TMP zu 720 optimieren.

Ich frage mich halt, ob es Beispiele gibt, wo ein Programm tatsächlich schneller würde durch TMP.

Den anderen Fall, wo Compilezeit-Berechnungen direkt benötigt werden, habe ich bisher kaum angetroffen. Man ist auch etwas eingeschränkt, weil z.B. keine Fliesskommazahlen verwendet werden können.

Viel häufiger sieht man die Template-Metaprogrammierung aber im Zusammenhang mit statischem Dispatchen von Typen (Traits, Static Assertions, Policies, ...).

und 4 für 5 Euro...

#include <iostream>

template<int p, int i>
struct istPrimzahl {
    enum {prim=(p%i) && istPrimzahl<(i>2?p:0), i-1>::prim};
};

template<int i>
struct druckePrimzahlenBis {
    druckePrimzahlenBis<i-1> a;
    enum { prime = istPrimzahl<i, i-1>::prim };

    druckePrimzahlenBis() {
        if ( prime )
            std::cout << i << std::endl;
    }
};

struct istPrimzahl<0, 0> { enum {prim=1};};
struct istPrimzahl<0, 1> { enum {prim=1};};
struct druckePrimzahlenBis<2> { enum{prim=1}; };

int main() {
    druckePrimzahlenBis< __17__ > a;
    return 0;
}

Dieses Programm wurde 1994 nach einer Idee von Erwin Unruh geschrieben, der ein programmm konstruierte, das beid er Übersetzung Primzahlen in den Fehlermeldungen des Compilers erzeugte.

#include <iostream> 

template<int p, int i> 
struct istPrimzahl { 
    enum {prim=(p%i) && istPrimzahl<(i>2?p:0), i-1>::prim}; 
}; 

template<int i> 
struct druckePrimzahlenBis { 
    druckePrimzahlenBis<i-1> a; 
    enum { prime = istPrimzahl<i, i-1>::prim }; 

    druckePrimzahlenBis() { 
        if ( prime ) 
            std::cout << i << std::endl; 
    } 
}; 

template<> 
struct istPrimzahl<0, 0> { enum {prim=1};};

template<> 
struct istPrimzahl<0, 1> { enum {prim=1};}; 

template<> 
struct druckePrimzahlenBis<2> { enum{prim=1}; }; 

int main() { 
    druckePrimzahlenBis< 501 > a; 
    return 0; 
}

Error 1 error C1202: recursive type or function dependency context too complex e:\workspace\cxx01\cxx01\main.cpp 5 1 cxx01

aber ich hab ihn wortwörtlich abgeschrieben aus dem buch vorhin, genauso wie die 3 zeilen danach

aber das prinzip sollte klar sein dabei denke ich
und die cracks hier können den auch so ohne probleme von syntaktischen rerrors befreien

Danke. Sowas meinte ich. Eine nichttriviale Aufgabe die während der Compilezeit gelöst werden kann.

TMP ist turingvollständig, also kann man alle Algorithmen damit zur Compilezeit lösen. Aber sämtliche Beispiele dafür sind prinzipbedingt akademischer Humbug, denn ein zur Compilezeit feststehendes Ergebnis kann ich genauso gut hardcodieren.

Aber sämtliche Beispiele dafür sind prinzipbedingt akademischer Humbug, denn ein zur Compilezeit feststehendes Ergebnis kann ich genauso gut hardcodieren.

Es sei denn das Ergebnis ist nicht eine Zahl sondern ein Typ.
Dann wirds naemlich interessant.

ipsec schrieb:

Aber sämtliche Beispiele dafür sind prinzipbedingt akademischer Humbug, denn ein zur Compilezeit feststehendes Ergebnis kann ich genauso gut hardcodieren.

Es sei denn das Ergebnis ist nicht eine Zahl sondern ein Typ.
Dann wirds naemlich interessant.

Ich denke, dann kommt der Horror

#define TYPELIST_1(T1) typelist<T1, null_typelist>
#define TYPELIST_2(T1, T2) typelist<T1, TYPELIST_1(T2) >
#define TYPELIST_3(T1, T2, T3) typelist<T1, TYPELIST_2(T2, T3) >
#define TYPELIST_4(T1, T2, T3, T4) typelist<T1, TYPELIST_3(T2, T3, T4) >

Es sei denn das Ergebnis ist nicht eine Zahl sondern ein Typ.
Dann wirds naemlich interessant.

ahja, das lässt sich nicht hartcodieren, oder was

ahja, das lässt sich nicht hartcodieren, oder was

Tu bitte mal

template <typename ForwardIterator>
void Algorithm(ForwardIterator itr)
{
    typedef typename std::iterator_traits<ForwardIterator>::value_type ValueType;
    ... // Mache was mit ValueType
}

hier ValueType ohne Metaprogrammierung hardcodieren.

ipsec schrieb:

Aber sämtliche Beispiele dafür sind prinzipbedingt akademischer Humbug, denn ein zur Compilezeit feststehendes Ergebnis kann ich genauso gut hardcodieren.

Es sei denn das Ergebnis ist nicht eine Zahl sondern ein Typ.
Dann wirds naemlich interessant.

Ja natürlich, da habe ich mich falsch ausgedrückt. Ich meinte Beispiele wie:

fak<10>::value;
primzahlen_bis<100>::value;
nullstelle<add<mul<2, mul<x, x> >, -1> >::next::value;    // 2. Nullstelle von f(x)=2x^2-1
kuerzester_weg<'A', 'C', graph<knoten<'A'>, knoten<'B'>, knoten<'C'>, kante<'A', 'B', 1>, kante<'B', 'C', 2>, kante<'A', 'C', 100> > >::begin::next;   // 2. Knoten des kürzesten Weges
                                                                                                                                                       // von A nach C in dem Graphen

Diese Ergebnisse kann man wesentlich lesbarer auch hardcodieren.
Das in Verbindung mit Typen TMP gewaltig Entwicklungszeit oder Laufzeit spart, ist natürlich klar. (Man denke an eine Implementierung von vector ohne Templates (und am besten noch ohne Makros, denn die sind böse)).

und am besten noch ohne Makros, denn die sind böse

Interessant ist doch gerade, dass Makros in Kombination mit Template-Metaprogrammierung enormes Potential haben.

Ob nun

TYPELIST_4(int, double, bool, signed char)

oder

STATIC_ASSERT(Condition)

oder

MAP_TYPES(KeyA, ValueA)
MAP_TYPES(KeyB, ValueB)
MAP_TYPES(KeyC, ValueC)

Man hat mit Makros eine effiziente Waffe gegen den unschönen und sperrigen Template-Code. Man kann Metafunktionen wie Funktionen aussehen lassen. Makros ermöglichen sogar mächtige Codegeneratoren wie Boost.Preprocessor.