Erkennen ob ein das Objekt eines Pointers noch existiert

IMHO nein.

Gruß
Stefan

Ich habe bis jetzt da zwar selber noch nicht mit gearbeitet, sondern nur darüber gelesen, aber evtl. ist der "try-catch"-Mechanismus das was du suchst.

moin,

sie dir mal das an, ist zwar nicht die antwort auf deine frage, aber vielleicht hilft es weiter

http://www.oop-trainer.de/Themen/Singleton.html

Hi,

Zitat

Original von Brougs78
Leider sehr ernüchternd ... muss mal darüber nachdenken wie ich das lösen/umgehen kann. Hier wäre so eine "on error goto"-Syntax wie bei VB wirklich praktisch.

Das macht doch speziell try/catch(...), es fängt einfach alles, die Klammer mit drei Punkten sind absicht...

Also z.B.

try {
  if(ptr != NULL)
     ptr->foo()
} catch(...) {
  ptr = NULL;
}

Vielleicht hilft rtti noch :

if (dynamic_cast<cTimer*>(a) != NULL)

am saubersten ist trotzdem ein Smartpointer, bzw. einfach im Destruktor des Pointerobjekt eine Cleanuproutine ...
Andreas

Ohne weiteres ist so eine Überwachung nicht möglich, da in C++ ein Pointer auf ein Objekt nun mal nur eine Speicheradresse ist. Einige Fehlertests sind möglich (Speicher vergeben, Typprüfung des Objekts etc.), aber das sind nur Indizien, keine verlässlichen Tests.

Denkbar wäre eine Implementierung von intelligenten Pointern, die sich wie normale Pointer verhalten, aber als Objekt-Template implementiert sind. Dazu gehört eine Basisklasse, die in die eigentlichen Objekte eingeerbt wird.
Die Basisklasse und der intelligente Zeiger bilden ein Team: Der Zeiger registriert sich während seiner Lebenszeit beim Objekt, und das Objekt löscht im Gegenzug alle registrierten Zeiger, wenn seine Lebenszeit zu Ende geht. (Bei Multithreaded-Programmen kann das natürlich fatale Nebenwirkungen haben, aber in solchen Situationen musst du dich sowieso um exklusiven Zugriff bemühen.)

In der Praxis lohnt der Aufwand meistens nicht, es ist einfacher, im großen Bogen drum herum zu programmieren. Versuche, den Zeiger nicht so lange zu halten, dass jemand anderes das Objekt löschen kann. Besorg dir einen neuen Zeiger, wenn du ihn brauchst.

Gruß,

Udo

Das obrige Beispiel von try/catch fängt nur seqfault's

Ist ja alles relativ, ein Pointer ist nur eine Zahl von einer Speicheradresse, ab der die Datenstruktur deinen Timer liegt, beim freigeben des Speicher wird dieser ja nicht automatisch gelöscht, sondern nur für ungenutzt erklärt, bis die nächste Speicheranforderung diesen Speicherbereich neu zuweist. Und jetzt an der Speicheradresse auf die Pointer zeigt jetzt die andere Daten enthält. Möglicherweise sogar einen anderen Timer
Aber meistens zeigt die Pointer mitten in eine andere Datenstruktur.
Wenn der Timer nur numerische Daten enthält, fällt der Unterschied nur durch wirre Daten auf.

Deshalb als Lösungvorschlag, einfach per lookup überprüfen ob dein Timerpointer noch in der Liste der verhandenen Timer enthalten ist.

z.B. mit cTimer *cTimers::GetTimer(cTimer *Timer)

Andreas

Wenn du den Typ des Objekts kennst, kannst du doch mit

typ* meintyp = NULL;
meintyp =dynamic_cast<typ*>(originalpointer);

if (meintyp) cout << "Juhuuuu, det geht";

gucken, ob es noch da ist, oder bin ich auf dem holzigen Weg?

Also in deinem Fall das timer-objekt dynamic_casten auf eine neue Zeigervariable? Sollte es vorher gelöscht worden sein, müsste das doch "irgendwie" scheitern, oder?

PS: Wenn der Timer gelöscht, aber immer noch korrekt da ist, müsstest du ihn natürlich auch noch extra validieren, gegen die Timerliste z.b.

Der vorgelagerte Typtest würde allerdings verhindern, dass du dem armen VDR laufend "irgendnen Müll" zu fressen gibst

Na, wenn Du ganz sicher gehen willst, überprüfst Du nicht nur den Inhalt sondern auch den Pointer selber :

bool foo::ValidTimer(cTimer *Timer)
{
  for (cTimer *ti = Timers.First(); ti; ti = Timers.Next(ti)) {
      if (ti == Timer && ti->Channel() == Timer->Channel() && ti->Day() == Timer->Day() && ti->Start() == Timer->Start() && ti->Stop() == Timer->Stop())
         return true;
      }
  return false;
}






....




return ValidTimer(timer) ?  timer : NULL;

Cu,
Andreas

Wie schon gesagt, es kann keinen sicheren Weg geben, um einen Pointer auf Lebendigkeit zu testen. Im schlimmsten Fall gehort der referenzierte Speicher bereits einem ganz anderen Objekt oder ganz anderen Daten, und dann kann ein Zugriff nahezu beliebigen Unfug bewirken. Auch ein dynamic_cast hilft da nicht mehr.

Eigentlich ergibt sich aber doch aus GetTimer() von selbst die optimale Vorgehensweise:

Leg vom Timer eine Komplettkopie an, den dazu nötigen Zuweisungsoperator gibts doch:

cTimer Remember = *timer;

Später, wenn du den Timer wieder brauchst, suchst du ihn einfach:

cTimer *timer = Timers.GetTimer(&Remember);

Ich denke, das ist der Weg, den Klaus für sowas vorgesehen hat. Den alten Zeiger wieder in GetTimer hinein werfen, das funktioniert natürlich nur, so lange der alte Timer noch zufällig an der Speicheradresse steht. Es muss schon eine Kopie sein.

Gruß,

Udo

Zitat

Original von Brougs78
Ev. ist mein voriger Ansatz doch der sicherste, in dem ich einfach die Timer durchgehe und Suche ob ich den Pointer (also nur den Verweis) noch finde.

Ja. Beachte bitte dass Timer nur im Vordergrund-Thread des VDR bearbeitet werden sollten, da die Klasse keine Locking-Mechanismen (anders als z.B. Channels, die auch im EPG-Thread modifiziert werden) implementiert. Anderenfalls könnte es sein dass Du den Timer gerade benutzt, während er Dir per SVDRP, OSD oder weil er abgelaufen ist "unterm Hintern" weggelöscht wird.

Zitat

Wenn ein Timer weg ist, dann werde ich auch keinen Timer mit der Speicheradresse mehr finden. Und wärend eines VDR-Lebens wird ja der Speicherbereich der Timer nicht verschoben oder?

Korrekt.

Zitat

Oder macht das der Kernel ev.?

Nein. Eine solche Verschiebung tritt nur auf wenn VDR intern den Timer neu allokiert und kopiert. Das passiert aber nur wenn der Timer editiert wird (hier wird eine Kopie editiert und nach dem Editiervorgang ins Original zurückkopiert), ist also für Dich unerheblich.

Zitat

Original von Brougs78
Danke für die Infos. Das mit dem Vodergrund-Thread und Timer-Editieren habe ich auch schon mit Klaus abgesprochen. Derzeit gibt es ja die IncBeeingEditted und DecBeeingEditted (oder so ähnlich) und die beiden Methoden werden ja auch in SVDRP verwendet um das ganze halbwegs sicher zu machen. Klaus meinte aber auch dass er da mal ev. eine wirklich threadsichere Variante machen möchte.

Da SVDRP selbst im Vordergrund-Thread abläuft, ist das nicht wirklich eine Gefahr :), und Inc-/DecBeingEdited sind auch nicht wirklich Thread-Safe (hier wird nicht mit Mutexen sondern mit einfachen Zählern gearbeitet). Sie sollen den VDR nur vor Torheiten bewahren, wenn während des Vordergrund-Threads das Menü "Timer bearbeiten" am OSD sichtbar ist.

Zitat

Bis dahin muss man eben im Vordergrund-Prozess sagen dass man was an den Timern editiert damit kein anderer dazwischenpfuscht. Wenn man in einem Thread arbeitet muss man eben darauf achten dass nicht gerade edtiert wird bzw. die SVDRP-Schnittstelle nutzen (die das gleich macht).

Sollte für eine Alltagsanwendung sicher vorerst gehen, da ich nicht damit rechne, dass mehrere User parallel per OSD, SVDRP und per Thread in einem Plugin die Timerliste befeuern

Für absolute Sicherheit sorgt allerdings trotz allem nur ein echtes Locking