unique_ptr und Lebenszeit

Für mich wäre es so, als ob ich die Fenster an meinem Haus vergittere, weil ich schon zweimal herausgefallen bin und dann mit Knochenbrüchen mehrere Wochen ausfiel

cooky451

Wenn man unique_ptr so nutzt, sollte die Serverinstanz so plaziert sein, dass es offensichtlich ist wenn irgendein Pointer aus dem Scope geht. Normalerweise sieht das doch so aus:

{
  Server s;
  los_gehts(s);
}

Oder wie auch immer. Jedenfalls eindeutig so, dass man nicht mal eben Zeiger aus dem Scope mitnimmt.

Die Server-Objekte sind selber dynamisch erzeugt. Die Lebenszeiten und -Räume erstrecken sich über unzählige Dateien und über Event-betriebene Prozessgrenzen. Es ist halt eine dynmische und flexible GUI-Anwendung, mit eingebautem Undo, Modellen, Views etc. Da kann man halt auch mal einen Bock einbauen, finde ich.

Dieses super-übersichtliche C++, das man hier in den Minimalbeispielen sieht, habe ich immer nur bei meinen schönen Konsolenapplikationen oder bei Schleifenbasierten 3D-Sachen.

knivil

Model-View-Controller ...

PS: Ja, das Problem ist abgehackt.

cooky451

Decimad schrieb:

Dieses super-übersichtliche C++, das man hier in den Minimalbeispielen sieht, habe ich immer nur bei meinen schönen Konsolenapplikationen oder bei Schleifenbasierten 3D-Sachen.

Dann bau deine GUI-Anwendung halt so, dass sie wieder wie dieses super übersichtliche C++ aussieht. Das ist nicht unmöglich. z.B. könntest du die Lebenszeit eines Servers einfach an das Fenster koppeln, über das er gesteuert wird.

dot

Decimad schrieb:

Die Server-Objekte sind selber dynamisch erzeugt. Die Lebenszeiten und -Räume erstrecken sich über unzählige Dateien und über Event-betriebene Prozessgrenzen.

Ja das ist halt das Problem von so eventgesteuerten Systemen. Am Ende ist über irgendwelche Pfade irgendwie immer alles von allem abhängig und man weiß eigentlich nichtmehr wo GUI aufhört und Logik anfängt. Darum bin ich kein besonderer Fan davon...

Wenn du sowas willst, dann wäre .NET oder Java vermutlich die besserere Welt für dich, dort hast du zumindest auch einen Garbage Collector der die ganzen Probleme schön vor dir versteckt sodass du sie nicht ständig sehen musst.

Na ich arbeite ja auch mit echten Membern wo es geht. Änderungen am Modell finden nicht im View statt etc.
Aber was der Benutzer mit Dokumenten macht, ist nunmal dynamisch. Das kann man auch durch tollste C++-Kunst nicht statisch machen. GUI-Anwendungen für dynamische Inhalte sind nunmal vom Prinzip her ne ziemlich verwobene/komplexe Sache. Klar kann man sich bemühen, klare Grenzen zu ziehen, aber irgendwo ist da auch ein Ende erreicht. Zumindest kam ich gedanklich immer zu diesem Ergebnis, als ich mich mal wieder darüber aufregte, warum das so sein muss. Ich kämpfe jetzt zu jeder Zeit um klaren Code, aber stecke nicht mehr den Kopf in den Sand, wenn es einfach aus meiner Sicht nicht mehr schöner geht. Ich finde es dann nur unfair, wenn man dann hier mit Simpelbeispielen zurechtgewiesen wird, als würde man sich keine Gedanken machen.

cooky451

Wenn du das mit den Dokumenten und wie die Serverobjekte damit zusammenhängen genauer erklären würdest, könnte dir vielleicht auch jemand eine bessere Idee liefern.

Ich möchte das ja gar nicht erklären, das würde für diesen Zweck wirklich zu weit führen. Ich wollte nur einige Worte zur Rechtfertigung dazu verlieren, dass ich eine solche Debug-Möglichkeit für sinnvoll halte, nachdem mir eine Grundsatzdiskussion während eines ganz anderen Themas aufgezwungen wurde. Ich hatte für mein ursprüngliches Anliegen genügend Kontext geliefert, der Sinn dahinter wurde dann mit Simpelbeispielen ins "Lächerliche" gezogen.

Vielleicht würde mir für zukünftige Projekte noch ein Hinweis helfen, welche Alternativen es für GUI-Projekte gibt, die nicht ereignisbasiert funktionieren Oder eine bessere Alternative zu einer lockeren Interpretation von MVC (Ich könnte mir da manchmal die Haare raufen, dass man eben nicht immer alle Daten so einfach zur Verfügung hätte, wie man sie beim rumfrickeln gerne hätte).

Aber das ist ja eine ganz andere Diskussion, die ich beizeiten mal unter einem anderen Thread eröffnen sollte.

Ich wünsch' euch was!

nurf

Falls das Ursprungsproblem noch existiert hätte ich einen Lösungsvorschlag anzubieten. Da man dafür aber etwas ausholen muss, mache ich das OnDemand.

Bei Interesse bitte nochmal in Kürze die Requirements posten. Beschreibungen wie Mischung von "weak_ptr, unique_ptr" ist nicht Zielführend.

Ich kann jetzt Deinem Ton nicht deutlich entnehmen, ob Dein Angebot konstruktiv oder sarkastisch ist.

Das Anliegen war folgendes:
Ein Paar aus Smart-Pointer-Klassen bei dem eine Klasse den Besitz der fraglichen dynamisch erzeugten Ressource darstellt, inklusive der Verwaltung der Lebenszeit und die andere Klasse einer Erlaubnis zur Verwendung inklusive der Möglichkeit, diesem die Rechte wieder zu entziehen, so dass ein Halter der vormaligen Erlaubnis diesen Entzug feststellen kann.

Diese Klassen sollen nicht dazu verwendet werden, ein Softwaredesign darauf aufzubauen, sondern zuverlässig einen Fehler in der Implementierung aufzudecken, an stellen, an denen mein treuer Debugger zuvor gescheitert ist.

dot

Mit anderen Worten: Du willst eine Referenz auch den unique_ptr?

Mir ist nicht ganz klar wie genau du damit Fehler finden willst. Ich seh nur wie du damit neue Fehler erzeugen kannst die ansonsten gar nicht möglich wären...

Nein, keine Referenz auf den Smartpointer mit fraglichem Namen. Der besitzanzeigende Zeiger wird ja irgendwann mal zerstört und zerstört die von ihm verwaltete Ressource gleich mit. Dass dieses Ereignis stattgefunden hat, während noch andere Smartpointer von abweichendem Typ auf die fragliche Ressource verweisen, das sollen letztere zuverlässig herausfinden können, ohne "undefined behaviour" hervorzurufen. Es soll letzteren Zeigern aber nicht möglich sein, Einfluss auf die Lebenszeit zu nehmen.

dot

Aber das findest du doch sowieso mit jedem Debugger heraus, warum dafür den Code unnötig kompliziert machen!?

Wie ich bereits geschrieben habe, hatte ich Fälle, bei denen es für meinen beschränkten Geist ein Akt war, die genaue Stelle des Fehlers aufzufinden, weil der Fehler ja zur Zeit der Zerstörung der Ressource stattfindet und nicht zur Zeit des Zugriffs auf die Ressource irgendwann danach, bei dem nichtmal zuverlässig sofort eine Ausnahme geworfen wird.

dot

Dann suchst du wohl sowas: http://msdn.microsoft.com/en-us/library/ys6cfhhh!?

Ethon

Eher soetwas: http://valgrind.org/
Aber für Winkrücke gibts wohl leider nichts in die Richtung, denke ich.

dot

Also ich bin kein Linux Experte, aber ich bezweifle dass valgrind bei diesem konkreten Problem viel helfen kann. Es geht nicht darum, memory leaks zu finden, oder rauszufinden wo ein kaputter Block allokiert wurde (das geht mit dem CRT Heap natürlich auch alles).

nurf

Decimad schrieb:

Das Anliegen war folgendes:
Ein Paar aus Smart-Pointer-Klassen bei dem eine Klasse den Besitz der fraglichen dynamisch erzeugten Ressource darstellt, inklusive der Verwaltung der Lebenszeit und die andere Klasse einer Erlaubnis zur Verwendung inklusive der Möglichkeit, diesem die Rechte wieder zu entziehen, so dass ein Halter der vormaligen Erlaubnis diesen Entzug feststellen kann.

Mir klingt das eher nach einer CRTP-Proxy-Klasse die sich wie ein Pointer verhält und wo beispielsweise der operator::-> überladen ist.
Je nach Kontext sagt man dazu auch Handle.

Falls Ownership besteht hast du quasi ein rwHandle, falls du das Ownership nicht hast, eben nur roHandle.

dot

Und wie findest du mit deinem Handle raus ob das referenzierte Objekt noch existiert?