Wie von Klassenreferenz nach Pointer oder umgekehrt ohne Nebeneffekte und Memory-Leaks?

Es geht hier nicht so sehr um Pointer und Referenz, sondern Heap und Stack. "MyClass" ist keine Referenz, sondern "MyClass&" ist eine. Das ist dann kein neues Objekt, sondern praktisch das gleiche wie ein Pointer, nur dass du mit . auf die Elemente zugreifst und nicht mit ->.

Mit new erzeugst du Objekte auf dem Heap, die immer mit delete gelöscht werden müssen.
Das andere ist ein Objekt auf dem Stack. Wenn man davon genug erstellt oder diese Objekte sehr groß sind, kommt irgendwann der stack overflow.

Wenn du Objekte auf dem Heap erzeugen möchtest, dich aber nicht um das delete kümmern willst, kannst du ein C++11 Feature nutzen: shared_ptr
http://en.m.wikipedia.org/wiki…r#shared_ptr_and_weak_ptr

Letztendlich spielt es keine Rolle, ob Pointer oder Referenz, sondern nur, wie lange das Objekt leben soll. Objekte auf dem Stack leben nur so lange, wie der Gültigkeitsbereich existiert. Gibt's du einen Pointer oder eine Referenz auf ein Stackobjekt irgendwo hin und wird dieser Stackframe beendet, ist das Objekt weg und dein Zeiger zeigt auf ungültigen Speicher; es kommt dann beim Zugriff zu einem segfault.

Erzähle etwas mehr von dem Problem, das du hast, dann lässt sich sowas leichter erklären.
Im Gegensatz zu den Sprachen mit garbage collector muss man bei C/C++ etwas mehr nachdenken, wenn es um alloziierten Speicher geht. Die GC-Sprachen machen quasi immer Objekte auf dem Heap, die mit sowas wie shared_ptr verwaltet werden. Wenn keiner mehr den Pointer kennt, wird das Objekt zerstört.

Lars.

shared_ptr sind eine nette Sache. Benutzen wir in der Firma schon länger. Leider können wir den C++11 nicht nutzen wegen iOS :(.
Deshalb nehmen wir direkt gleich boost.

Gerald

Man kann natürlich auch mit class templates arbeiten, so etwa wie in der Win32 COM Programmierung.

// irgendwo im header..
template<class T> class MyPtr {
public:
  T * ptr;
  MyPtr()  { ptr = NULL; }
  ~MyPtr() { ReleaseNull(); }
  void ReleaseNull() { if (ptr) { delete ptr; ptr = NULL; }}
}




int CreateMyClass(MyClass ** pp) {
  *pp = new MyClass();
  if (*pp == NULL) return -1;
  *pp->Init();
  return 0;
}




// Die eigentlich Arbeit ist hier..
int MyFunc() {
  MyPtr<MyClass> my_instance;
  int res;


  res = CreateMyClass(&my_instance.ptr); // oder z.B.   my_instance.ptr = new MyClass();
  if (res < 0)
      ComplainAboutOutOfMemory();
  else
      my_instance.ptr->CallSomeFunction();


  (...)
  return res;
}  // <- destructor von MyPtr<class T> ruft hier delete() für my_instance auf, der Speicher wird automatisch aufgeräumt.

Bitte keine:

if (x) delete x;

http://stackoverflow.com/quest…-to-delete-a-null-pointer
http://en.wikipedia.org/wiki/Delete_%28C%2B%2B%29

Selbe gilt für free:

if (x) free (x)

bitte nicht verwenden!

Johns

Zitat von M-Reimer

"virtual"-Destruktoren in Klassen und wasweißichnichtalles.

Das deterministische Aufrufen der Destruktoren ist das, was mir bei den GC-Sprachen am meisten fehlt. Da kann man immer so schön hinter sich aufräumen. Ansonsten muss man immer mit Dispose-Pattern u.ä. rumärgern. Geht natürlich auch, ist aber etwas gewöhnungsbedürftig.

Zitat von M-Reimer

Wäre ja fast ein Wunder wenn ich bei meinen ersten Schritten nicht irgendwo "Speicher verliere"

Das tut jeder und nicht nur am Anfang seiner Laufbahn.

Ob man nun Objekte mit new oder per Copy-Konstruktor zurückgibt, hängt maßgeblich auch von den Objekten selbst und deren Größe bzw. den Performance-Ansprüchen ab. Bei kleinen Objekten mit ein paar einfachen Feldern (z.B. int o.ä.), muss es nicht zwingend new sein:

class MySize
{
public:
 int Width;
 int Height;


 MySize():Width(0),Height(0) {};
 MySize(int w, int h):Width(w),Height(h) {};
};


MySize GetSize()
{
 return MySize(10, 15);
}


void func()
{
 MySize s = GetSize();
}

Bedenken muss man hier, das insgesamt zwei MySize-Objekte erstellt werden. Das innerhalb von GetSize, welches dann mit Hilfe des (in diesem Fall automatisch erzeugten) Copy-Konstruktor in das Objekt s kopiert wird. Das erste Objekt wird dann gleich wieder freigegeben. Und das ist die größte Fallgrube. Wenn MySize jetzt ein Member hätte, das z.B. ein Pointer auf dynamischen Speicher wäre und dieser würde im Destruktor freigegeben werden, dann hätte s ein Problem, weil es einen Pointer hätte, der auf schon freigegebenen Speicher zeigt. Deshalb muss man in so einem Fall einen eigenen Copy-Konstruktor schreiben, der im neuen Objekt Speicher alloziiert und ihn mit dem Inhalt des alten Objektes füllt.
Typisches Beispiel sind String-Klassen, auch im vdr (nur das Klaus die C-str-Routinen für Strings benutzt, statt "new char[...]" bzw. std::string):
http://projects.vdr-developer.…vdr.git/tree/tools.h#n168
http://projects.vdr-developer.…dr.git/tree/tools.c#n1036

Ein Gefühl kann man dafür kriegen, indem man ein bisschen damit rumspielt und ein kleines, eigenes Reference-Counting implementiert:
(EDIT: das ist natürlich kein reference counting, jedem Objekt wird nur zu Loggingzwecken eine eindeutige ID zugeteilt und es muss wahrscheinlich noch ein Copy-Konstruktor geschrieben werden, der nicht ID vom zum kopierenden Objekt holt)

class RefCounter
{
private:
 static int _next_id;
 int _id;
public:
 RefCounter()
 {
  _id = _next_id++;
  dsyslog("RefCounter: c'tor %d", _id);
 }


 RefCounter(const RefCounter& rc)
 {
  _id = _next_id++;
  dsyslog("RefCounter: copy-c'tor %d", _id);
 }


 virtual ~RefCounter()
 {
  dsyslog("RefCounter: d'tor %d", _id);
 }
}
int RefCounter::_next_id = 0;


class MyClass:public RefCounter
{
...
}


MyClass GetObject()
{
 return MyClass();
}


void func()
{
 MyClass c = GetObject();
}

Keine Sorge, wenn du dir ins eigene Knie schießt - das tun wir alle.
Das wichtigste ist, genau festzulegen, wer die Verantwortung über den Pointer hat, wenn du ein Objekt mit new erstellst.

(jeglichen Code habe ich nicht kompiliert, sondern einfach nur so hingeschrieben)

Lars.

Zitat von johns

Bitte keine:

Code

if (x) delete x;

http://stackoverflow.com/quest…-to-delete-a-null-pointer
http://en.wikipedia.org/wiki/Delete_%28C%2B%2B%29

Selbe gilt für free:

Code

if (x) free (x)

bitte nicht verwenden!

Johns

Alles anzeigen

Bei etwas nachlesen.. berechtigt. Danke.

Zitat von M-Reimer

Ist aber schon verdammt kompliziert, dieses C++. Schon was man beim Klassendesign alles beachten muss.

Der Vorteil ist, dass du die komplette Kontrolle hast.
Der Nachteil ist, dass du dein Programm komplett kontrollieren musst.

Wenn man C++ erst mal verinnerlicht hat, sind die "modernen" GC-Sprachen alle um so einfacher.

Lars.