# Objekte werden zerstört



## BLR (8. Januar 2014)

Hallo zusammen, 
ich habe mit c++ angefangen und habe dabei folgendes Proble:

In der main hab ich nen Vector vom Typ "Auto"

```
vector<Auto> Lvz;
    
    populate(Lvz);
```

Und in einer Supportfunktion, sprich einer Funktion, die an keiner Klasse hängt fülle ich den:

```
void populate(vector<Liwanze> &li) {


    li.push_back(Auto("Joey", Auto::amer));
    li.push_back(Auto("Johnny", Auto::amer));
    li.push_back(Auto("DeeDee", Auto::amer));
    li.push_back(Auto("Suzy", Auto::apac));
    li.push_back(Auto("Sheena", Auto::amer));
    
}
```

nun möchte ich diese Funktion diesen gefüllten Vector in der main ausgeben.
Problem dabei ist, dass er direkt in den Destruktor reingeht, sodass am Ende mein Vector in der main leer ist.

Meine Absicht ist also mehrere Objekte in einer klassenlosen Funktion erzeugen und diese in der Main ausgeben.
Wie kriege ich das hin?
Danke für jeden Tipp


----------



## Matthias Reitinger (8. Januar 2014)

Hallo BLR,

welcher Destruktor wird aufgerufen und wie hast du das überprüft? Kannst du ein vollständiges Beispiel (inkl. main) einstellen?

Grüße
Matthias


----------



## BLR (8. Januar 2014)

geprüft habe ich das, in dem ich gedebugt habe 
der wird aufgerufen:


```
Auto::~Auto() {
}
```


```
int main(int argc, char** argv) {

    vector<Auto> auto;
}
```


```
#include "Auto.h"
#include <iostream>

using std::string;

//Konstruktur der aufgerufen wird

Auto::Auto(string myName, Auto marke) {

    name = myName;
    loc = myLoc;
}
```

dann kommt die klassenlose methode, die von der main aus aufgerufen wird

```
void populate(vector<Liwanze> &li) {


    li.push_back(Auto("meinAuto", Auto::golf));
   li.push_back(Auto("deinAuto", Auto::astra));
  li.push_back(Auto("seinAuto", Auto::mercedes));
  li.push_back(Auto("ihrAuto", Auto::opel));
  
   
}
```

Ich übergebe hier eine Referenz, also erwarte ich, dass die Veränderung am Vector auch in der main vom Vector zu erwarten ist.
Das heisst, wenn ich die Klassenlose Methode aufrufe:


```
populate(Lvz);
```

Dann ist der Vector "Lvz" nicht mehr leer.

Allerdings habe ich dann folgende Ausgabe:

Vectorgröße: 4
Name:  Marke: golf
Name:  Marke: golf
Name:  Marke: golf
Name:  Marke: golf

Danke für jeden tipp


----------



## Cromon (8. Januar 2014)

Hallo BLR

Ich sehe mehrere Probleme mit deinem Code (möglicherweise auch einfach, weil er nicht vollständig ist):
1. 
void populate(vector<*Liwanze*> &li) 

Vorhin wars doch Auto?

2.

```
Auto::Auto(string myName, Auto marke) {
 
    name = myName;
    loc = myLoc;
}
```

marke wird nicht verwendet und somit auch der Member vermutlich nicht mit einem Wert belegt. Was ist myLoc?

Grüsse
Cromon


----------



## BLR (9. Januar 2014)

ja entschuldigung, es handelt sich um eine andere Klasse, aber einfachheitshalber spreche ich hier von der Klasse "Auto"

Typ vom vector ist natürlilch "Auto"


```
void populate(vector<Auto> &li)
```

und der Konstruktor vom Auto muss natürlich richtigeweise so heißen:

```
Auto::Auto(string myName, Auto marke) {
 
    name = myName;
    loc = marke;
}
```

Wie gesagt, möchte ich einfach aus der "main" heraus in einer klassenlosen Funktion paar objekte erzeugen.
Den gefühlten vector dann in der main ausgeben, also die die erzeugten Objekte in der main ausgeben wie:

```
cout << autoVector.at(3).getName() << autoVector.at(3).getTyp()
```


----------



## Matthias Reitinger (9. Januar 2014)

Hallo BLR,

anhand deines Codes kann ich den Fehler nicht nachvollziehen. Bitte poste doch ein vollständiges Minimalbeispiel, das man auch tatsächlich kompilieren kann. Bisher hast du nur Stückwerk geliefert und den Rest in Prosa (vermutlich verbirgt sich der Fehler im Prosa-Text).

Dass der Destruktor deiner Klasse auch vor Ende des Programms schon aufgerufen wird, ist normal. Du legst in der Funktion populate temporäre Objekte an, die dann an push_back übergeben und dort in den Vektor kopiert werden. Anschließend werden die temporären Objekte wieder zerstört und dabei der Destruktor aufgerufen. (Es sei denn der Compiler optimiert das weg.)

Grüße
Matthias

P.S.: Membervariablen initialisiert man am besten mit Initialisierungslisten.


----------



## BLR (10. Januar 2014)

Ja, du hast das Problem richtig erkannt, diese Objekte werden im localen Bereich einer Methode erzeugt.
Diese Methode hat aber kein normalen Vector als Parameter sondern eine Referenz. Daher hab ich gedacht, dass die Änderung ja auch in der Aufrufenden Main da sein sollte, damit ich in der main mit diesem (von der void populate(vector<Auto> &ReferenzAuto) )

Aber auf der anderen Seite geht er natürlich in den Destructor, nach dem er mit der Methode fertig ist.....

Es funktioniert so wie du oder ich es beschrieben haben.

Da habe ich mir gedacht, dass ich den Destruktor einfach aus der .h und .cpp Datei weglasse (was unschön ist) aber der Vector in der main ist dennoch leer 

Der Code:

```
int main(int argc, char** argv) {
    try {
        vector<Auto> myAuto;

        populate(myAuto);

        cout << "name: " << myAuto.at(2).getName() << " Marke: " << myAuto.at(2).getMarke();
  
}
```

Die .h Datei von der Klasse:

```
using std::string;
using std::vector;

class Auto{
public:
    
    enum Marke{ ich=0, du, er, sie};
    
    Auto();
    Auto(string auto, Marke myMarke);

    string get_name() const;
    Marke get_loc() const;



private:

    string name;
    Marke loc;
}
```

Die .cpp Datei

```
#include "Auto.h"
#include <iostream>

using std::string;



Auto::Auto(string myName, Marke myLoc) {

    name = myName;
    loc = myLoc;
}

string Auto::get_name() const {
    return name;
}

Auto::Marke Auto::get_loc() const {

    return loc;
}
Auto::~Auto() {
}
```

seperate globale populate-Funktion, die in der Auto.h definiert 
und in der Auto.cpp implementiert ist: 

```
void populate(vector<Auto> &li) {


    li.push_back(Liwanze("Joey", Marke::ich));
    li.push_back(Liwanze("Johnny", Marke::ich));
    li.push_back(Liwanze("DeeDee", Marke::du));
    li.push_back(Liwanze("Suzy", Marke::er));
    li.push_back(Liwanze("Sheena", Marke::sie));


}
```


----------



## Cromon (10. Januar 2014)

Hallo BLR

Es ist sehr schwer dir zu helfen, wenn du nicht deinen Code postest. Das Beispiel von dir ist an verschiedenen Stellen offenbar vom Original abgeändert worden und compiliert nicht, einige Beispiele:

```
int main(...) {
   try {
     code
}
```

Wo lässt du die schliessende Klammer und das catch?


```
string get_name() const;

myAuto.at(2).getName()
```

Hier musst du dich entscheiden

```
vector<Auto> &li
push_back(Liwanze("Joey", Marke::ich))
```

Wieder gleich, Auto vs. Liwanze


```
Auto::~Auto() {
}
```

Im Header ist aber kein Destruktor.

Poste doch einfach deinen richtigen Code, ansonsten ist das hier heiteres Rätselraten. Und warum ist das so? Weil dein geposteter Code mit Syntaxfehlern behoben die absolut richtige Ausgabe ergibt, nämlich "name: DeeDee Marke: 1".

Viele Grüsse
Cromon


----------



## BLR (10. Januar 2014)

Entschuldigung für die Schnippsel.
hhmm....interessant, ok, dann ist hier der Code an dem ich das versuche. Die Klasse heisst anders.


```
#include <cstdlib>
#include <iostream>
#include <vector>
#include <stdexcept>
#include "Liwanze.h"
using std::vector;
using std::cout;
using std::cin;

/*
 * 
 */
int main(int argc, char** argv) {
    try {
        vector<Liwanze> Lvz;

        populate(Lvz);

        for (int i = 0; i < Lvz.size(); i++) {
            cout << "name: " << Lvz.at(i).get_name() << " Region: " << Lvz.at(i).get_loc();

        }


        return 0;
    } catch (...) {

        cout << "Fehlerhafte Eingabe, das Programm wurde beendet\n";
    }
}
```

Headerdatei


```
#ifndef LIWANZE_H
#define	LIWANZE_H
#include <stdlib.h>
#include <iostream>
#include <vector>

using std::string;
using std::vector;

class Liwanze {
public:
    
    enum Region { ndef=0, amer, apac, emea };
    
    Liwanze(): name(""), loc(){};
    Liwanze(string myName, Region myLoc);
    string get_name() const;
    Region get_loc() const;
    void print();
    virtual ~Liwanze();
private:

    string name;
    Region loc;
 
};

void populate(vector<Liwanze> &li);
```


```
#include "Liwanze.h"
#include <iostream>

using std::string;

Liwanze::Liwanze() {
}

Liwanze::Liwanze(string myName, Region myLoc) {

    name = myName;
    loc = myLoc;
}

string Liwanze::get_name() const {
    return name;
}

Liwanze::Region Liwanze::get_loc() const {

    return loc;
}

void populate(vector<Liwanze> &li) {


    li.push_back(Liwanze("Sui", Liwanze::amer));
    li.push_back(Liwanze("Mark", Liwanze::amer));
    li.push_back(Liwanze("Robert", Liwanze::amer));
    li.push_back(Liwanze("Ralph", Liwanze::apac));
    li.push_back(Liwanze("Sven", Liwanze::amer));

}
```


So ich hoffe, dass du jetzt das Problem nachstellen kannst 
Danke dir im Voraus


----------



## Cromon (10. Januar 2014)

Hallo BLR

Nachdem ich die Syntaxfehler behoben habe funktioniert auch dieser Code einwandfrei. Das folgende ist nicht gut:

```
Liwanze(): name(""), loc(){};

Liwanze::Liwanze() {
}
```

Wenn du den Konstruktor im Header mit einem Funktionskörper versiehst darfst du das nicht in der cpp auch nochmals machen.


```
virtual ~Liwanze();
```

Wird nirgendwo implementiert -> Linkerfehler

Liwanze.h fehlt das #endif, ist wohl nicht mitkopiert.


```
cout << "name: " << Lvz.at(i).get_name()
```

Für den operator std:stream << std::string musst du den Header <string> includieren.

Viele Grüsse
Cromon


----------



## BLR (10. Januar 2014)

Hhm....damit ich richtig verstehe:

Der Standartkonstruktor darf also nicht in der cpp. Datei implementiert werden, da ich das schon in der .h Datei gemacht habe?


----------



## Cromon (10. Januar 2014)

Hallo BLR

Das gilt für jede Funktion: Du darfst sie nur an einem Ort mit einen Funktionskörper versehen, entweder im Header oder in der cpp.

Viele Grüsse
Cromon


----------



## veeman (11. Januar 2014)

Die Funktion push_back erstellt eine Kopie von deinem übergebenen Objekt.

Du hast wahrscheinlich keinen Copy Operator definiert.
Normalerweise sollte dein Compiler bei dem Funktionsaufruf sofort meckern, aber anscheinend ruft deiner einfach den Standardkonstruktor, vermutlich Aufgrund der von Cromon genannten Tatsache der doppelten Konstruktordefinition, auf und du erhältst leere Objekte.

-> Wenn nicht nötig den einen Konstruktor entfernen.
-> Copy Operator für deine Klasse definieren.


----------



## Cromon (11. Januar 2014)

Hallo veeman

Du hast recht, push_back erstellt eine Kopie. By default ist in C++ eine Kopie eines Objekts eine deep copy (im Gegensatz zu vielen anderen (Script-)Sprachen). Das heisst auch alle Member werden kopiert. Mit 'by default' meine ich, wenn kein Copy-Konstruktor definiert ist. Es gibt keinen Fehler, wenn du diesen nicht implementierst, die Standardvariante (wenn keine eigene definiert wurde) ist wohldefiniert.

Grundsätzlich muss ein copy-konstruktor nur im Rahmen der big-4 implementiert werden, also:
Wenn du einen der folgenden implementierst, implementiere alle:
1. Destruktor
2. Assignment-Operator
3. Copy-Constructor
4. Move-Constructor

Grüsse
Cromon


----------



## Matthias Reitinger (11. Januar 2014)

veeman hat gesagt.:


> Die Funktion push_back erstellt eine Kopie von deinem übergebenen Objekt.


Soweit korrekt.



veeman hat gesagt.:


> Du hast wahrscheinlich keinen Copy Operator definiert.


Es gibt in C++ keinen "Copy Operator". Meinst du den Copy-Konstruktor?



veeman hat gesagt.:


> Normalerweise sollte dein Compiler bei dem Funktionsaufruf sofort meckern, aber anscheinend ruft deiner einfach den Standardkonstruktor, vermutlich Aufgrund der von Cromon genannten Tatsache der doppelten Konstruktordefinition, auf und du erhältst leere Objekte.


Wieso sollte der Compiler meckern? Ist kein Copy-Konstruktor deklariert, erzeugt der Compiler (in der Regel) automatisch einen Copy-Konstruktor. 

BLR, ich habe deinen Code auf ein vollständiges Minimalbeispiel reduziert. Es funktioniert bei mir ohne den von dir beschriebenen Fehler.

```
#include <iostream>
#include <string>
#include <vector>

using namespace std;

class Liwanze {
public:
    enum Region { ndef=0, amer, apac, emea };
    
    Liwanze(const string& name, Region loc) : name(name), loc(loc) {
    }
    
    const string& get_name() const {
        return name;
    }
    
    Region get_loc() const {
        return loc;
    }
    
private:
    string name;
    Region loc;
};
 
void populate(vector<Liwanze> &li) {
    li.push_back(Liwanze("Sui", Liwanze::amer));
    li.push_back(Liwanze("Mark", Liwanze::amer));
    li.push_back(Liwanze("Robert", Liwanze::amer));
    li.push_back(Liwanze("Ralph", Liwanze::apac));
    li.push_back(Liwanze("Sven", Liwanze::amer)); 
}

int main() {
    vector<Liwanze> lvz;
    populate(lvz);
   
    for (int i = 0; i < lvz.size(); ++i) {
        cout << "Name: " << lvz.at(i).get_name()
             << " Region: " << lvz.at(i).get_loc() << endl;
    }
    
    return 0;
}
```

BLR, bitte erstelle ein vollständiges Minimalbeispiel, in dem das Problem auftritt. Und stelle bitte sicher, dass das Beispiel auch tatsächlich kompiliert. Sonst kommen wir hier nicht weiter.

Grüße
Matthias


----------



## Matthias Reitinger (11. Januar 2014)

Cromon hat gesagt.:


> By default ist in C++ eine Kopie eines Objekts eine deep copy (im Gegensatz zu vielen anderen (Script-)Sprachen). Das heisst auch alle Member werden kopiert.


Das kann man so allgemein nicht sagen. Sobald eine Klasse Zeiger oder Referenzen enthält, erzeugt der Default-Copy-Konstruktor nur eine flache Kopie.



Cromon hat gesagt.:


> Mit 'by default' meine ich, wenn kein Copy-Konstruktor definiert ist. Es gibt keinen Fehler, wenn du diesen nicht implementierst, die Standardvariante (wenn keine eigene definiert wurde) ist wohldefiniert.


Auch diese Aussage ist nicht allgemein gültig. Der Default-Copy-Konstruktor kann nicht immer automatisch generiert werden. Das ist zum Beispiel der Fall, wenn einer der Member nicht kopierbar ist.



Cromon hat gesagt.:


> Grundsätzlich muss ein copy-konstruktor nur im Rahmen der big-4 implementiert werden, also:
> Wenn du einen der folgenden implementierst, implementiere alle:
> 1. Destruktor
> 2. Assignment-Operator
> ...


Das scheint mir eine nicht ganz zu Ende gedachte Übertragung der "Rule of Three" von C++03 (Destruktor, Copy-Konstruktor und Copy-Assignment-Operator immer gemeinsam definieren) auf C++11 zu sein. Der Move-Konstruktor ist für die Korrektheit nicht nötig (kann aber bei der Effizienz helfen). Andererseits gibt es auch Fälle, in denen man einen Move-Konstruktor, aber keinen Copy-Konstruktor haben möchte/kann (z.B. std::unique_ptr). Siehe weiterführend dazu http://stackoverflow.com/a/4782927/764214.

Grüße
Matthias


----------



## Endurion (11. Januar 2014)

Matthias Reitinger hat gesagt.:


> Das kann man so allgemein nicht sagen. Sobald eine Klasse Zeiger oder Referenzen enthält, erzeugt der Default-Copy-Konstruktor nur eine flache Kopie.



Das klingt richtig, ist aber evtl. der Denkansatz, der in die falsche Richtung führt.

Der Zeiger ist nur ein Zeiger, und der wird sauber kopiert. Das, worauf er zeigt, natürlich nicht (ist ja auch nicht Bestandteil eines Pointers)

Referenzen werden gar nicht kopiert. Ein Objekt mit einer Referenz als Member ist nicht kopierbar.


----------



## Cromon (11. Januar 2014)

Matthias Reitinger hat gesagt.:


> Das kann man so allgemein nicht sagen. Sobald eine Klasse Zeiger oder Referenzen enthält, erzeugt der Default-Copy-Konstruktor nur eine flache Kopie.



Wie Endurion sagte ist das für mich so ein Grenzfall für die Klassifizierung. Wenn ich ein Objekt mit einem Zeiger kopiere ist für mich die Kopie der Adresse bereits eine deep copy, würde das Objekt worauf es zeigt kopiert hätte ja der Zeiger nacher auch einen anderen Wert, das entspricht für mich weniger einer Kopie sondern eher einer Art Reproduktion.



Matthias Reitinger hat gesagt.:


> Das scheint mir eine nicht ganz zu Ende gedachte Übertragung der "Rule of Three" von C++03 (Destruktor, Copy-Konstruktor und Copy-Assignment-Operator immer gemeinsam definieren) auf C++11 zu sein. Der Move-Konstruktor ist für die Korrektheit nicht nötig (kann aber bei der Effizienz helfen). Andererseits gibt es auch Fälle, in denen man einen Move-Konstruktor, aber keinen Copy-Konstruktor haben möchte/kann (z.B. std::unique_ptr). Siehe weiterführend dazu http://stackoverflow.com/a/4782927/764214.



Das ist eine (bis auf den move-assignment-operator) zu Ende gedachte Übertragung der Rule of Three von C++03 auf C++11. Für mich gehört es zur Korrektheit dazu sich genau diese Gedanken zu machen. Das von dir angesprochene Beispiel sehe ich nicht als Widerspruch dazu sondern viel mehr als Bestätigung, siehe:

```
class Foo
{
public:
   virtual ~Foo();
   Foo(const Foo&) = delete;
   Foo(Foo&&);
   Foo& operator = (const Foo&);
};
```

std::unique_ptr ist bei mir auch so implementiert: unique_ptr(const _Myt&) = delete;

Wenn aber jemand findet, der move-Konstruktor kann nicht als Erweiterung der Serie gesehen werden kann ich das durchaus auch nachvollziehen, die ursprüngliche Regel ist ja auch nur da um zu verhindern, dass in den Fällen, in denen das nichtimplementieren des Copy-Konstruktors auch wirklich ein Problem birgt dies nicht passiert.

Viele Grüsse
Cromon


----------



## BLR (11. Januar 2014)

Hallo zusammen und noch mal vielen Dank für die Hilfe.
Der Fehler lag leider ganz wo anders. Ich hab es nicht wahrgenommen, weil ich nicht weiss, was es macht. Und zwar folgendes:

Die NetBeans -IDE hat mir in der Header-Datei folgendes erzeugt:


```
Liwanze(const Liwanze& orig);
```

und in der .cpp auch implementiert:


```
Liwanze::Liwanze(const Liwanze& orig) {
}
```

Also einen Konstruktor mit einer constanten Referenz auf die Klasse "Liwanze".
Aber was hat das für einen Sinn und warum hat es den Code so beeinflusst, dass ich
keine erzeugten Objekte mehr hatte****


----------



## Matthias Reitinger (11. Januar 2014)

Endurion hat gesagt.:


> Das klingt richtig, ist aber evtl. der Denkansatz, der in die falsche Richtung führt.
> 
> Der Zeiger ist nur ein Zeiger, und der wird sauber kopiert. Das, worauf er zeigt, natürlich nicht (ist ja auch nicht Bestandteil eines Pointers)





Cromon hat gesagt.:


> Wie Endurion sagte ist das für mich so ein Grenzfall für die Klassifizierung. Wenn ich ein Objekt mit einem Zeiger kopiere ist für mich die Kopie der Adresse bereits eine deep copy, würde das Objekt worauf es zeigt kopiert hätte ja der Zeiger nacher auch einen anderen Wert, das entspricht für mich weniger einer Kopie sondern eher einer Art Reproduktion.


Wenn also das reine Kopieren des Zeigers eine tiefe Kopie ist, was wäre dann eine flache Kopie? Kopie und Reproduktion sind für mich Synonym, daher verstehe ich nicht was du damit sagen willst.



Endurion hat gesagt.:


> Referenzen werden gar nicht kopiert. Ein Objekt mit einer Referenz als Member ist nicht kopierbar.


Wie kommst du denn darauf? Natürlich können solche Objekte kopiert werden.



Cromon hat gesagt.:


> Das ist eine (bis auf den move-assignment-operator) zu Ende gedachte Übertragung der Rule of Three von C++03 auf C++11. Für mich gehört es zur Korrektheit dazu sich genau diese Gedanken zu machen.


Klar sollte man sich überlegen, ob Move-Semantik für eine Klasse sinnvoll ist oder nicht. Aber sofern meine Klasse kopierbar ist, sollte die Existenz eines Move-Konstruktors keinen Einfluss darauf haben, ob sie korrekt funktioniert. Ich sehe es daher nicht so, dass man in diesem Fall unbedingt den Move-Konstruktor implementieren muss. Beim Beispiel mit unique_ptr wollte ich darauf hinaus, dass man in diesem Fall keinen Copy-Konstruktor implementieren kann. Wenn du = delete als Implementierung siehst (was ich auch nachvollziehen kann), ist das natürlich ein schlechtes Beispiel  Abgesehen davon müsste man sich die Arbeit nicht machen, den Copy-Konstruktor und den Copy-Assignment-Operator explizit als gelöscht zu definieren, da das schon implizit geschieht, sofern ein Move-Konstruktor vom Benutzer definiert wurde.

Grüße
Matthias


----------



## Matthias Reitinger (11. Januar 2014)

BLR hat gesagt.:


> Hallo zusammen und noch mal vielen Dank für die Hilfe.
> Der Fehler lag leider ganz wo anders. Ich hab es nicht wahrgenommen, weil ich nicht weiss, was es macht.


Und genau weil du als Anfänger nicht weißt, was du weglassen kannst und was nicht, solltest du immer ein vollständiges, kompilierbares Beispiel angeben.




BLR hat gesagt.:


> Die NetBeans -IDE hat mir in der Header-Datei folgendes erzeugt:
> 
> [...]
> 
> ...


Das ist der Kopierkonstruktor für deine Klasse. Er wird immer dann aufgerufen, wenn du eine Kopie eines Objektes erzeugst. Das passiert beispielsweise, wenn du das Objekt per-value als Funktionsparameter übergibst (hier an push_back, wie bereits früher erklärt). In dieser Form ergibt der Kopierkonstruktor keinen Sinn, da er nämlich nichts kopiert. Richtig wäre:


```
Liwanze::Liwanze(const Liwanze& orig)
  : name(orig.name),
    loc(orig.loc) {
}
```

Oder aber auch die Deklaration und Definition des Kopierkonstruktors ganz weglassen, da in diesem Fall der Compiler automatisch einen zur Verfügung stellt.

Wenn du die Membervariablen im Konstruktor nicht selbst initialisierst, werden sie sofern möglich mit Defaultwerten versehen. Bei Klassen wie std::string heißt das, dass der Defaultkonstruktor aufgerufen wird (ergibt einen leeren String). Bei primitiven Datentypen wie deinem enum hingegegen wird standardmäßig überhaupt nichts initialisiert, der Inhalt der Membervariable loc ist also mehr oder weniger zufällig.

Deine Objekte waren also schon noch da, sie waren nur mit „unsinnigen“ Werten initialisiert, weil beim Kopieren in den Vektor die Membervariablen nicht kopiert wurden.

Grüße
Matthias


----------



## Endurion (12. Januar 2014)

Matthias Reitinger hat gesagt.:


> Wie kommst du denn darauf? Natürlich können solche Objekte kopiert werden.



Ok, offenbar geht direktes Kopieren schon (Copy Constructor). Nur bei einem STL-Container hast du ganz schnell Probleme, da sich Referenzen nur einmal initial zuweisen lassen.


----------



## Matthias Reitinger (13. Januar 2014)

Endurion hat gesagt.:


> Ok, offenbar geht direktes Kopieren schon (Copy Constructor). Nur bei einem STL-Container hast du ganz schnell Probleme, da sich Referenzen nur einmal initial zuweisen lassen.


Richtig. std::vector<T> erfordert beispielsweise, dass T kopierbar und zuweisbar ist (letzteres ist das Problem).

Grüße
Matthias


----------



## BLR (13. Januar 2014)

Hallo zusammen und vielen Dank für eure Hilfe.
Das Problem lag an einem Codefragment, welches mir die NetBeans IDE selbst erzeugt hat, sodass ich erst nicht daran gedacht habe und zwar das:
in der .h Datei


```
Liwanze(const Liwanze& orig);
```

in der .cpp Datei

```
Liwanze::Liwanze(const Liwanze& orig) {
}
```

Nach dem ich das auskommentiert habe, sind die Objekte auch in der main dar


----------



## BLR (27. Januar 2014)

Das Problem lag darin, dass mir die NetBeans IDE automatisch folgenden Code beim erstellen der .h Datei erstellt hat:


```
//Liwanze(const Liwanze& orig);
```
und in der .cpp Datei ausplementiert hat:


```
//Liwanze::Liwanze(const Liwanze& orig) {
//}
```

Seit dem ich das weggemacht habe, verschwinden meine erstellten Objekte nun nicht mehr.
Vielen Dank noch mal


----------

