template <typename T, typename T1>
T ConvertFrom (T1 val)
{
	if(T1 == int)
	{
		std::cout<<"integer"<<std::endl;
	}
}

Der Rückgabe-Wert ist egal, den benötige ich für später, aber geht das prinzipiell?

thx so far

#include <typeinfo>
if(typeid(T) == typeid(int)) //...

bräuchte mal bitte Feedback dazu, ist das richtig so?

P.S. RTTI kannst du generell auch verwenden, sollte aber eigentlich bei Templates nicht angewendet werden (da templates ja zur Kompilierzeit schon ausgewertet werden - und der Overhead bei RTTI ziemlich groß ist).

Wenn du bei einer Template-Funktion Sonderfälle betrachten willst, dann erzeuge für diese Funktion eine (partiell-) spezialisierte Version, z.B.

template<typename R, typename T>
R Convert(T t)
{
  return R(t);
}

template<typename R, int>
R convert(int i)
{
  cout << "integer: " << i;
  return R(i);
}

Als Antwort auf die Frage von Scorcher:
Wenn du nur bestimmte Datentypen zulassen willst, dann erzeugst du einfach in der allgemeinen Template-Definition einen Fehler, z.B.

template<typename R, typename T>
R Convert(T t)
{
  Error_No_Specific_Conversion_Defined!!! // <- Compile-Error
}

hrmpf, also RTTI wär mir eigentlich schon ganz recht, weil ich mir sonst eigentlich die Templates sparen könnte ...

Wichtig: Willst Du eine Prüfung zur Lauf- (wie bei RTTI) oder bereits zur Compilezeit (wie bei templates) ?

Gruß,

Simon2.

Dazu ein Beispiel: mal angenommen man habe eine generische Funktion zur Berechnung der Fakultät:

template< typename T >
T fac( T x )
{
    return x <= T(1)? T(1): x * fac( x - 1 );
}

Dann würde ein Ausdruck wie

double erg = fac(3.14);

zwar irgendwas liefern, aber keine Fakultät. Will man die Funktion nur für Integer-Typen zulassen, so schreibt man:

#include <boost/utility/enable_if.hpp>
#include <boost/type_traits.hpp>

template< typename T >
typename boost::enable_if< boost::is_integral< T >, T >::type fac( T x )
{
    return x <= T(1)? T(1): x * fac( x - 1 );
}

somit lässt sich der Ausdruck mit dem double erst gar nicht übersetzen. Und man bekommt den Compiler-Fehler nicht in der fac-Funktion sondern genau da, wo man fac(double) aufgerufen hat ... ist ein Riesenvorteil.

Gruß
Werner

Die Antwort auf Vordens Frage lautet *nicht* RTTI (und auch nicht boost::enable_if) sondern einfach Templatespezialisierung!

Und dieselbe Antwort trifft auch auf Scorchers Frage zu, *falls* einfache Überladung nicht ausreichen sollte.

Das enable_if soll wohl auch im TR1 enthalten sein.

Dazu ein Beispiel (...)

Alternativ dazu kann man oft auch einfach ein static asser (BOOST_STATIC_ASSERT) verwenden.

Wenn man mehrere Overloads hat und je nach Typ möchte dass eine bestimmte Implementierung genommen wird und die anderen für die Overload Resolution "ausgeblendet werden" muss man wohl (das IMO greisliche) enable_if verwenden. Wenn man dagegen z.B. nur verhindern möchte dass double/float als Template Parameter verwendet werden würde ich eher zu BOOST_STATIC_ASSERT greifen.

also ganz naiv würd ich ja einfach mal sagen, dass die idee, einem template für verschiedene typen, verschiedene verhaltensweisen einzuprägen, die ganze template idee ad absurdum führt.

Nein, tut sie nicht, im Gegenteil:

Templates implementieren zwar das Prinzip der Generalität, also der Abstraktion. Aber dieses Prinzip ist untauglich, wenn es sich nicht mit Spezialisierung verbinden lässt. Das wird offensichtlich, wenn man sich den std::distance-Algorithmus anschaut. std::distance ermittelt den Abstand zweier Iteratoren. Der Algorithmus ist generisch, d.h. er funktioniert mit jedem Iterator-Typ. Allerdings ist essenziell, dass er je nach Iteratortyp unterschiedlich implementiert wird, weil er sonst in häufigen Fällen ineffizient ist. Und wenn der Algorithmus ineffizient wäre, dann würde man ihn natürlich nicht verwenden, und damit wäre die Generalität des Algorithmus' untauglich.

Daher ist std::distance für Random-Access-Iteratoren durch Zeigerarithmetik (Subtraktion) implementiert und für andere Iteratoren über eine Schleife.

operator int ();
operator double ();

Das war glaub ich eigentlich das, wonach ich gesucht hatte, wobei ich mir das (selbst) nochmal überlegen muss...
Btw was liefert denn ein std::stringstream, wenn die Konvertierung von/in einen Datentyp nicht klappt, Exception oder irgendwelche Errorcodes?
Also wenn ich z.B. so was habe (jetzt wieder mit Templates):

template<typename T, typename T1>
T ConvertFromTo (T1 val)
{
    std::stringstream temp(val);
    T retVal;
    temp >> retVal;
    return retVal;
}

Wird das mir bei nativen Typen immer eine richtige und sinnvolle Konversion durchführen?

...habe jetzt die Operatoren überladen, also z.b.

operator int ();
operator double ();

Das war glaub ich eigentlich das, wonach ich gesucht hatte, wobei ich mir das (selbst) nochmal überlegen muss...

Mit diesen Operatoren kann man sich ins eigene Bein schießen, und stundenlang Fehler suchen. Du solltest zumindest immer aufpassen wenn du mit diesen srbeitest, da in manchen Fällen die Umwandlung vielleicht doch nicht gewollt ist (Auch wenn ich nicht unbedingt Methoden wie "ToString" mag, so haben die doch einen ganz entschiedenen Vorteil: Man muss sie explizit aufrufen).

cu André

Btw was liefert denn ein std::stringstream, wenn die Konvertierung von/in einen Datentyp nicht klappt, Exception oder irgendwelche Errorcodes?

Der Stream setzt das failbit, das du bei Bedarf auswerten kannst, um darauf zu reagieren. Alternativ kannst du ihn auch anweisen, bei Fehlern eine Exception (Typ ios_base::failure) zu werfen, indem du vorher temp.exceptions(ios::failbit); aufrufst.

also ganz naiv würd ich ja einfach mal sagen, dass die idee, einem template für verschiedene typen, verschiedene verhaltensweisen einzuprägen, die ganze template idee ad absurdum führt. schön, dass boost/tr1 da irgendwelche konstrukte für anbieten, aber wenn man mehrere methoden hat, die unterschiedliche eingabetypen erwarten und sich für die jeweiligen typen auch unterschiedlich verhalten, dann sollte man daraus auch unterschiedliche methoden machen.

Mmh, finde ich nicht. Mein Fall:
Ich hab 3 Vectoren geschrieben. Die sind aber keine Container, sondern eben mathematische Vektoren-Klassen. Jetzt macht es natürlich wenig sinn, so einem Vector als Typ beispielsweise string zuzuordnen.
Meine Frage zielt darauf ab, dass ich zur Kompilierzeit solche Fehler vom Anwender gleich als Compilererror anzeigen kann.
Klar, man kann den Vector auch mit einem festen Typ anlegen, aber ich hab ehrlicherweise wenig Lust, das für int, double und float jeweils extra anzulegen.
Man kanns auch dem Verwender der API überlassen, aber naja, ich dachte da kann man halt die Verwendung etwas optimieren und solche "Fehler" gleich aufzeigen.
rya.

Der direkte Weg bedeutet, daß du einfach in der Vektor-Mutliplikation auf die Element-Multiplikation zurückgreifst - wenn der verwendete Typ kein hat, beschwert sich der Compiler mit entsprechenden (zugegeben - mitunter etwas kryptischen) Fehlermeldungen. Etwas klarer werden die Fehlermeldungen, wenn du STATIC_ASSERT und ähnliche Hilfsmittel aus der Boost-Bibliothek verwendest (irgendwo habe ich auch eine Hilfsbibliothek gesehen, mit denen du dem Template Typ-Anforderungen mitgeben kannst).

Base * temp = new Derived();

und anschließend

int c = temp->Convert();

aufrufe, die Konvertierungsfunktion der Oberklasse aufgerufen kriege... Das will ich allerdings um jeden Preis vermeiden, da jede neue Klasse auch ihre eigenen Konvertierungsfunktionen haben soll und dann auch diese aufgerufen werden sollen. Mit void * könnte ich zwar zum Ziel kommen, allerdings sind hierbei dann die Hin - und Rückkonvertierungen jeweils auch zwecks Typprüfung relativ aufwendig. Ich hoffe, dass es dafür irgendeine Lösung gibt (die mir allerdings derzeit ein wenig schleierhaft ist

Irgendwie ganz schön strange was du da machen willst. Man könnte höchstens über boost::any nachdenken. Oder wenn es keine Templates sein dürfen, mußt du halt ein void* zurück geben, und derjenige muß casten.

template <typename T, typename T1> T Convert ()
{
//...
}

abgeleitet:

template <typename T> T Convert<std::string> ()
{
}

Allerdings geht dies nicht, ich hoffe, irgendwer kann mir nun helfen

Trotzdem verstehe ich den Sinn deiner Konvertierungstemplates immer noch nicht?
Wenn du einfach nur Konvertierungen nach String- und zurück brauchst, dann würde ich über die Stringstreams gehen:

template<class T> string toStr(const T& t)
{
	std::ostringstream str;

	str << t;

	return str.str();
}

template<class T> T fromStr(const string& s, const T& def = T())
{
	std::istringstream str(s);
	T t = def;

	str >> t;

	return t;
}

Ansonsten müßtest du für beliebige Datentypen die Funktion 'Convert' mit den jeweiligen Datentypen überladen (jedoch darf sich die Funktion nicht alleine im Rückgabewert unterscheiden, d.h. "int Convert()" und "float Convert()" geht nicht!!!).

Alternativ müßtest du dann jeweils eine Klasse (bzw. Struktur) darum packen:

template<typename R>
struct Convert
{
  template <typename T>
  static R Do(T t) { return R(t); }
};

// Aufruf, z.B.
int x = Convert<int>::Do(42.123f);

Du könntest jetzt dann entsprechend des Rückgabetypes spezialisieren:

template<>
struct Convert<int>
{
  template <typename T>
  static int Do(T t) { std::cout << t; return int(t); }

  static int Do(std::string s) { return 0; } // Überladung
};

// Aufruf z.B.
int x = Convert<int>::Do(42.123f); // float->int
int y = Convert<int>::Do(std::string("hallo")); // string->int

Mehr fällt mir aber auch nicht mehr ein und ich hoffe, ich habe dich (in Ansätzen) richtig verstanden, was du vorhast???