Ich habe eine Klasse definiert, die unter anderem folgenden Code beinhaltet:
Headerdatei:

template<typename T> 
class complex 
{
 private:
   T re;
   T im;
 public: 
   complex();
   complex(const T, const T);
   complex(T);
};

Programmdatei:

template<typename T>
complex<T>::complex(const T x=0, const T y=0) : re(x), im(y) 
{  
   return;
}

Also wie ihr seht, will ich mir einen Kontruktor schreiben, welcher 2 Parameter erwartet.
In meiner main Datei definiere ich das Template mit dem Wert double beim instanzieren eines Objectes wie folgt aus:

complex<double> x(3.9,4.0);

Beim Compilieren bekomme ich nun den Fehler:
...undefined reference to 'complex<double>::complex(double,double)'

Warum ?
Wenn ich den Kontruktor direkt in der Headerdatei ausdefinieren, gibts keine Probleme.
Ich würde mich über Hilfe sehr freuen !

Darum muss das ganze in den Header. Du kannst es ansonsten ja auch in eine andere Datei schreiben und diese dann per include am Ende der Header Datei einfügen. (Das wird normalerweise gemacht..)

ich glaube, in diesem Fall ist wesentlicher, dass Du die Default-Parameter erst in der Implementation definierst - sie müssen aber in der Deklaration ("Klassendefinition") definiert werden:

template<typename T>
class complex
{
...
   // complex(); den braucht's nicht bzw. darf's wegen der Eindeutigkeit nicht geben
   complex(const T x=0, const T y=0) : re(x), im(y) {} // ruhig hier schon Implementation
   // außerdem: Da ei Ctor keine "Funktion" (im klassischen Sinne) ist, braucht's auch kein return
...
};

Das von drakon geschilderte Problem hätte Dich erst beim Linken erwischt (und da auch nur für genutzte Konstruktoren) und nicht schon beim Compile....

Gruß,

Simon.

...

Ups. Das kommt davon, wenn man den Post nicht ganz durchliest.
Normalerweise kommt ja eh die gekürtzte Verison dieses Problems.

Gruß,

Simon2.

Dass es in den FAQ steht, sollte eigentlich reichen.

Naja. Sollte mal ein wenig erweitert werden.
z.B das mit dem Compiler. Wurde zwar angesprochen, aber nicht aufgenommen. Es geht ja nicht darum einen zu nehmen, den wir wollen, sondern einfach nur einen aktuellen. Dann ist alles OK. Aber sich immer wegen alten, inkompatiblen Compiler Fehler einzuhandeln, kann es nicht sein.
Oder auch eine gute, aktuelle Bücherliste (für Anfänger)..

Dass es in den FAQ steht, sollte eigentlich reichen.

ich habe auch nicht dafür plädiert, ein eigenes Subforum aufzumachen, sondern meinte eher: Die Threads zu diesem Thema würden locker ein eigenes Subforum füllen.

Ich meine auch nicht, dass ein Subforum besser funktionierte als die FAQ. Beides krankt am gleichen Ansatz: Erst wer schon weiß, dass <XYZ> sein eigentliches Problem ist, kann er danach suchen und finden.
Und dazu noch: Erst wenn er weiß, dass sein "absolut merkwürdiges und einzigartiges Problem (vermutlich Compilerfehler)" in Wirklichkeit ein 08/15-Fehler von Anfängern ist, kommt er auf die Idee, in den FAQs nachzusehen...

Gruß,

Simon2.

ich habe auch nicht dafür plädiert, ein eigenes Subforum aufzumachen, sondern meinte eher: Die Threads zu diesem Thema würden locker ein eigenes Subforum füllen.

Ja, das hab ich auch so verstanden.

Aber du hast schon Recht. Dazu kommt noch, dass die FAQ meiner Ansicht nach sehr unübersichtlich ist. Manche Titel sagen nichts aus oder sind sonst verwirrend, viele Themen überschneiden sich inhaltlich, und einige sind von mir aus gesehen alles andere als "frequently asked".

Naja, liegt auch daran, dass einfach gewisse Threads, die als wichtig erachtet werden, in den FAQ-Bereich verschoben werden.

Das von drakon geschilderte Problem hätte Dich erst beim Linken erwischt (und da auch nur für genutzte Konstruktoren) und nicht schon beim Compile

Tut es doch auch beim Versuch den Konstruktor aufzurufen:

meisteralex schrieb:

In meiner main Datei definiere ich das Template mit dem Wert double beim instanzieren eines Objectes wie folgt aus:

complex<double> x(3.9,4.0);

Und hier der Linkerfehler:

meisteralex schrieb:

undefined reference to 'complex<double>::complex(double,double)'

Anscheinend hat er doch die Impl. in ne andere Quelldatei ausgelagert:

meisteralex schrieb:

Wenn ich den Kontruktor direkt in der Headerdatei ausdefinieren, gibts keine Probleme.

Oder ist es schon zu spät und ich übersehe etwas?

ich würde den CTor als explicit marken - außerdem würde ich
(const T &x = T(), const T &y = T())
schreiben - aber da weiß ich nicht, ob es sich was nimmt (bei dir wird der copy-ctor von int zu T vrmtl aufgerufen bei meiner variante wird nur der default ctor aufgerufen), also:

class complex
{
public:
  explicit(const T &_re = T(), const T &_im = T()) : re(_re), im(_im) {}
};

bb und gn8 ^^

PS: Als Referenz, weil es im Vergleich zu den Standard-Typen Copy-CToren wahrscheinlich nur ein wenig langsamer ist bei großen Zahlen (also extra Bibliotheken für die) allerdings sehr viel schneller sein sollte - aber falls es darauf so sehr ankommt würde man da vielleich auch mit boost::enable_if oder so - je nach dem wie groß der datentyp ist - die const ref-variante oder die per-value-methode einschalten können, weiß ich aber nicht, ob sich dafür die schreibarbeit lohnt und ob das überhaupt so einfach geht

Simon2 schrieb:

Das von drakon geschilderte Problem hätte Dich erst beim Linken erwischt (und da auch nur für genutzte Konstruktoren) und nicht schon beim Compile

Tut es doch auch beim Versuch den Konstruktor aufzurufen...

äh ... wo liegt denn der Unterschied zwischen "Konstruktor nutzen" und "Konstruktor aufrufen" ?

Gruß,

Simon2.

äh ... wo liegt denn der Unterschied zwischen "Konstruktor nutzen" und "Konstruktor aufrufen" ?

äh ... da liegt kein Unterschied vor.

Aber nach genauerer Betrachtung von:

Simon2 schrieb:

Das von drakon geschilderte Problem hätte Dich erst beim Linken erwischt

wurde mir klar was du meintest, war doch wohl schon spät ...

Gruß,

Simon2.

Das von drakon geschilderte Problem hätte Dich erst beim Linken erwischt (und da auch nur für genutzte Konstruktoren) und nicht schon beim Compile....

Es ist das von drakon geschilderte Problem, und der Fehler HAT ihn auch erst beim Linken erwischt. Dass der OP den Unterschied nicht für relevant hält und deswegen "beim Compilieren" hinschreibt ist wieder eine andere Sache.

Die Default-Parameter in der Implementierung sind natürlich trotzdem Blödsinn. Das eigentliche Problem waren sie hier aber wohl nicht.

...Es ist das von drakon geschilderte Problem, und der Fehler HAT ihn auch erst beim Linken erwischt. ...

hmmmmmmm ... das ist aber diesmal besonder gut versteckt. Ich wäre auch von einer Compilerfehlermeldung ausgegangen (hatte aber auch nicht realisiert, dass "... undefined reference ..." schon so eine Art "Schlüsselwort für Linker" ist (könnte glatt schon in C++09 aufgenommen werden ).
Also gut: Man lernt nie aus - auch das Lesen nicht.

Gruß,

Simon2.

Wer unter MSVC schon öfters solche Fehlermeldungen hat weiss halt dass das ein Linker-Fehler ist.
Zugegeben, es wäre theoretisch möglich dass andere Tool-Chains das anders machen, aber eine "undefined reference" vom Compiler... wüsste nicht was das bedeuten soll. Vor allem wenn dort schon genau die Funktion angegeben ist die ihm abgeht. (Und da Default-Parameter an der Signatur nichts ändern kann das IMO eben auch nicht reinspielen)

...eine "undefined reference" vom Compiler... wüsste nicht was das bedeuten soll. ...

Eben.

Gruß,

Simon2.