Verständnis "const" pointer



  • @spiri

    Das war nicht die Frage, bzw. willst du jetzt vector durch list ersetzen und dann wäre das Beispiel von DocShoe okay für dich?



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

    @spiri

    Das war nicht die Frage, bzw. willst du jetzt vector durch list ersetzen und dann wäre das Beispiel von DocShoe okay für dich?

    Ja 🙂



  • z.T. spiri kann ich nur sagen: Die Funktion zum Blocken von Benutzern ist für mich der grösste Mehrwert der neuen Forumssoftware. Denn wenn ich den Rotz den manche Trolle (absichtliche oder unabsichtliche) hier so ablassen lesen muss, dann kann ich nicht anders als mich zu ärgern. So blocke ich jetzt die diversen Kandidaten einfach und hab meine Ruhe. (Und nein, ich hab hier nicht zig User geblockt, im Moment sind es genau zwei.)



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

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

    Referenz worauf denn überhaupt?

    Nicht worauf. Sondern statt einem konstanten Pointer.

    ?? Bei einer Referenz stellt sich immer die Frage des "worauf". Wenn wir von Referenzen reden, dann reden wir immer davon, dass das Objekt irgendwo "wohnt" und wir uns eine Referenz auf dieses Objekt beschaffen.

    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.



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

    Bei einer Referenz stellt sich immer die Frage des "worauf".

    Was für ein Quatsch. Eine Referenz nimmst du und zeigt ein Leben lang auf das selbe Objekt. Worauf?

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

    Mit T* ( oder artverwandten Dingen ) muss dieser Wohnort nicht existieren

    Ein Zeiger kann auch null sein. Da muss man schon wissen worauf der zeigt.

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

    weil wir mit der Übernahme des Zeigers auf das Objekt aus der Factory-Funktion auch das Ownership übernehmen

    So ein Quatsch



  • Mittlerweile stimme ich HustBaer zu: du bist wirklich ein Troll, aber ich hab es wenigstens versucht.

    Wenn dich deine Factory-Funktion mit Referenz glücklich macht, dann mach das halt so... Aber wenn irgendwie alle anderen anderer Meinung sind, würde mich das zumindest zum Nachdenken anregen.



  • Das war kein Trolling 🙂



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



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



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



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



  • @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 hier gehts nicht um delete &ref sondern um T* const vs. T&.



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



  • @It0101

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



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



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


Anmelden zum Antworten