frage zum kopierkonstruktor
-
Du meinst:
temp = a.mult(b); //mecker....Wo hier der Copy-Constructor aufgerufen wird?
Laut Deiner Fehlermeldung:/home/dgrat/Documents/vektor/src/vektor.cpp:76: error: vektor::vektor(vektor&)
/home/dgrat/Documents/vektor/src/vektor.cpp:136: error: initializing argument 1 of `vektor vektor::mult(vektor)'für b.
Warum?
Du übergibst an mult eine Kopie des Vektors. Mal abgesehen davon, dass das teuer wird wenn die Vektoren gross werden, wird für das Anlegen der Kopie der Copy-Ct. benötigt. In Wirklichkeit macht der Compiler daraus (Pseudo-Code):Vektor& Vektor::mult( Vektor& x); // so "denkt der Compiler es sich" Vektor x(b); // hier der Copy-Ctr das generiert er, weil Du eine Kopie haben willst temp = a.mult(x); // jetzt kann er die Referenz übergeben, ohne das Du b in der Funktion modifizieren kannstDasselbe gilt bei Deiner Klasse auch für:
a.mult(2).sub(c.mult(2)).add(d.mult(2))
-
mhh, danke erstmal für die geduld, aber das bsp, hat nur irgendwie nicht unter dev gefunzt.. obwohl compiler sehr zuverlässig sind unter linux dann aber doch!
folgendes hat nicht funktioniert:temp = a.mult(b.mult(2) );und weil
"b.mult(2)"eben sowas wie
"b"ist, hat mich das gewundert... .
aber du hast ja jetzt gut erklärt wo der c-ctr. aufgerufen wird, danke.
der c-ctr wird also bei sämtlichen kopiervorgängen aufgerufen die klasseneigene objekte betreffen, egal ob direkt mit dem ctr. oder mit einer member-fkt.
-
ssm schrieb:
exigoner schrieb:
float* vektor::get_vektor() { v = new float[3+1]; v[0] = x; v[1] = y; v[2] = z; v[3] = 4; //groeße return v; delete [] v; }

frag mich grad, warum du v returnst, also raus gehst aus der Methode und danach (obwohl du gar nicht mehr drin bist, den Speicher für v frei gibst... naja, wird schon seine Gründe haben, steht da net irgendwo vom Compiler irgendsowas wie: Waring: Unreachable Code
?
-
nein der gcc, warnt mich nicht. ich hab das gemacht weil ich irggendwo gelesen habe, dass ich mit new allokierten speicher wieder frei geben muss. also sollte ich wohl diese variable im destruktor delete'n und im konstruktor allokieren, oda->sicher...
aber ich hatte keine lust soviel zu schreiben.ist diese aussage nun richtig?
der c-ctr wird also bei sämtlichen kopiervorgängen aufgerufen die klasseneigene objekte betreffen, egal ob direkt mit dem ctr. oder mit einer member-fkt.
dann weiß ich wenigstens wann i9ch diese referenzen benötige wenn ich nen eigenen c-ctr. mache.
-
jo, wäre auf jeden Fall besser, die im Konstruktor zu allokieren und im Destruktor zu deallokieren, als die Anweisung hinter ner Anweisung stehen zu lassen, bei der se sowieso nie an kommt
-
zum "zweiten" thema
warum verwendest du kein unionunion { struct { float x, y, z, w; } m; float val[4]; };float *vektor::get_vektor() { return &val[0]; }
-
weil ich es nicht kenne,...
ist das schlimm?
-
exigoner schrieb:
weil ich es nicht kenne,...
ist das schlimm?es würde auf jedenfall einige probleme lösen bzw ein paar sachen vereinfachen.
bsp: du bräuchtest keinen dynamischen speicher
zum thema union siehe: http://tutorial.schornboeck.net/union.htm
-
ich weiß nicht so recht... ist union nicht ein überbleib-sel aus vergangenen c-zeiten

ich kann mir vorstellen, dass der code vielleicht unübersichtlich wird. wie oft/wo wendet ihr sowas an? immer da wo ihr auf new und delete verzichten wollt?
in meinen programm wär das auf jeden fall eine interessante alternative.ps: ich nehme mal aufgrund fehlender einwände an, dass meine aussage bezüglich des c-ctr. richtig war. [hopefully]
-
miller_m schrieb:
es würde auf jedenfall einige probleme lösen bzw ein paar sachen vereinfachen.
bsp: du bräuchtest keinen dynamischen speicher
zum thema union siehe: http://tutorial.schornboeck.net/union.htmWelchen Gewinn hat man durch die union? Ein struct würde es doch auch tun. Ich hoffe, Du willst die Union nicht zum casten missbrauchen. Dein Link zeigt das z.B. im 2. Beispiel auch falsch. Nur auf das letzte zugewiesene Element der Union darf zugriffen werden (mit einer Ausnahme für POD-Structs). (9.5)
-
exigoner schrieb:
wie oft/wo wendet ihr sowas an?
in meinen vektor klassen in den ich zeiger auf das erste element benötige

exigoner schrieb:
immer da wo ihr auf new und delete verzichten wollt?
das eine hat eigentlich nicht nichts mit den anderen zu tun
exigoner schrieb:
in meinen programm wär das auf jeden fall eine interessante alternative.
sehe ich genau so
exigoner schrieb:
ps: ich nehme mal aufgrund fehlender einwände an, dass meine aussage bezüglich des c-ctr. richtig war. [hopefully]
deine aussage ist für mich eigentlich nichts sagend. denn es wohl klar das wenn
du kopierst wird er aufgerufen.
wichtig ist nur das du entscheiden musst wann du kopieren willst und wann nicht.
-
das glaub ich nicht, wie soll ich mir das array im uniun dann vorstellen, 4 zeilen lan und nur w gespeichert?
-
7H3 N4C3R schrieb:
Welchen Gewinn hat man durch die union?
hauptsächlich schreibarbeit und die gewissheit das im array das selbe steht
wie in den werten des structs. und ich kann einfach einen pointer auf das erste element zurückgeben7H3 N4C3R schrieb:
Ich hoffe, Du willst die Union nicht zum casten missbrauchen.

nein, wie kommt man auf so eine idee
7H3 N4C3R schrieb:
Dein Link zeigt das z.B. im 2. Beispiel auch falsch. Nur auf das letzte zugewiesene Element der Union darf zugriffen werden (mit einer Ausnahme für POD-Structs). (9.5)
was meinst du? shades beispiel

-
Den Link den du gepostet hast. Siehe Standard Sektion 9.5.
-
7H3 N4C3R schrieb:
Den Link den du gepostet hast. Siehe Standard Sektion 9.5.
hab kein standard da, poste mal bitte den text. was für einen sinn hätte dann lt. dme standard union?
-
"In a union, at most one of the data members can be active at any time, that is, the value of at most one of the data members can be stored in a union at any time."
Der Zweck von Unions ist der selbe, wie er schon immer war: Speicher sparen.
-
mir ist schon halbwegs klar was du geschrieben hast, was auch gut in shades erstem bsp. behandelt wird. dh mein code bzw. shades code sind lt standard illegal
-
Japps, sollte laut Standard illegal sein (bzw. undefiniert). Weiß garnicht, wie das in C war und was man sich dabei jetzt gedacht hat. Immerhin gibt es da ein paar Schnittstellen, die sich darauf verlassen (Berkley Socket-API z.B.).
In irgendeinem Text hat Alexandrescu auch mal geschrieben: "Unions are not for casting!".
-
was ist casten

-
Die implizite oder explizite Umwandlung eines Typen in einen anderen.