Template Functions funktioneren nicht

icarus2

Heisst also, dass man es so lösen sollte?

#ifndef BASIC_ARITHMETIC_INCLUDED
#define BASIC_ARITHMETIC_INCLUDED

#include "BasicArithmeticOperations.cpp"

namespace my_math {

	template<typename T>
	T add(T a, T b);

	template<typename T>
	T subtract(T a, T b);
}

#endif

Nexus

icarus2 schrieb:

Heisst also, dass man es so lösen sollte?

Nein, inkludier keine .cpp-Dateien! Ich habe in meinem oberen Post beschrieben, wie du es machen kannst.

Nexus schrieb:

sanyas schrieb:

Außer du includierst im Header die Implementierungs-Datei.

Implementierungsdateien sollte man nicht inkludieren. Folglich muss die Definition von Templates immer in Headerdateien stehen ( export wird sowieso kaum unterstützt).

Ich hab das eiegntlich genau so gemeint, wie du es dann unten machst
Wenn man unbedingt Header und Implementierung trennen will, dann muss man die Implementierungsdatei (ob man die jetzt .inl, .impl, .tmplimpl, .tpp, ... nennt ist egal) nach der Deklaration includen.

Ein ".cpp" als template-Implementierung zu nehmen, ist ungünstig, da .cpp eigentlich impliziert "kompilier mich separat". Und das geht mit templates nicht.
Templates sind eine Vorlage. Es wird, wenn du die Funktion (oder auch Klasse) das erste mal mit einem bestimmten Typ verwendest, Code generiert und kompiliert. Damit der Compiler diesen Code generieren kann, muss ihm die komplette Implementierung bekannt sein, weshalb eben alles in einer Datei stehen muss - Der compiler kann ja jetzt schlecht raten, wie die Datei mit der Implementierung heißt...

icarus2

Ersma Danke für eure Beiträge

Ich habe jetzt mal etwas gebastelt, aber ich habe atm ziemlich Mühe mit dem ganzen

Ich habe jetzt einmal versucht eure Vorschläge umzusetzen (sry, wenn das wieder nicht gut ist, ich habe im Moment etwas Mühe mit dem ganzen).

Passt das so?
Das Header-file als Schnittstelle:
BasicArithmeticOperations.h

#ifndef BASIC_ARITHMETIC_INCLUDED
#define BASIC_ARITHMETIC_INCLUDED

namespace my_math {

	template<typename T>
	T add(T a, T b);

	template<typename T>
	T subtract(T a, T b);
}

#include "BasicArithmetic.inl.h"

#endif

Und dann noch die eigentliche Implementierung der Methoden im separaten Header-file BasicArithmetic.inl.h

#ifndef BASIC_ARITHMETIC_INL
#define BASIC_ARITHMETIC_INL

namespace my_math {
	template<typename T>
	T add(T a, T b){
		return a + b;
	}

	template<typename T>
	T subtract(T a, T b){
		return a - b;
	}
}

#endif

Das .cpp file habe ich jetzt vollständig weggelassen.

drakon

Ja, kann man so machen.

Nexus

Ja, grundsätzlich ist das richtig. Allerdings kannst du gleich die Dateiendung .inl nehmen statt .inl.h, ausserdem brauchst du keine Include-Guards in der .inl-Datei, weil sie nur an einem Ort (in der .h- oder .hpp-Datei) eingebunden wird, wo bereits Guards stehen.

icarus2

Was ist der Unterschied zwischen .inl und .h? Oder besser gesagt... wann nimmt man .h und wann nimmt man .inl?

Aber die include-Guards schaden ja auch nicht wirlich, oder? Falls es doch von mehreren files includiert werden würde, so besteht die Gefahr nicht, dass diese vergessen gehen. Oder liege ich da falsch?

Nexus

icarus2 schrieb:

Was ist der Unterschied zwischen .inl und .h? Oder besser gesagt... wann nimmt man .h und wann nimmt man .inl?

Es spielt eigentlich keine Rolle. Ich mache es allerdings so, dass Schnittstellen in .hpp-Dateien stehen, und Implementierungen von Templates in .inl-, ansonsten .cpp-Dateien.

Ist auch etwas Geschmackssache, aber .inl.h habe ich jetzt noch nie gesehen.

icarus2 schrieb:

Aber die include-Guards schaden ja auch nicht wirlich, oder? Falls es doch von mehreren files includiert werden würde, so besteht die Gefahr nicht, dass diese vergessen gehen. Oder liege ich da falsch?

Sie schaden nicht, aber sie sind sinnlos. Template-Implementierungsdateien sollten immer nur von einer Datei inkludiert werden (dem zugehörigen Schnittstellen-Header).

icarus2

Ok, soweit ich das sehe macht dein System mit den Endungen Sinn

Vielen Danke für alle eure Beiträge, haben mir sehr geholfen.

Nexus schrieb:

Sie schaden nicht, aber sie sind sinnlos.

Natürlich schaden sie: Sie müssen ausgewertet werden und kosten somit CPU-Power und Compile-Zeit :p

icarus2

Alles klar, ich werde sie rausnehmen... bevor ich meine CPU noch zum explodieren bringe