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.

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



  • @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.



  • @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.



  • 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.



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

    Ein konstanter Pointer [...]

    Mhm. Zeig mal.



  • @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.



  • @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?



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

    Kannst du dir dein Beispiel nicht selbst zusammenschustern?

    Nein.



  • Pech gehabt.



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



  • @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.



  • @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.



  • @spiri lol. top-level const ... Aber ich find' auch deine persönlichen Angriffe immer wieder sehr amüsant. Besonders zu Weihnachten. Du Arschloch.



  • @Swordfish Na heul doch



  • @spiri Warum? Weil du ein dahergelaufenes Arschloch im Internet bist? Du überschätzt dich.



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

    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.

    Wieso eine Klasse pro NUMA-Knoten? Spätestens mit den PMR Allokatoren sollte das doch unnötig sein. Und auch davor funktionieren Stateful-Allokatoren, wenn sich der State auf z.B. einen shared_ptr<MyMemoryPool>, shared_ptr<NumaRegion> o.Ä. beschränkt und entsprechend mitkopiert wird.


Anmelden zum Antworten