Linker-problem mit C++ Templates--> woran liegts????

Michael E.

Einen sehr interessanten Bericht von den einzigen Menschen, die export jemals implementiert haben, findest du bei hier.

Hm ich bin nicht so firm mit den Feinheiten der C++ Normierungsversuche.

Für ein anderes Forum hatte ich mal den Quelltext zu dem gleichen Problem (?) so nach Infos aus dem Netz ergänzt/umgesetzt - leider nicht sauber dokumentiert
ist schon ein paar Monate her.

#ifndef ARRAY_H_
#define ARRAY_H_

#include <iostream>
#include <stdexcept>

using namespace std;

template <class T, int n>
class Array{
private:
	T wert[n];
public:
	int get_size() const;
	T& operator [](int number);
};

template <class T, int n>
T& Array<T, n>::operator [](int number){
	if( number < 0 || number >= n){
		throw out_of_range("Bereichsüberschreitung!");
	}
	return wert[number];
}

template <class T, int n>
int Array<T, n>::get_size() const{
	return n;
}

#endif

die .cpp dazu

#include "Array.h"
using namespace std;

template <class T, int n>
T& Array<T, n>::operator [](int number){
	if( number < 0 || number >= n){
		throw out_of_range("Bereichsüberschreitung!");
	}
	return wert[number];
}

template <class T, int n>
int Array<T, n>::get_size() const{
	return n;
}

und die main:

#include "Array.h"
#include <conio.h>

using namespace std;

int main(){
	Array<int, 5> ca1;
	try{
		for(int i = 0; i < 5; i++){
			ca1[i] = i*i;
			cout << ca1[i] << " ";
		}
	}
	catch(out_of_range& e){
		cout << e.what() << endl;
	}
	getch();
}

Da das anhand eines vorliegenden Quelltextes bearbeitet wurde, geht da wahrscheinlich noch was zu verbessern Beispiel: C-Header

Kann mir einer das Foul erklären, wenn es in dem Quelltext das Thema betrifft?
Oder ist das ein zulässiger Lösungsansatz?

MfG f.-th.

Zu spät sollte erst lesen und dann schreiben

Doch noch einen Link gefunden:
http://www4.informatik.uni-erlangen.de/Lehre/SS07/V_OSE/Skript/11-Templates-2x2.pdf

pumuckl

Max3000 schrieb:

Ich war auf dem Stand dass sich da der C++ Standard spaltet und es viele gibt die das können.

Der Standard spaltet sich da nicht. Der Standard schreibt vor, dass es geht - und die meisten Compiler sind an der Stelle nicht standardkonform, weil sich gezeigt hat dass es keinen wirklichen Mehrwert im Vergleich zum Aufwand hat, export zu implementieren.

Michael E.

f.-th. schrieb:

Kann mir einer das Foul erklären, wenn es in dem Quelltext das Thema betrifft?
Oder ist das ein zulässiger Lösungsansatz?

IMHO ist das gültiger Code, weil die Definitionen in der cpp-Datei exakt mit den Definitionen im Header übereinstimmen. Allerdings kannst du den Code in der einen Datei nicht ändern, ohne auch den Code in der anderen Datei zu ändern. Also hast du keinen Mehrwert von der cpp-Datei und kannst sie ganz löschen.

pumuckl

Michael E. schrieb:

f.-th. schrieb:

Kann mir einer das Foul erklären, wenn es in dem Quelltext das Thema betrifft?
Oder ist das ein zulässiger Lösungsansatz?

IMHO ist das gültiger Code, weil die Definitionen in der cpp-Datei exakt mit den Definitionen im Header übereinstimmen. Allerdings kannst du den Code in der einen Datei nicht ändern, ohne auch den Code in der anderen Datei zu ändern. Also hast du keinen Mehrwert von der cpp-Datei und kannst sie ganz löschen.

Ich denke nicht, dass es gültiger Code ist, weil bereits zur Compilezeit in der ÜE von Array.cpp eine Neudefinition im Code steht. erlaubt wäre dagegen, wenn in zwei verschiedenen ÜEs die selbe Definition je einmal drinsteht, z.B. wenn man die Definitionen des op[] und von get_size() aus Array.h in die main.cpp verlagert. Dann hat man genau den Fall wo die Template-Ausnahme der ODR greift.

Dass das so wie es ist ggf. vom Compiler geschluckt wird liegt wohl daran, dass das Template in der Array.cpp-ÜE nicht instantiiert wird. Eigentlich müsste der Compiler beim ersten Durchgang trotzdem feststellen dass er da doppelte Definitionen im Code hat. Die ODR-Ausnahme bezieht sich nämlich nicht auf Definitionen im Sourcecode innerhalb einer ÜE, sondern darauf, dass das selbe Symbol (d.h. Template-Instantiierung) zur Linkzeit in mehreren ÜEs vorhanden sein darf.

Michael E.

Hast wohl Recht, pumuckl. Hab nur leider meine Literatur nicht hier, ums zu verifizieren

Wie machen es die Hersteller von Tools oder der STL, hab das jetzt nicht so geprüft, oder leben die mit der in meinem Link genannten Einschränkungen mit dem Explicit Instantiation Model auf int und long?
Export lassen wir mal weg.
Und dem Nutzer soll nicht der ganze Quelltext bekannt gegeben werden.

Solche Fälle soll es ja geben.

pumuckl

f.-th. schrieb:

Wie machen es die Hersteller von Tools oder der STL, hab das jetzt nicht so geprüft, oder leben die mit der in meinem Link genannten Einschränkungen mit dem Explicit Instantiation Model auf int und long?
Export lassen wir mal weg.
Und dem Nutzer soll nicht der ganze Quelltext bekannt gegeben werden.

Wenn sie nicht den ganzen Quelltext bekannt geben wollen müssen sie sich wohl auf einzelne Typen beschränken. Vieles wird aber tatsächlich offen ausgeliefert => inclusion model. Man kann sich z.B: durchaus anschauen, wie die STL des jeweils genutzten Compilers implementiert ist, ist aber meistens keine große Freude weil da natürlich nicht auf Lesbarkeit geachtet wird...

Linker-problem mit C++ Templates--&gt; woran liegts????

Linker-problem mit C++ Templates--> woran liegts????