Allerdings frage ich mich schon, ob es nicht irgendwo eine Mischung aus unique_ptr und shared_ptr gibt ("uniquely_owned_ptr" oder sowas) , mit dem Unterschied, dass man deren weak_ptr nicht zu einem vollwertigen Pointer zurück-"upgraden" kann.

Hoffentlich habe ich mich verständlich ausgedrückt :).

Viele Grüße,
deci

class A
{
  std::unique_ptr<int> p_;
public:
  A() {...}
  int* get() { return p_.get(); }
};

int main()
{
  A a;
  {
    int* p = a.get();
  } // Hier willst du benachrichtigt werden, da p aus dem Scope geht?
}

Derzeit schicke ich einfach blanke Zeiger zurück und es funktioniert auch alles, keiner der Clients lebt länger als die "Server"-Objekte, so ist die Software aufgebaut.

Genau so soll es auch gemacht werden. Das ist die empfohlene Vorgehensweise. Kein Grund es anders zu machen.

std::unique_ptr<T> p = ...

//...

some_checkable_ptr<T> c = p;

//p koennte nun sterben

if(c.lock()) //nur, wenn p noch gültig
{
   c->foo();
}

Ist aber ziemlich gefährlich. Außerdem würde der unique_ptr, damit das funktionieren kann, nicht mehr so schön simpel sein können.

Genau, da möchte ich beurteilen können, ob das Programm bei Dereferenzierung von p noch das tut, was es tun soll. Wenn man einen bösen Fehler einbaut, könnte ja an die gleiche Speicherposition ein anderes Objekt vom selben Typ erstellt worden sein, oder was gänzlich anderes, was dennoch erstmal nicht zu Access Violations und hinterher zu obskuren Fehlern führt.

Wenn die Lebenszeit der Objekte des Servers an die Lebenszeit des Servers gebunden sind, dann ist ein Nutzer selbst schuld, wenn er nachdem der Scope des Servers verlassen wurde noch irgendwelche Zeiger auf seine Objekte dereferenziert. Wenn das nicht der Fall ist, willst du keinen unique_ptr. (Da die Objekte dann ja offensichtlich nicht alleine dem Server gehören.)

Das erinnert mich an Qt's "guarded pointers". Die funktionieren aber nur, wenn man von einer bestimmten Klasse (QTObject) ableitet. Der QTObject Destruktor lässt dann irgendwie die entsprechenden QGuardedPtr-Instanzen auf 0 setzen.

Pointer sind üblicherweise unsigned.

Pointer sind weder signed noch unsigned. Es ist Ansichtssache, ob sich der Stack unter oder weit über NULL befindet. Dessen ungeachtet kann man aber auch vorzeichenlose Variablen auf -1 setzen; bei vorzeichenlosen Integern wird das Modulo 2^Breite verrechnet, also auf den maximal darstellbaren Wert des Datentyps umgemünzt. Das findet man auch recht häufig, beispielsweise im Standard in der Definition von std::basic_string:

static const size_type npos = -1;

Das ist genauso, wenn ich in meinem Haus die Fenster vergittere, damit ich nicht aus Versehen hinausfalle.

{
  Server s;
  los_gehts(s);
}

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

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.

PS: Ja, das Problem ist abgehackt.

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.

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.

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!