mfG, Sven

MyFrame::MyFrame(const wxString& title) : wxFrame(NULL, wxID_ANY, title, wxDefaultPosition, wxSize(1000, 1000)){

  // [...]

  // SeaTalk-Objekt erstellen, Zeiger speichern
  this->seaTalkPtr = new SeaTalk();
}

Ein delete im Destruktor der Frame-Klasse bringt logischerweise auch nichts.

Warum sollte das nichts bringen?

class Foo
{
private:
  int* m_p;

public:
  Foo()
  {
    m_p = new int(3);
  }

  Foo(Foo const& foo)
  {
    m_p = new int(*foo.m_p);
  }

  ~Foo()
  {
    delete m_p;
  }

  Foo& operator =(Foo const& foo)
  {
    m_p = new int(*foo.m_p);
  }
};

Wo ist das Problem?

Grüssli

...

Wobei ich dennoch die Initialisierungsliste des Konstruktors verwenden würde

Foo& operator =(Foo const& foo)
  {
    m_p = new int(*foo.m_p);
  }

Ich glaube ich habe mich falsch ausgedrückt. Natürlich geht der Zeiger nicht verloren und ich kann ihn auch wunderbar benutzen, alles läuft, aber wenn ich im MyFrame::OnQuit() ein "delete seaTalkPtr;" reinschreibe, bleibt das Speicherleck bestehen!

Warum?

Wird OnQuit nicht aufgerufen?
Und waere der Destruktor nicht der bessere Platz fuer ein delete?

Woher weisst du dass hier ein Speicher Leck entsteht?

Woher ich weiß, dass ein Speicherleck vorliegt?

Detected memory leaks!
Dumping objects ->
{1448} normal block at 0x00D50EE0, 16 bytes long.
 Data: <  s             > D8 A1 73 00 CD CD CD CD CD CD CD CD CD CD CD CD 
Object dump complete.

Dieser liegt eindeutig an der oben genannten Codestelle!

Danke!

PS: Warum meckert der Compiler hier über die Tilde? Kann man nicht von Destruktoren erben?

MyFrame::~MyFrame() : ~wxFrame(){
	delete seaTalkPtr;
}

Ich nehme alles zurück und behaupte das Gegenteil! Wenn ich den delete in den Destruktor schreibe, funktionierts anstandslos.

Danke!

PS: Warum meckert der Compiler hier über die Tilde? Kann man nicht von Destruktoren erben?

MyFrame::~MyFrame() : ~wxFrame(){
	delete seaTalkPtr;
}

man kann nur von klassen erben.
destruktoren aller basisklassen werden automatisch aufgerufen, wenn sie virtual deklariert sind.

Dravere schrieb:

Foo& operator =(Foo const& foo)
  {
    m_p = new int(*foo.m_p);
  }

rofl, geil ... das ist natürlich Unsinn

Foo& operator =(Foo const& foo)
{
  *m_p = *foo.m_p;
  return *this;
}

Nur zur Rettung meiner Ehre ... *dum di dum*
Hab das wohl ein wenig zu schnell hingeworfen ...

@asc,
Verwende für new Sachen so gut wie nie die Initialisierungsliste. Ist mir zu heiss, wenn dort eine Exception fliegt.

Grüssli

Soll ichs dennoch mal beim Destruktor versuchen (ich wüsste jetzt nicht, wo da der Mehrwert wäre)?

Grundsätzlich ist es üblich den Destruktor, und nichts anderes für das aufräumen zu verwenden. Und wenn du dir nicht sicher bist, könntest du Alternativ auch Smartpointer verwenden (z.B. boost::scoped_ptr, boost::shared_ptr, std::tr1::shared_ptr...), und dir das delete von deiner Stelle aus schenken.

@asc,
Verwende für new Sachen so gut wie nie die Initialisierungsliste. Ist mir zu heiss, wenn dort eine Exception fliegt.

Ich verwende grundsätzlich auf Grund der Exceptionbehandlung die Initialisierungsliste und Smartpointer (nicht zwangsläufig den "teuren" shared_ptr, aber eigentlich inzwischen immer einen geeigneten).

destruktoren aller basisklassen werden automatisch aufgerufen, wenn sie virtual deklariert sind.

Auch wenn sie nicht virtuell sind.

Foo& operator =(Foo const& foo)
{
  *m_p = *foo.m_p;
  return *this;
}

Nur zur Rettung meiner Ehre ... *dum di dum*

Das ist immer noch falsch.

Foo& operator =(Foo const& foo)
{
  *m_p = *foo.m_p;
  return *this;
}

Nur zur Rettung meiner Ehre ... *dum di dum*

this->m_p könnte nicht initialisiert sein, und Foo::m_p ist private.

Foo::m_p ist private.

Inwieweit hindert diese Tatsache Foo:: (!) operator= daran, auf m_p zuzugreifen?

Dravere schrieb:

Foo& operator =(Foo const& foo)
{
  *m_p = *foo.m_p;
  return *this;
}

Nur zur Rettung meiner Ehre ... *dum di dum*

Das ist immer noch falsch.

Aha?
Was ist daran falsch?

this->m_p könnte nicht initialisiert

Das kann auch nicht der Fall sein. Da hätte er bereits vorher (im ctor) ein Problem bekommen.