[c++] delete in destructor

[Baron]

Wat doe ik fout in onderstaande code. Zo werkt ze niet. Als de delete xy weghaal werkt het wel, maar ik heb een memory leak. Ik weet dat het basis c++ is maar ik heb mijn boeken thuis liggen.

code:

class xyvector  
{
public:
  int y;
  int x;
  xyvector();
  ~xyvector();  
};

class xyzvector  
{
public:
  xyzvector Equals(const xyzvector src);
  xyzvector();
  ~xyzvector();
  int z;
  xyvector* xy;
};

xyzvector::xyzvector()
{
  xy = new xyvector();
}

xyzvector::~xyzvector()
{
  delete xy;
}

xyzvector xyzvector::Equals(const xyzvector src)
{
  this->z = src.z;
  this->xy->x = src.xy->x;
  this->xy->y = src.xy->y;
  return *this;
}

void CTest_new_deleteDlg::OnButton1() 
{
  xyzvector a,b;
  CString tmp;
  a.xy->x = 1234;
  b.Equals(a);
  tmp.Format("%d", b.xy->x);
  AfxMessageBox(tmp);
}

[Verwijderd]

Volgens mij moet er [] achter delete staan, dus:
delete[] xy;

[farlane]

Volgens mij is met de new en delete nix mis. De Equals functie is echter wel gek:

code:

xyzvector& xyzvector::Equals(const xyzvector& src)
{
  this->z = src.z;
  this->xy->x = src.xy->x;
  this->xy->y = src.xy->y;
  return *this;
}

[edit]
Omdat je het ding by value doorgeeft wordt er een kopie gemaakt van die src. Je hebt geen copy constructor gemaakt, dus de compiler maakt er zelf een, die een binaire kopie maakt van src. De pointer nar xyvector wordt dus ook gekopieerd. Bij het verlaten van de functie wordt dit object weer gedelete, waarbij in de destructor de xyvector ook wordt gedelete.

Maw, na de equals functie bestaat je originele xyvector niet meer.

[edit2]

Normaal wordt een Equals functie gebruikt om te checken of twee objecten gelijk zijn (in Java anyway), en de operator= functie om twee objecten aan elkaar toe te wijzen.

[Verwijderd]

Tuurlijk moeten er blokhaken achter anders werkt het echt niet hoor.

[Baron]

stukje code vervangen:

code:

xyzvector& xyzvector::operator=(const xyzvector& src)
{
  z = src.z;
  xy->x = src.xy->x;
  xy->y = src.xy->y;
  return *this;
}

en

code:

void CTest_new_deleteDlg::OnButton1() 
{
  xyzvector a,b;
  CString tmp;
  a.xy->x = 1234;
  b = a;
  tmp.Format("%d", b.xy->x);
  AfxMessageBox(tmp);
}

Die blokhaken moeten er helemaal niet staan.

Tanx farlane

[MSalters]

Bug1: Je hebt wel een dtor, maar geen copy ctor
Bug2: en ook geen assignment operator
Bug3: Geheugen voor een vector van elementen
moet je met new[] alloceren
Bug 3b: en met delete[] dealloceren
Bug4: Je kopieert functionaliteit uit de standard
library

edit:
^W^W^W^W^W^W^W^W^W]^W^W^W^W^W^W^W^W^W
Bug3: Je gebruikt een pointer waar je gewoon een object moet embedden. Dus geen new/delete, en dan hoef je instantaan ook geen dtor/copy ctor/assignment meer te schrijven. Al je members hebben dan een goede dtor/copy ctor/assignment, dan maakt de compiler er ook voor je object.

[farlane]

Tanx farlane

np.


En voor de mensen die opeens over de array new/delete beginnen: Het is een andere vector waar we hier over praten. Lees eens wat beter zou ik zeggen.

[Bananeman]

Op dinsdag 05 maart 2002 10:07 schreef avdriel het volgende:
Tuurlijk moeten er blokhaken achter anders werkt het echt niet hoor.

Zoals al aangegeven: nee, die haken horen hier niet te staan.

Die haken worden alleen gebruikt bij het deleten van een array.

[.oisyn]

Waarom maak je sowieso een xyvector object aan met new? Lijkt me een beetje zonde als je m ook gewoon in de klasse zelf kunt instantieren. Ik bedoel dus zo:

code:

class xyzvector
{
public:
    ...
    xyvector xy;
};

nou hoef je m niet steeds weer te alloceren en vrij te geven. Bovendien kun je de hele Equals methode achterwege laten, omdat een byte-voor-byte kopie nu prima werkt

zo dus:

code:

xyzvector a, b;

a = b; // werkt uitstekend

nog veel mooier is natuurlijk als je van de xyzvector een subklasse maakt van xyvector:

code:

class xyzvector : public xyvector
{
public: 
    int z;
};

nu heeft xyzvector alle eigenschappen van xyvector, en ook nog een int z erbij De x en de y kun je gewoon aanspreken alsof het een xyvector is:

code:

xyzvector a;

int x = a.x;
int y = a.y;
int z = a.z;

[farlane]

Op dinsdag 05 maart 2002 14:27 had OiSyN een idee

Is het wiskundig gezien correct om te zeggen dat een xyz vector een soort xy vector is?

[.oisyn]

Op dinsdag 05 maart 2002 16:37 schreef farlane het volgende:

[..]

Is het wiskundig gezien correct om te zeggen dat een xyz vector een soort xy vector is?

ik denk het niet maar het gaat om de convenience
hoewel, een xyz vector is natuurlijk wel een uitbreiding van een xy vector, namelijk 1 dimensie. Berekeningen die je in 2-space doet kun je natuurlijk ook prima in 3-space doen door er een extra component aan toe te voegen. Dus misschien is het wiskundig gezien ook niet eens verkeerd

maar je kunt het ook omdraaien: vind je zijn manier beter dan de mijne? (dit is geen flame richting topicstarter)

[Olaf van der Spek]

Op dinsdag 05 maart 2002 10:47 schreef MSalters het volgende:
Bug1: Je hebt wel een dtor, maar geen copy ctor

Is toch geen bug op zich.

Bug2: en ook geen assignment operator

Is ook geen bug op zich.

Bug4: Je kopieert functionaliteit uit de standard
library

Is geen bug. Misschien een design fout

[curry684]

Op dinsdag 05 maart 2002 16:37 schreef farlane het volgende:
Is het wiskundig gezien correct om te zeggen dat een xyz vector een soort xy vector is?

Hmmm lijkt me welzeker een soort extensie waarbij je de functionaliteit correct uitbreidt met letterlijk een extra dimensie... wiskundig wellicht niet correct maar wat inheritance betreft wel:

code:

class xvector
{
public:
  xvector(int p_X)  { m_X = p_X; }

  inline int X() const  { return m_X; }  

protected:
  int     m_X;
};

class xyvector : public xvector
{
public:
  xyvector(int p_X, int p_Y) : xvector(p_X)
    { m_Y = p_Y; }

  inline int Y() const  { return m_Y; }  

protected:
  int     m_Y;
};

class xyzvector : public xyvector
{
public:
  xyzvector(int p_X, int p_Y, int p_Z) : xyvector(p_X, p_Y)
    { m_Z = p_Z; }

  inline int Z() const  { return m_Z; }  

protected:
  int     m_Z;
};

Overigens zou ik dan eerder voor de generieke variant gaan:

code:

template <typename p_DataType, int p_Axes> class SuperVector
{
public:
  SuperVector(p_DataType p_InitialValue = 0);
  SuperVector(const p_DataType &p_InitialValues[p_Axes]);

  ...

private:
  p_DataType        m_Values[p_Axes];
};

[Bananeman]

Op dinsdag 05 maart 2002 21:07 schreef curry684 het volgende:

[..]

Hmmm lijkt me welzeker een soort extensie waarbij je de functionaliteit correct uitbreidt met letterlijk een extra dimensie... wiskundig wellicht niet correct maar wat

Dat het functioneel correct is was al duidelijk, het ging om de wiskundige correctheid.

Maar toch bedankt.

[curry684]

Op dinsdag 05 maart 2002 21:11 schreef Bananeman2002 het volgende:
Dat het functioneel correct is was al duidelijk, het ging om de wiskundige correctheid.

On second thought is het wiskundig denk ik zelfs wel correct (een extra plane binneninheriten is een legitieme extensie, daar de xy-baseclass van een 3D-object dan juist de 2D-representatie zou voorstellen) maar zou je door het theoretisch eindeloze aantal dimensies eigenlijk juist niet de per definitie eindige inheritancemethode moeten gebruiken maar juist de template-constructie die ik suggereerde... dus wiskundig correct maar functioneel incorrect

Any voters?

[Bananeman]

Op dinsdag 05 maart 2002 22:55 schreef curry684 het volgende:

[..]

On second thought is het wiskundig denk ik zelfs wel correct (een extra plane binneninheriten is een legitieme extensie, daar de xy-baseclass van een 3D-object

We hebben het over een vector, geen object.

dan juist de 2D-representatie zou voorstellen)

Het 2d (xy) gedeelte.

maar zou je door het theoretisch eindeloze aantal dimensies

Een vector voor 684 dimensies?

eigenlijk juist niet de per definitie eindige inheritancemethode

Als je maar genoeg RAM en tijd tot je beschikking hebt kun je blijven deriven tot je een ons weegt.

moeten gebruiken maar juist de template-constructie die ik suggereerde... dus wiskundig correct maar functioneel incorrect

Functioneel correct, want we wilden een 3d (xyz) vector hebben. Dat je niet alle mogelijkheden die deze planeet te bieden heeft afdekt, wil niet zeggen dat het niet functioneel correct is. Hooguit incompleet voor het doel dat je voor ogen staat, wat dat uiteindelijk ook moge zijn.

[MSalters]

Op dinsdag 05 maart 2002 18:27 schreef OlafvdSpek het volgende:

[Over de bugs die ik zag]

Is toch geen bug op zich.
[..]
Is ook geen bug op zich.
[..]
Is geen bug. Misschien een design fout

Wat betreft de laatste heb je een punt. "Bug" in de strikte zin van het woord is een verschil tussen je input documenten en je output source, en in het bijzonder een verschil tussen je specificatie en je source.

Wat dat betreft zijn de ontbrekende operators dus wel bugs; je class moet gekopieerd kunnen worden ( afgeleid uit context van programma, waar het gebeurd ), zonder dat er een memory leak is ( klacht van poster ).

Op het project waar ik momenteel aan werk zijn alle drie "Faults"; we hebben een coding standard die alle drie expliciet verbiedt.

[MSalters]

Op dinsdag 05 maart 2002 14:27 schreef OiSyN het volgende:

nog veel mooier is natuurlijk als je van de xyzvector een subklasse maakt van xyvector:

code:

class xyzvector : public xyvector
{
public: 
    int z;
};

nu heeft xyzvector alle eigenschappen van xyvector, en ook nog een int z erbij De x en de y kun je gewoon aanspreken alsof het een xyvector is:

code:

xyzvector a;

int x = a.x;
int y = a.y;
int z = a.z;

's proberen:

code:

xyzvector a(1,1,1)
xyvector b(2,2)
a+b;

a wordt gesliced naar (1,1), resultaat is (3,3) dus 2D.

[MSalters]

Op dinsdag 05 maart 2002 23:10 schreef Bananeman2002 het volgende:

Een vector voor 684 dimensies?

Geen theoretische natuurkunde gaan studeren, als je daar moeite mee hebt. Dan heb je af en toe vectoren met een niet-aftelbaar oneindig aantal dimensies. [/OT]

[Bananeman]

Op woensdag 06 maart 2002 09:59 schreef MSalters het volgende:

[..]

Geen theoretische natuurkunde gaan studeren, als je daar moeite mee hebt. Dan heb je af en toe vectoren met een niet-aftelbaar oneindig aantal dimensies. [/OT]

Mwah, moeite, 't is meer zoiets van: en het nut van een software implementatie daarvoor is ...

[curry684]

Op dinsdag 05 maart 2002 23:10 schreef Bananeman2002 het volgende:
Een vector voor 684 dimensies?

M'n broer zit in de theoretische natuurkunde en quantumfysica, en daar heb ik al een keer een programmaatje voor geschreven dat een 12-dimensionele hyperkubus moest doorrekenen of zoiets...

Als je maar genoeg RAM en tijd tot je beschikking hebt kun je blijven deriven tot je een ons weegt.

Terwijl de template generiek voor 1 tot x is.

Functioneel correct, want we wilden een 3d (xyz) vector hebben. Dat je niet alle mogelijkheden die deze planeet te bieden heeft afdekt, wil niet zeggen dat het niet functioneel correct is. Hooguit incompleet voor het doel dat je voor ogen staat, wat dat uiteindelijk ook moge zijn.

Twas maar een suggestie

[.oisyn]

Op woensdag 06 maart 2002 09:57 schreef MSalters het volgende:

[..]

's proberen:

code:

xyzvector a(1,1,1)
xyvector b(2,2)
a+b;

a wordt gesliced naar (1,1), resultaat is (3,3) dus 2D.

wat probeer je hiermee nou te zeggen? De + operator is sowieso al niet gedefinieerd

[MSalters]

Op woensdag 06 maart 2002 17:22 schreef OiSyN het volgende:

[..]

wat probeer je hiermee nou te zeggen? De + operator is sowieso al niet gedefinieerd

Nog niet. Alleen is dat waarschijnlijk opdracht 2.
Maar hetzelfde geldt voor alle functies die op
2D vectors werken.

Het punt is LSP, Liskov Substitution Principle, ook wel bekend als het IS-A pronciple. Een class Y mag deriven van X als alle Y'en gebruikt kunnen worden waar een X gebruikt kan worden: Y IS-A X

Een vergelijkbare benadering is 2D-vector IS-A 3D-vector met een component ==0. Dat werkt dus ook niet;

stel dat A,b,c en d 3d vectoren zijn, dan kan a=b+c+d.
Je kunt niet zomaar a een 2D vector maken ( of c, of... )

[.oisyn]

Je kunt wel een 3d vector doorgeven aan een functie die een 2d vector verwacht, en dan zal de z-component dus gewoon buiten beschouwing worden gelaten in berekeningen. Dat bedoel ik dus

Een vergelijkbare benadering is 2D-vector IS-A 3D-vector met een component ==0. Dat werkt dus ook niet

wel eens gehoord van homogene coordinaten? Dat is het principe dat een 2d vector een vector is op een vlak in 3-space

en een 3d vector kun je weer schrijven als coordinaten op een hypervlak in 4-space