3. undefined reference to "constructor"

undefined reference to "constructor"

  • F

    Entweder du schreibst das ganze direkt in die Header-Datei, oder du inkludierst die Implementationsdatei in die Header-Datei. Mache ich meist so, zwecks Überblick.

    Es gibt noch eine Möglichkeit, diese unterstüzt aber kaum ein Compiler.

    Lg freeG

    0
  • K

    beatbasser schrieb:

    d.h. ich muss die funktionen direkt in der klassendefinition inplementieren?
    ich probiers gleich mal aus.

    Nein, das heißt es nicht. Es heißt, dass Du die Definitionen nur mit in den Header packen musst -- nicht unbedingt innerhalb der Klassendefinition. Definierst Du Funktionen innerhalb einer Klassendefinition sind die automatisch inline.

    Der Ansatz, eine Resource wie Speicher in einem Objekt zu kapseln, ist löblich. Allerdings kannst Du es Dir auch noch viel einfacher machen, indem Du statt einem Zeiger, dessen Kopiersemantik dir ja offensichtlich nicht gefällt, da Du Kopierkonstruktor, Destruktor & co überschreiben tust/müsstest, einfach einen vector<T> als Datenmitglied benutzt. Ui! Langer Satz. Ich hoffe, Du verstehst, was ich meine.

    0
  • B

    vielen dank erstmal,

    ihr habt mir hier wirklich geholfen.

    ich geb zu, dass die aufgabe im zusammenhang mit der stl nicht wirklich die sinnvollste ist, sollte sie aber auch nicht sein, sondern mir eher eine übung. deswegen auch der umgang mit den zeigern. sicherlich könnte ich auch auch in der klasse direkt ein array deklarieren und mit dem dann arbeiten, dann hätte ich den ganzen ärger nicht, aber auch nicht den spaß 😉

    ich werde den punkt mit den "großen drei" noch berücksichtigen. das war mir so nicht bewusst, wie wichtig der copy-contructor ist.

    für alle, die ein ähnliches problem haben und später über diesen threat stolpern:

    ich habe, ausgehend von den codes, lediglich ein #include "matrix.cpp" in der header-datei unter der klassendefinition hinzugefügt, #include "matrix.h" aus der matrix.cpp entfernt und diese datei auch nicht separat kompiliert.

    0
  • K

    beatbasser schrieb:

    ich habe, ausgehend von den codes, lediglich ein #include "matrix.cpp" in der header-datei unter der klassendefinition hinzugefügt, #include "matrix.h" aus der matrix.cpp entfernt und diese datei auch nicht separat kompiliert.

    Das macht man eigentlich nicht. Praxis ist die, Definitionen von Funktionstemplates entweder im Header zu lassen, oder per #include im Header eine Datei mit einer anderen Endung als cpp einzubinden, weil diese Datei keine eigene Übersetzungseinheit sein muss/sollte.

    0
  • B

    ich finde es auch komisch, dass ich auf diese art und weise kein eigene objekt-datei für die member-funktionen erzeuge, aber im moment ist es die einzige lösung, die ich habe.

    wie wäre denn die wirklich saubere variante zu realisieren?

    0
  • K

    beatbasser schrieb:

    wie wäre denn die wirklich saubere variante zu realisieren?

    Wurde das hier nicht schon mehrfach gesagt (inklusive meines letzten Beitrags)?!

    0
  • B

    ich versteh dass jetzt so, dass die elegante variante ist, die template-defintionen direkt in den header zu schreiben.

    der übersichtlichkeit halber hätte ichs gern in einer seperaten datei. sollte ja nicht das problem sein, die dann einfach per #include einzubinden. ist ja quasi das gleiche.
    kurz, ob ichs direkt in header schreibe, oder so inkludiere, sollte das gleiche sein. berichtigt mich, wenns nicht stimmt.

    meine letzte frage, die sich also noch stellt. kann ich eine seperate objekt-datei erzeugen, die ich dann mit dem hauptprogramm linke? und wenn ja, wie?
    ich stelle die frage, weil es ja auch möglich sein sollte, ein .o datei schon fertig zu haben, die ich dann nicht jedes mal neu kompilieren muss.

    0
  • N

    beatbasser schrieb:

    ich versteh dass jetzt so, dass die elegante variante ist, die template-defintionen direkt in den header zu schreiben.

    der übersichtlichkeit halber hätte ichs gern in einer seperaten datei.

    Ja, das ist elegant. Machs mit einer .inl-Datei, die du am Schluss der .hpp-Datei inkludierst. Nicht dass dies krümelkacker nicht schon mehrmals gesagt hätte...

    beatbasser schrieb:

    meine letzte frage, die sich also noch stellt. kann ich eine seperate objekt-datei erzeugen, die ich dann mit dem hauptprogramm linke?

    Nein, das geht nicht, da der Compiler die Template-Parameter erst zur Instanziierungszeit einsetzen kann. Du kannst höchstens einzelne Instanziierungen separat kompilieren.

    0
  • C

    beatbasser schrieb:

    der übersichtlichkeit halber hätte ichs gern in einer seperaten datei. sollte ja nicht das problem sein, die dann einfach per #include einzubinden. ist ja quasi das gleiche.
    kurz, ob ichs direkt in header schreibe, oder so inkludiere, sollte das gleiche sein. berichtigt mich, wenns nicht stimmt.

    Klar kannst du das machen, nur solltest du die Datei nicht CPP nennen 😉

    meine letzte frage, die sich also noch stellt. kann ich eine seperate objekt-datei erzeugen, die ich dann mit dem hauptprogramm linke? und wenn ja, wie?
    ich stelle die frage, weil es ja auch möglich sein sollte, ein .o datei schon fertig zu haben, die ich dann nicht jedes mal neu kompilieren muss.

    Nein, das geht nicht, außer du weißt schon vorher alle Datentypen, mit denen das Termplate jemals instantiiert werden soll.
    Das Template ist nicht alleinstehend verwendbar (im Gegensatz zu z.B. Generics aus C#), sondern erst wenn der Compiler weiß, was er für die Template-Parameter einsetzen soll. Darum benötigt er im Hauptprogramm den Quelltext des Templates.

    (theoretisch ist im Standard noch export vorgesehen, aber das hat afair noch kaum ein Compiler umgesetzt)

    0
  • ?

    CStoll schrieb:

    (theoretisch ist im Standard noch export vorgesehen, aber das hat afair noch kaum ein Compiler umgesetzt)

    Und in c++-11 wird es auch wieder aus dem Standard entfernt.

    0
  • P

    CStoll schrieb:

    (theoretisch ist im Standard noch export vorgesehen, aber das hat afair noch kaum ein Compiler umgesetzt)

    Im alten Standard ists noch vorgesehen. Umgesetzt hats genau ein einziger Compiler (Comeau), und die haben da 2 Mannjahre an Entwicklung reingesteckt, nur um das export-Feature zu implementieren und zu zeigen, dass es keine nennenswerte Verbesserung bringt.
    Wie von manni66 beschrieben wirds aus dem C++0x-Standard komplett rausgenommen, mit dem Einverständnis der Comeau-Entwickler, die ja dadurch dann die 2 Jahre endgültig in den Sand gesetzt haben.

    SIehe dazu auch hier:
    http://herbsutter.com/2010/03/13/trip-report-march-2010-iso-c-standards-meeting/

    0
  • B

    man könnte behaupten, dass manche hier ihren namen nicht umsonst haben 😉
    ich bin mal ganz naiv davon ausgegangen, dass es doch egal ist, wie ich das kind nenne, solang ich weiß wie es heißt.

    trotzdem, danke an die vielen hilfreichen tipps. ich bin mit der klasse schon fast soweit, wie ich sie (im moment) haben will.

    ich denke, alles was jetzt hier noch kommt, wird mir zu hoch.
    hauptsache, es funktioniert 😉

    0

  • pumuckl schrieb:

    Im alten Standard ists noch vorgesehen. Umgesetzt hats genau ein einziger Compiler (Comeau), und die haben da 2 Mannjahre an Entwicklung reingesteckt, nur um das export-Feature zu implementieren und zu zeigen, dass es keine nennenswerte Verbesserung bringt.

    Umgesetzt hat es EDG, nicht Comeau. Comeau verwenden EDGs Frontend, und bieten das Feature in ihrem Compiler an, mehr nicht.

    Und gedauert hat es 1.5 Jahre für Design/Planung + 3 Mannjahre Entwicklungszeit.

    siehe: http://www.open-std.org/Jtc1/sc22/wg21/docs/papers/2003/n1426.pdf - "2.2 (Prohibitively) Expensive to implement"

    0
Anmelden zum Antworten