Template-Klassenprogramierung - Kontruktor wird nicht erkannt

Nexus

Dass es in den FAQ steht, sollte eigentlich reichen.

drakon

Nexus schrieb:

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)..

Simon2

Nexus schrieb:

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.

Nexus

Simon2 schrieb:

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.

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:

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?

unskilled

class complex
{
public:
  complex(const T x=0, const T y=0)
};

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

KasF schrieb:

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.

Simon2 schrieb:

ä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 ...

Simon2

Ok, dann sind wir uns ja einig - schön

Gruß,

Simon2.

hustbaer

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....

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.

Simon2

hustbaer schrieb:

...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.

Da lag ich ja doch richtig Deutsche Sprache, schwere Sprache ...

hustbaer

Naja, ist ja nicht tragisch

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)

Simon2

hustbaer schrieb:

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

Eben.

Gruß,

Simon2.