Ich weiß nämlich nicht wie ich ihn in meinem Fall implementieren soll.
Eine C-API gibt mir einen verkettete Liste zurück, in Form von:

struct Item
{
    int i;
    int j;
    Item* pNext;
};

Dafür hab ich jetzt einen Iterator geschrieben. Aber ich möchte es so haben das mir der Iterator nur ein Proxyobjekt zurückgibt und nicht einen Zeiger auf die rohe Struktur. Beim operator* geht das auch:

ItemProxy operator*() const
{
   return ItemProxy(pItem);
}

Im operator-> müsste ich ja einen Zeiger zurückgeben, aber ich kann ja ItemProxy nicht mit new anlegen da es sonst nie wieder freigeben wird.

Ist aber nur in Ausnahmefällen sinnvoll.

???
Was wenn man den Proxy, wie hier anscheineind erfolgt, nach dem Vorschlag der GoF implementiert?

Grüsse

*this

camper schrieb:

Ist aber nur in Ausnahmefällen sinnvoll.

???
Was wenn man den Proxy, wie hier anscheineind erfolgt, nach dem Vorschlag der GoF implementiert?

Grüsse

*this

an externe Kollektionen hatte ich dabei nicht gedacht. Sind wohl mehr als nur ein paar Ausnahmen. Aber bei Containern die vollständig im Speicher stehen, ist es eher selten nötig. Der Sinn eines Proxies für operator-> kann ja nur in irgendwelchen Seiteneffekten im Konstruktor oder Destruktor liegen - und wenn diese so wichtig sind, habe ich gewisse Zweifel, ob es gut ist, diese implizit herbeizuführen. Alexandrescu (glaub er wars) hatte das mal genutzt (hab vergessen wo) um mittels volatile-Überladung ein Interface zu schaffen, das theradsafe ist. Im Zweifel nehm ich die Bemerkung aber lieber zurück als mich darüber zu streiten