folgender Code sei vorhanden um ein "Wörterbuch" zu implementieren, soll jedoch jetzt nur als Beispiel dienen:

extern "C"
{
	template<typename Tk, typename Tv>
	class __declspec(dllexport) xyz
	{
	private:
		Tk* keyArray;
		Tv* valueArray;

	public:
		xyz();
		~xyz();
		void addPair(Tk key, Tv value){
			keyArray = (Tk*)alloc(/*whatever*/);
			valueArray = (Tv*)alloc(/*whatever*/);
			// usw...
		}
	};
}

Diesen Code würde ich gerne in einer statischen Bibliothek exportieren und in einem Programm, welches diese Lib nutzt, wie folgt verwenden:

// ...
xyz<int, short> whatever;
whatever.add(1,2);
// ...

Nun ist es ja leider nicht möglich, Templates zu exportieren.
Ich habe überlegt, einfach ein paar "Vorgaben" zu exportieren, wie z.B.

extern "C"
{
class __declspec(dllexport) VorlageByteInt
{
	private:
		xyz<BYTE, int> dasTemplate;
	public:
		//...			
};
class __declspec(dllexport) VorlageShortInt64
{
	private:
		xyz<short, long int> dasTemplate;
	public:
		//...			
};
// usw...
}

Allerdings scheint mir das nicht gerade die feine Art zu sein.
Wie löse ich das am besten?

Gruß.

Da nur der Compiler mit Templates etwas anfangen kann, macht es wenig Sinn, sie aus einer DLL exportieren zu wollen, und damit der Compiler sie verwenden kann, muss er sie in Gänze kennen. Wenn die Template, um die es dir geht, zu deinem API gehören soll, wirst du daher nicht umhinkommen, sie in einem Header zu definieren und diesen auszuliefern -- sonst kennt der Compiler desjenigen, der deine Bibliothek benutzen will, die Template nicht und kann keine Klasse/Funktion daraus stanzen.

Gibt´s noch irgendwelche anderen Wege, um das Problem zu "umgehen"?
Ich muss nicht unbedingt einen finden, ich frage das aus reinem Interesse...

dllexport ist Windows-only und (wie der Name vermuten lässt) fürs exportieren aus DLLs gedacht. DLLs sind dynamische Bibliotheken, also das Gegenteil von statisch.

@Nathan: Ist mir alles bekannt, trotzdem danke
Extern "C" wird, soweit ich weiß, vorallem wegen überladenen Funktionen, die C nicht kennt, verwendet, um somit "kompatibel" zu sein...

Aber zum Thema zurück, ich glaube es ist geklärt, dass es da keine "Alternative" gibt.

Danke euch

würde eben vom Compiler zu etwas wie

__party__foo_int_barp_float

als Name verwurstet werden (in der Realität nicht so primitiv), damit die Funktion für den Linker eindeutig ist.

extern "C" int foo(bar*, float);

würde auch danach noch foo heißen.

Eher umgekehrt...
Extern C ist für C++ Programme, die C Code verwenden, da die interne Signatur von C-Funktionen anders ist als die von C++ (wegen Überladung).

extern "C" kann auch in der Gegenrichtung verwendet werden, also wenn man in einer C++ Library eine Funktion definieren möchte, so dass sie aus einem C Programm aufgerufen werden kann.

extern "C" bewirkt einfach nur dass die Bezeichner C-kompatibel dekoriert werden. Ob man die Bezeichner dann verwendet um etwas zu konsumieren oder zu exportieren ist egal.