Den Sinn eines Copy-Konstruktor hab ich jetzt verstanden auch wie er arbeitet.

17 // copy Konstruktor
18 C::C (const C& c)<---- Kann mir jemand diese Zeile erklären?? vor allem die Argumente verwirren mich ( (const C& und die variable))

19 : m_x(c.m_x),
20 m_y(c.m_y)

17 // copy Konstruktor <---- Kann mir jemand diese Zeile erklären??

Kommentar???

wenn du zum bleistift zeiger in deiner klasse hast, die im konstruktor mit new initialisiert werden und im destruktor wird delete aufgerufen, und wenn du eine kopie eines objektes zulassen möchtest, musst du dir gedanken über die flache kopie versus die tiefe kopie machen.

den kopierkonstruktor gibt es immer. er ist .. auch wenn du ihn nicht implementierst.. für dich da und macht eine flache kopie des objektes.

Person peter;
Person paul = peter; //Person paul(peter);

was aber, wenn du im konstruktor mit new einen weiter bereich alloziert hast? dann kopiert die flache kopie nur die zeigeradresse, und peter wie paul zeigen auf die gleiche stelle. damit wird zweimal über der gleichen stelle delete aufgerufen .. schlecht.

die "regel der großen drei" besagt: benötigt eine klasse einen der großen drei: kopierkonstruktor, destruktor oder zuweisungsoperator, dann müssen die anderen beiden auch implementiert werden.

les dazu auf hume sikkins seite oder in entsprechenden tutorials.

so long

@Computerbücher für einen euro:

Ja sry ich hab den Fehler bereits ausgebessert

Thx

C& das ist nicht der adressoperator sondern der reference operator. also das objekt wird als reference übergeben und nicht als kopie..sagt dir call by reference und call by value etwas?

und naja die varibale bestimmt ja nur den namen des übergebenen objekts

Ja nur in dem Beispiel aus dem ich diesen Codeschnipsel kopiert habe, wird auch kein neuer Speicher allokiert....

Ich weiß jetzt nicht, welche "Speicherallokation" Du meinst.
Wenn Du aber meinst, ein CopyCtor sollte Speicher für das Objekt selbst (hier also "ein C") allokieren: Braucht er nicht !! Der CpyCtor wird erst aufgerufen, wenn der Speicher für ein neues Objekt bereits allokiert wurde !
Es wird auch nicht der CpyCtor des "alten", sondern der des "neue Objektes" aufgerufen.

class C {
int i;
public:
    C() : i(0) {}
    C(C const& c) : i(c.i) {
        c.i = 2; // ---> FEHLER !!! geht nicht wegen "const"
    }
    void seti(int a) {i = a; }
};

int main() {
    C c1; // c1.i == 0
    c1.seti(1);    // c1.i == 1
    C c2(c);    // allokiert erst Speicher für c2 und 
        // ruft dann (implizit) c2.C(c1); (== CpyCtor) auf
        // => c2.i == 1
...

Wenn C jetzt "Heapspeicher" für seine Variablen braucht (sprich: "irgendwo ein new/delete macht)), muß das wahrscheinlich im CpyCtor auch passieren.

muhi schrieb:

K das einzige was ich noch wissen will, wieso hier der Adress-Operator "&" in der Argumentliste steht....

Naja, wenn da kein "&" stände, würde der Compiler eine weitere ("temporäre") Kopie von c1 anlegen, um die dann dem CpyCtor von c2 zu übergeben. Das wäre einerseits unnötig/zeitraubend und andererseits sehe ich da irgendwie "rekursive Probleme" beim CpyCtor (muß ich mal ausprobieren) (schließlich wird das temporäre Objekt ja selbst auch wieder per CpyCtor erzeugt, für desse n Aufruf ja eine andere Temporäre Kopie erzeugt werden muß, für die der CpyCtor aufgerufen wird, für ....)

Gruß,

Simon2.

class foo
{
private:
	int *xyz;

public:
	foo()
		: xyz( new int( 10 ) )
	{}

	~foo()
	{
		delete xyz;
	}

	void set( int num )
	{
		*xyz = num;
	}

	int get() const
	{
		return *xyz;
	}
};

int main()
{
	foo bar;
	bar.set( 50 );
	foo foobar( bar );
	foobar.set( 70 );
	std::cout << bar.get() << " " << foobar.get(); // Ausgabe 70 70
} // Fehler beim zerstören von foobar

Die Lösung ist also ein Copy C'tor der auch xyz korrekt kopiert.

foo( const foo &other )
{
	// selbstzuweisung testen, etc...
	xyz = new int( *other.xyz );
}

Dann passts.

grüße

dazu hab ich auch ne kleine kurze Frage. Den Stern bei *other.xyz muss man setzen, weil xyz ein Zeiger ist, richtig?

Weil other ist ja eine Referenz, da braucht man die Dereferenzierung ja nicht. Also wegen xyz oder?

Und was wäre, wenn man den Stern weglassen würde? Wurde man dann mit der Adresse von xyz arbeiten?

foo( const foo &other )
{
    // selbstzuweisung testen, etc...
    xyz = new int( *other.xyz );
}

dazu hab ich auch ne kleine kurze Frage. Den Stern bei *other.xyz muss man setzen, weil xyz ein Zeiger ist, richtig?

Weil other ist ja eine Referenz, da braucht man die Dereferenzierung ja nicht. Also wegen xyz oder?

Und was wäre, wenn man den Stern weglassen würde? Wurde man dann mit der Adresse von xyz arbeiten?

So isses!

muhi schrieb:

Ok ich versteh gar nix mehr ich glaub ich gebs auf...

Was verstehst du denn nicht?

grüße

Ok ich versteh gar nix mehr ich glaub ich gebs auf...

Ist gar nicht so schwer:
- Was ist "other" ? Richtig: "const foo &" = eine (const-)Referenz; d.h. man kann auf other genauso zugreifen wie auf ein "normales Objekt": other.xyz.
- Was ist xyz ? Richitg: Ein "int* " = ein Zeiger; d.h. man greift auf den Speicherplatz, auf den er zeigt mit * oder -> zu: *xyz = 3
- Wie greift man auf xyz von other zu ? Richtig: other.xyz
- Wie greift man auf den Speicherplatz, auf den other.xyz verweist zu ? Richtig: *(other.xyz) oder (wenn man die Operatorenreihenfolge beachtet - man braucht keine Klammern) *other.xyz

Etwas verwirrend wirkt wahrscheinlich, weil es so aussieht, als bezöge sich * auf other (sowas wie other) ... tut's aber nicht
Es bezieht sich auch xyz; so in der Art "_____.xyz".

Gruß,

Simon2.

Wies funzt hier denn kein call by value?

also ein CopyCon kopiert das übergebene objekt und man hat am ende dann zwei objekte. das zu kopierende und einmal die kopie.

sie sind damit von einander unabhängig und wenn du das eine löschst ist das andere noch vorhanden.

das wäre dann nen prog:

int main{
A* a1 = new A();
a1->setI(234);
A *a2( a1 );
a2->setI( 9876 );

// nun ist auch *(a1.i) == 9876
delete a1;

a2->setI( 21 ); // error der pointer von i zeigt nämlich nun in nicht
                //alloziierten speicher, der wurde nämlich mit dem zerstören von a1 wieder 
                //freigegeben

B * b1 = new B();
b1->setI( 45 );
B *b2 = new B(b1);
b2->setI( 565 );
// *(b1.i) ist immer noch 45

delete b1;

b2->setI(45677); //geht ohne weiteres. der pointer ist immer noch ok, da er auf
                 //seinen eigenen speicherbereiche zeigt

return 0;
}

so ich hoffe das hilft

EDIT: is keine antwort auf vorposter hab gar nur zu spät gepostet-

Klasse::Klasse( const Klasse& src){}

dabei ist src natürlich nur ein bezeichner und kann auch anders lauten

wäre es nämlich keine reference sondern ein call by value würdest du das objekt erstmal beim übergeben kopieren und dann nochmals innerhalb deines kopierkonstruktors.

nun stelle dir mal eine super komplexe klasse vor die mehr als 10000 andere objekt enthält die wiederum etwas komplexer sind.

und nun male dir mal aus weöche performance auswirkungen es hätte jedesmal alle objekte 2 mal zu kopieren...

wenn ich mich nicht täusche MUSS der CopyConst diese Signatur haben.

Klasse::Klasse( const Klasse& src){}

Du täuschst dich. Korrekt ist, dass der Copy-Ctor einen Referenz-Parameter erhalten muss. Dabei ist aber egal, ob das Ziel der Referenz als const, volatile, const volatile oder nichts von alledem angesehen werden soll.

wäre es nämlich keine reference sondern ein call by value würdest du das objekt erstmal beim übergeben kopieren und dann nochmals innerhalb deines kopierkonstruktors.
[...]
und nun male dir mal aus weöche performance auswirkungen es hätte jedesmal alle objekte 2 mal zu kopieren...

Es käme noch viel schlimmer, da du nicht zweimal sondern bis in alle Ewigkeit kopieren würdest. Beim "by value"-Aufruf wird eine Kopie erzeugt. Für das Erzeugen einer Kopie wird der Copy-Ctor verwendet. Würde der Copy-Ctor seinen Parameter "by value" übernehmen, müsste beim Aufruf des Copy-Ctors erstmal wieder eine Kopie erzeugt werden. Das würde wieder den Copy-Ctor aufrufen, wobei wieder eine Kopie erzeugt werden müsset, was wieder den Copy-Ctor aufrufen würde... und so weiter ...

...
Es käme noch viel schlimmer, da du nicht zweimal sondern bis in alle Ewigkeit kopieren würdest....

Schön, habe ich also recht vermutet. (Habe ich aber noch nirgendwo gelesen ... sollte man vielleicht mal aufschreiben).

Gruß,

Simon2.

Foo(Foo f);

schlicht nicht erlaubt ist.

@Simon2
Ist ja letztlich irrelevant, da eine Signatur wie:

Foo(Foo f);

schlicht nicht erlaubt ist.

Aber ich finde es immer besser, wenn ich einen konkreten Grund sehe, warum etwas nicht erlaubt ist. Kann ich mir einfach leichter merken, wenn es plausibel ist.

Gruß,

Simon2.