Ist es sicher den this-Pointer zu speichern?

happystudent

camper schrieb:

Wobei unique_ptr hier nur bedingt einsatzfähig ist.
In Bezug auf node::data ist nicht klar, wieso hier überhaupt Indirektion erforderlich ist, ein unique_ptr wäre allerdings möglich.

Das hab ich gemacht, weil ich einen Baum von abstrakten Objekten brauche, also was wie tree<my_abstract_object> .

camper schrieb:

node::children kann allerdings kein std::vector<std::unique_ptr<node>> sein ohne UB hevorzurufen.

Hä, warum dass?

camper schrieb:

Im Prinzip ist auch für node::children die doppelte Indirektion (1 Indirektion wird ja schon durch vector impliziert) überflüssig, mit ein bisschen Aufwand (wie z.B. hier) kann man diese ebenso vermeiden, und so ganz auf Zeiger (sowohl roh als auch smart) verzichten.

Aber da verwende ich doch auch shared_ptr ?

Columbo

Template-Argumente fuer Templates in der Standardbibliothek (smart pointer eingeschlossen) duerfen i.d.R. Keine unvollstaendigen Typen sein.

happystudent

Arcoth schrieb:

Template-Argumente an Templates in der Standardbibliothek (smart pointer eingeschlossen) duerfen i.d.R. nicht unvollstaendig sein.

Wie jetzt, hier wurde mir aber gesagt dass smart pointer hier eine Ausnahme sind. Wie soll man denn sonst unvollständige Typen mit smart pointern speichern und was stimmt jetzt hier? Oder gilt das jetzt nur für smart_ptr und nicht für unique_ptr ? Warum wäre dass dann anders als bei smart_ptr ?

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.