Verständnis "const" pointer

[It0101]

@john-0 sagte in Verständnis "const" pointer:

@It0101 sagte in Verständnis "const" pointer:

Mit T* ( oder artverwandten Dingen ) muss dieser Wohnort nicht existieren, weil wir mit der Übernahme des Zeigers auf das Objekt aus der Factory-Funktion auch das Ownership übernehmen. Im Gegensatz zur Referenz.

Das ist aber nur eine lang gepflegte Tradition bei Zeigern auf Objekten, und es ermöglichte schon immer den Missbrauch, weil man dem Zeiger nicht ansieht, ob der Besitzt auch übertragen wird. Aus diesem Grund wurden ja die Smartpointer entwickelt: shared_ptr, unique_ptr (dieser funktioniert erst seit C++11 so richtig wegen des move) und weak_ptr, die exakt anzeigen wie es mit dem Besitzt aussieht, und den Besitzt automatisch steuern. Bei neu zu schreibenden Code drängen sich die Smartpointer deshalb auf.

Das war es auch was ich mit "artverwandten Dingen" meinte.

[hustbaer]

@john 0
Hast du die Beiträge davor gelesen?
Verstehst du worum es in der Diskussion aktuell geht?

Und meinst du wirklich eine Referenz zurückzugeben wo der Aufrufer das Objekt dann mittels delete &ref; löschen muss wäre besser (oder auch nur ansatzweise "OK")?

[*john 0]

@hustbaer sagte in Verständnis "const" pointer:

@john 0
Hast du die Beiträge davor gelesen?
Verstehst du worum es in der Diskussion aktuell geht?

Meiner lieber Hustbaer,
ich habe den kompletten Thread durchgelesen, ich habe ich verstanden, ich weiß was eine Factory bzw. Factory Method ist, ich weiß wie man sie in C, C++ und diversen anderen Sprachen korrekt umsetzt.

Und meinst du wirklich eine Referenz zurückzugeben wo der Aufrufer das Objekt dann mittels delete &ref; löschen muss wäre besser (oder auch nur ansatzweise "OK")?

Habe ich das irgendwo behauptet?

[Swordfish]

@hustbaer sagte in Verständnis "const" pointer:

(Und nein, ich hab hier nicht zig User geblockt, im Moment sind es genau zwei.)

Bitte, husti, sag mir, daß ich einer davon bin. Das wäre eine große Ehre

[Ein ehemaliger Benutzer]

Nein hier gehts nicht um delete &ref sondern um T* const vs. T&.

[It0101]

@spiri sagte in Verständnis "const" pointer:

Nein hier gehts nicht um delete &ref sondern um T* const vs. T&.

und du bist nachwievor der einzige, der die Referenzvariante gegenüber den Alternativen ( smartpointer und klassische Pointer ) für sinnvoll erachtet.

[Ein ehemaliger Benutzer]

@It0101

Wenn man sich nicht um den Ownership kümmern muss, ja.

[hustbaer]

@Swordfish sagte in Verständnis "const" pointer:

@hustbaer sagte in Verständnis "const" pointer:

(Und nein, ich hab hier nicht zig User geblockt, im Moment sind es genau zwei.)

Bitte, husti, sag mir, daß ich einer davon bin. Das wäre eine große Ehre

Nein, bist du nicht. Wenn du es wärst könnte ich es auch schwer bestätigen, da ich deinen Beitrag gar nicht gesehen hätte. Und wieso wäre das eine Ehre? Ich hatte nicht den Eindruck dass du mich nicht ausstehen kannst oder meine Beiträge grundsätzlich schlecht findest. Kann natürlich täuschen. Hm...

[hustbaer]

@john-0
Dann verstehe ich deinen Beitrag nicht ganz. Ich glaube es hat niemand hier bestritten dass die beste Möglichkeit ein Smart-Pointer wäre.

Mir kam halt vor dass du @spiri 's Vorschlag eine Referenz zurückzugeben irgendwie verteidigen wolltest. Aber vermutlich hab ich dich dann falsch verstanden?

[*john 0]

@hustbaer sagte in Verständnis "const" pointer:

@john-0
Dann verstehe ich deinen Beitrag nicht ganz. Ich glaube es hat niemand hier bestritten dass die beste Möglichkeit ein Smart-Pointer wäre.

Das Problem hier in Forum ist, dass es viele Beiträge der Etablierten gibt, die vor sprachlicher Ungenauigkeit nur so strotzen. Rein aus den Interface einer Factory (Method) lässt sich eben nicht ersehen, ob der Besitz auf den Aufrufer übergeht, wenn diese Funktion einen Zeiger zurück liefert! Ein Zeiger ist ein Zeiger und eben kein unique_ptr, shared_ptr oder weak_ptr. Das heißt es fehlt dadurch im Interface der Funktion eine wesentliche Information und es gibt eine andere Qualität des Interfaces. Das ist ein wesentlicher Unterschied. In der Regel werden Factories so realisiert, dass der Besitzt auf den Aufrufer übergeht, aber das kann man bei der Rückgabe eines Zeigers eben nicht am Interfaces ersehen, sondern man muss dazu die Dokumentation oder schlimmstenfalls den Sourcecode der Factory lesen.

Mir kam halt vor dass du @spiri 's Vorschlag eine Referenz zurückzugeben irgendwie verteidigen wolltest. Aber vermutlich hab ich dich dann falsch verstanden?

Ja, in der Tat!

Allerdings wurde im Thread von Dir geschrieben Funktionen sollten generell keine Referenzen zurückgeben. Eine logische Konsequenz wäre: Container wie std::vector oder std::map wären unmöglich, weil der operator[] keine Referenzen zurück liefern dürfte. Und das wird wohl kein erfahrener C++ Nutzer behaupten wollen?

Gerade gegenüber Anfängern sollte man daher sehr viel mehr auf die korrekte Formulierung achten, weil best practices sind gut und schön, aber sie haben oftmals ihre Grenzen, und sollten deshalb nicht zum Dogma erhoben werden. Ich denke da konkret an daran, weshalb man auf NUMA-Systemen mit std::vector und den üblichen Smart-Pointer-Regeln nicht weit kommt. Eigene Allocatoren zu schreiben ist wegen der limitierten Schnittstellen derselben ein Problem. Ich habe das heute testweise für einen speziellen NUMA-Allokator gemacht, und das Ergebnis ist nicht sonderlich befriedigend, da man pro NUMA-Knoten im System eine Allokator-Klasse erzeugen muss. Man sollte dabei bedenken, dass es am Markt bereits Systeme mit hunderten von NUMA-Knoten gab, und aktuell Softwarelösungen fürs verclustern existieren, die dann auf dem logischen System tausende NUMA-Knoten erzeugen.

[Swordfish]

@john-0 sagte in Verständnis "const" pointer:

Allerdings wurde im Thread von Dir geschrieben Funktionen sollten generell keine Referenzen zurückgeben. Eine logische Konsequenz wäre: Container wie std::vector oder std::map wären unmöglich, weil der operator[] keine Referenzen zurück liefern dürfte.

@hustbaer hat sich in seinem Beitrag sehr differenziert und kaum missverständlich ausgedrückt. NSITOJS.

[Ein ehemaliger Benutzer]

Grundsätzlich kommt es wohl darauf an, wie man die Lebenszeit seiner Objekte behandelt. Das kann unterschiedlich sein.

Aber (auch bei ner Factory-Funktion) würde ich bei T* const vs. T& die Referenz-Variante nehmen. Eine Referenz ist wie ein konstanter Pointer. Das soll man bevorzugen. Hier muss man beachten, dass die Lebenszeit des Objekts bereits garantiert ist und man einfach auf dem Objekt losarbeiten kann.

@DocShoe's Beispiel ist für mich ganz ok, bis auf std::vector. Bei jedem insert/remove von diesem Vektor erzeugt eine Reallokation des gesamten Inhalts, was die zuvor ergatterten Pointer kaputt man. In dem Fall würde ich dann doch lieber std::list<> nehmen, weil mir das Ding garantiert, dass eine gesamte Reallokation nicht vorkommt. Die Lebensdauer des Objekts wird in die Liste geschoben und man bekommt eine frische Referenz des Objekts. Das Objekt lebt.

Ein konstanter Pointer hingegen ginge in dem Fall auch, ist halt nur unschön wegen den Access-Operatoren und bei einem Pointer ist es üblich, dass der auch mal null sein kann. Obwohl man das natürlich auch beeinflussen kann.

Wie und wann man dieses (in der Tat lebende in der Liste existierende Objekt) nun wirklich zerstören will, hängt eben ganz vom Kontext ab. Manchmal reicht auch nur ein list.clear() und die Sache hat sich erledigt.

[Swordfish]

@spiri sagte in Verständnis "const" pointer:

Ein konstanter Pointer [...]

Mhm. Zeig mal.

[hustbaer]

@john-0 sagte in Verständnis "const" pointer:

Das Problem hier in Forum ist, dass es viele Beiträge der Etablierten gibt, die vor sprachlicher Ungenauigkeit nur so strotzen.

Da stimme ich grundsätzlich zu.

Ein Zeiger ist ein Zeiger und eben kein unique_ptr,

Ja, hab ich ja nun schon mehrfach geschrieben dass wir (=die meisten die hier diskutieren) schon sehr bald zu dem konsens gekommen sind dass ein Smart-Pointer besser wäre. Mir ging es primär aber mal darum klarzustellen dass das Zurückgeben einer Referenz bei einer klassischen Factory-Funktion (=wenn Ownership übergeben wird) eine ganz schlechte Idee ist.

Allerdings wurde im Thread von Dir geschrieben Funktionen sollten generell keine Referenzen zurückgeben.

Nö, hab ich nicht. Ich hab geschrieben "fragwürdig", und "fragwürdig" heisst für mich dass man es eben hinterfragen sollte bevor man es macht. Weiters hab ich geschrieben "und wo es doch (aus mehr oder weniger gutem Grund) gemacht wird" - was impliziert dass es sehrwohl gute Gründe gibt. Wenn ich mich auch in anderen Beiträgen sicher öfters schwammig/ungenau ausdrücke, so meine ich doch, dass das klar genug gewesen sein sollte.

Deine Antwort macht auf mich jetzt etwas den Eindruck dass du die Beiträge anderer hier mindestens so ungenau liest, wie du meinst dass manche geschrieben sind. Und dann hineininterpretierst was du gerade willst.

ps: Ich finde auch den Begriff "factory function" komisch und zumindest fragwürdig wenn nicht Ownership übertragen wird. Das ist mir noch nie begegnet. Natürlich gibt es Funktionen die Objekte "on demand" erzeugen, und einen Zeiger/eine Referenz auf sie zurückliefern. Die nennt man dann aber normalerweise anders. Also ich würde z.B. nie auf die Idee kommen einen Service-Locator als Factory zu bezeichnen.

[Ein ehemaliger Benutzer]

@hustbaer sagte in Verständnis "const" pointer:

@john-0 sagte in Verständnis "const" pointer:

Das Problem hier in Forum ist, dass es viele Beiträge der Etablierten gibt, die vor sprachlicher Ungenauigkeit nur so strotzen.

Da stimme ich grundsätzlich zu.

Und das finde ich Scheiße dass ihr so denkt. Hier soll es nicht um die perfekteste Genauigkeit gehen, sondern darum jemanden zu helfen, damit er schlussendlich dann doch besser weiter weiß. Dieses ganze Rumgefappe von wer mit dem größten Penis protzt geht mir ziemlich aufn Sack. Wenn es hier darum ginge, dass die User immer die perfekteste Antwort bekommen müssten, dann würde ziemlich immer @SeppJ und @camper die perfekteste Antwort liefern und keiner bräuchte sich mehr zu melden.

@Swordfish sagte in Verständnis "const" pointer:

Mhm. Zeig mal.

Kannst du dir dein Beispiel nicht selbst zusammenschustern?

[Swordfish]

@spiri sagte in Verständnis "const" pointer:

Kannst du dir dein Beispiel nicht selbst zusammenschustern?

Nein.

[Ein ehemaliger Benutzer]

Pech gehabt.

[Swordfish]

@spiri Ja, dachte ich mir. Vielleicht kommst du irgendwann auch selbst drauf, warum "konstanter Pointer" bullshit ist.

[Ein ehemaliger Benutzer]

@Swordfish sagte in Verständnis "const" pointer:

@spiri Ja, dachte ich mir. Vielleicht kommst du irgendwann auch selbst drauf, warum "konstanter Pointer" bullshit ist.

Vielleicht kommst du auch einmal selber drauf dass du eigentlich nur ein trauriger und bemitleidenswerter Typ bist.

[Mechanics]

@hustbaer sagte in Verständnis "const" pointer:

Ich finde auch den Begriff "factory function" komisch und zumindest fragwürdig wenn nicht Ownership übertragen wird.

Hab ich schon mal gesehen. War irgendso ein System mit abstrakten Factories, und manche haben sowas wie singletons bzw. gecachte Objekte zurückgegeben. Waren aber auch alles smart pointer.