Ist es sicher den this-Pointer zu speichern?

Columbo

Ja, hast natürlich Recht.

[unique.ptr]/5 schrieb:

The template parameter T of unique_ptr may be an incomplete type.

Ich hatte flugs in der nachvollziehbaren Annahme geantwortet dass camper keine Flüchtigkeitsfehler mache. (Außerdem war ich auf dem Handy und konnte nicht den Standard checken. :p )

Warum wäre dass dann anders als bei smart_ptr ?

Weil shared_ptr etwas anderes ist als unique_ptr . Ich nehme mal an es müssen einige interne Deklarationen instantiiert werden die die Vollständigkeit von T voraussetzen.

Columbo

... Ich wusste ich hätt's prüfen sollen.

[util.smartptr.shared]/2 schrieb:

The template parameter T of shared_ptr may be an incomplete type.

Ethon

baumstruktur schrieb:

Ethon schrieb:

Ich hatte sehr wohl schon den Anwendungsfall Unterbäume herumreichen und speichern zu wollen und habe da den Baum von unique_ptr auf shared_ptr umgestellt.

Und alle Unterbäume können den Baum überleben?
Dann hast du den Baum hoffentlich immutable gemacht.

In meinem Fall ging es um einen AST, der interpretiert wurde. Unterbäume wurden durch Opimierungen modifiziert, dass diese nur 1x für beliebig viele Kopien durchgeführt wurden war sogar erwünscht.

camper

Arcoth schrieb:

Ja, hast natürlich Recht.

[unique.ptr]/5 schrieb:

The template parameter T of unique_ptr may be an incomplete type.

Ich hatte flugs in der nachvollziehbaren Annahme geantwortet dass camper keine Flüchtigkeitsfehler mache. (Außerdem war ich auf dem Handy und konnte nicht den Standard checken. :p )

Huh, keine Ahnung wie miur das entgehen konnte... aber wäre nicht das erste mal, dass ich Unfug erzähle und wird auch nicht das letzte mal gewesen sein. Also schön wachsam bleiben

Nathan

camper schrieb:

Arcoth schrieb:

Ja, hast natürlich Recht.

[unique.ptr]/5 schrieb:

The template parameter T of unique_ptr may be an incomplete type.

Ich hatte flugs in der nachvollziehbaren Annahme geantwortet dass camper keine Flüchtigkeitsfehler mache. (Außerdem war ich auf dem Handy und konnte nicht den Standard checken. :p )

Huh, keine Ahnung wie miur das entgehen konnte... aber wäre nicht das erste mal, dass ich Unfug erzähle und wird auch nicht das letzte mal gewesen sein. Also schön wachsam bleiben

Kennt ihr beide nicht das neue "idiomatische" Pimpl Idiom?

class foo
{
   struct impl;
   std::unique_ptr<impl> pimpl;
public:
   ~foo(); // destruktor muss dann natürlich in cpp definiert werden...
};

Nathan schrieb:

Kennt ihr beide nicht das neue "idiomatische" Pimpl Idiom?

class foo
{
   struct impl;
   std::unique_ptr<impl> pimpl;
public:
   ~foo(); // destruktor muss dann natürlich in cpp definiert werden...
};

Jetzt nur noch die beiden Kopierkonstruktoren und den einen Zuweisungsoperator definieren.

Nathan

plimpl schrieb:

Nathan schrieb:
Kennt ihr beide nicht das neue "idiomatische" Pimpl Idiom?
class foo
{
   struct impl;
   std::unique_ptr<impl> pimpl;
public:
   ~foo(); // destruktor muss dann natürlich in cpp definiert werden...
};
Jetzt nur noch die beiden Kopierkonstruktoren und den einen Zuweisungsoperator definieren.

Jup.

Mechanics

Und das reicht immer noch nicht, wenn man die Klasse aus einer Dll exportieren will, was bei einer Klasse mit Pimpl nicht unwahrscheinlich ist.

camper

Nathan schrieb:

Kennt ihr beide nicht das neue "idiomatische" Pimpl Idiom?

class foo
{
   struct impl;
   std::unique_ptr<impl> pimpl;
public:
   ~foo(); // destruktor muss dann natürlich in cpp definiert werden...
};

Macht in der Praxis kaum jemand so. Da in aller Regel sowieso noch Kopieren und Zuweisung definiert wird, ist der Nutzen gering.
(Die Verwendung von unique_ptr erspart copy-ctor und -Opeerator sofern die Semantik stimmt; aber diese Verletzung der Regel der Drei bedarf im Prinzip schon wieder eines Kommentares der die Ersparnis negiert).

Und früher zu auto_ptr-Zeiten war das eben undefiniert.

Nathan

camper schrieb:

Macht in der Praxis kaum jemand so. Da in aller Regel sowieso noch Kopieren und Zuweisung definiert wird, ist der Nutzen gering.
(Die Verwendung von unique_ptr erspart copy-ctor und -Opeerator sofern die Semantik stimmt; aber diese Verletzung der Regel der Drei bedarf im Prinzip schon wieder eines Kommentares der die Ersparnis negiert).

Habe ich nicht abgestritten, mag PIMPL generell nicht so.
Daher weiß ich aber, dass unique_ptr mit unvollständigen Typen klar kommt.

Finnegan

Nathan schrieb:

Habe ich nicht abgestritten, mag PIMPL generell nicht so.

Falls du mal in die Verlegenheit kommen solltest, solche Namespace-Seuchen wie "windows.h" einbinden zu müssen, wirst du PIMPL mit anderen Augen sehen
(Gilt auch für diverse andere Bibliotheken, die den globalen Namensraum über Gebühr befüllen).

Finnegan

Columbo

Nathan schrieb:

Daher weiß ich aber, dass unique_ptr mit unvollständigen Typen klar kommt.

Der einzige Grund aus dem du uns das mitteilen könntest ist um zu beweisen dass du es vorher wusstest.