Verständnis "const" pointer



  • @SoIntMan

    Du veränderst nicht die Adresse des Objektes, sondern den Inhalt der Zeigervariablen, die auf das Objekt zeigt. Das ist dem eigentlichen Objekt total schnuppe, das behält seine Adresse. Wenn du deinen Namen auf einen Zettel schreibst, später durchstreichst und durch einen neuen Namen ersetzt behältst du ja auch deinen Namen. Nur aufm Zettel steht halt was anderes.



  • @DocShoe und @manni66 AHHHH.. click.. ja ok , das war ein Griff ins Klo:) Jetzt raff ich das, vielen dank;)



  • Warum gibst du nicht einfach eine Referenz zurück und speicherst den Pointer.



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

    Warum gibst du nicht einfach eine Referenz zurück und speicherst den Pointer.

    Weil das ganz ganz furchtbarer Stil wäre?



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

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

    Warum gibst du nicht einfach eine Referenz zurück und speicherst den Pointer.

    Weil das ganz ganz furchtbarer Stil wäre?

    Weil man im C++ eine Referenz statt einem konstanten Pointer nimmt.



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

    Weil man im C++ eine Referenz statt einem konstanten Pointer nimmt.

    Als Rückgabetyp? Nein, ganz sicher nicht. Und schon dreimal nicht bei Factory-Funktionen.



  • Doch als Rückgabetyp. Dann hast du einen konstanten Pointer den du nicht mehr umbiegen kannst. Und brauchst nicht mehr mit dem Dereferenzierungsoperator zu hantieren.



  • Das führt aber zu Problemen, wenn du
    auto xy = getSomething();
    schreibst. Und schwupps hast du eine Kopie. Const ref also nur in Zusammenhang mit fehlendem Kopierkonstruktor.

    Aber noch viel wichtiger: wie lange lebt denn so ein Objekt? Und wer gibt es frei? delete &referenz; ist Blödsinn.

    Die Factory sollte doch wohl besser einen std::unique_ptr<Base> zurückgeben?



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

    Das führt aber zu Problemen, wenn du
    auto xy = getSomething();
    schreibst.

    Dann schreibt man halt auto&. Man soll wissen ob man eine Referenz oder eine Kopie will. Ich schreibe auch immer auto*, weil man dann noch wenigstens erkennt, dass man einen Pointer bekommt.



  • Dieser Beitrag wurde gelöscht!


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

    Doch als Rückgabetyp.

    Nein. Referenzen zurückzugeben ist grundsätzlich schon fragwürdig, und wo es doch (aus mehr oder weniger gutem Grund) gemacht wird, heisst es: die Referenz die du da bekommst verweist auf ein Objekt das hoffentlich lange genug leben wird für das was du damit vor hast, du musst es aber nicht wegräumen, da kümmert sich dann irgendwer anderer drum - irgendwann mal. (Wobei eben genau diese Unklarheit was die genaue Lebenszeit betrifft der Grund ist warum ich das Zurückgeben von Referenzen für fragwürdig halte.)

    Du kannst jetzt anderer Meinung sein, aber das ist der de-Facto Standard was Funktionen die Referenzen zurückgeben angeht. Dass man es technisch betrachtet anders machen kann ist klar. Man macht es aber einfach nicht. Vielleicht solltest du mal das hier lesen: https://en.wikipedia.org/wiki/Principle_of_least_astonishment

    Dann hast du einen konstanten Pointer den du nicht mehr umbiegen kannst.

    Nein. Was "man hat" kommt drauf an was man mit dem Returnwert macht. Man kann immer noch schreiben

    T* p = &(theCrazyFactoryFunction());
    

    Und hätte dann das selbe "Problem" - wobei ich es halt nicht als Problem ansehe.

    Umgekehrt kann man auch jederzeit

    T* const p = theNotSoCrazyFactoryFunction();
    

    schreiben.

    Und brauchst nicht mehr mit dem Dereferenzierungsoperator zu hantieren.

    Was ja wohl vollkommen wurscht ist.



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

    Die Factory sollte doch wohl besser einen std::unique_ptr<Base> zurückgeben?

    Genau! Das wäre vermutlich die beste Lösung, da es drei interessante Dinge kommuniziert

    • Es wird Ownership transferiert
    • Der korrekte Weg das Objekt zu löschen ist das normale delete
    • Es handelt sich um ein einzelnes Objekt und kein Array

    Und natürlich vermeidet es Fehler durch "Vergessen" von delete o.Ä.



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

    Nein. Referenzen zurückzugeben ist grundsätzlich schon fragwürdig, und wo es doch (aus mehr oder weniger gutem Grund) gemacht wird, heisst es: die Referenz die du da bekommst verweist auf ein Objekt das hoffentlich lange genug leben wird für das was du damit vor hast, du musst es aber nicht wegräumen, da kümmert sich dann irgendwer anderer drum - irgendwann mal. (Wobei eben genau diese Unklarheit was die genaue Lebenszeit betrifft der Grund ist warum ich das Zurückgeben von Referenzen für fragwürdig halte.)

    Wenn du einen nackten Pointer zurückgibst kannst du dir auch nicht sicher sein, ob dieser noch gültig ist. Und ich finde nicht dass man immer die Lebenszeit beachten muss. Man kann den Code auch so entwerfen, dass das einfach nicht der Fall sein wird.

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

    Nein. Was "man hat" kommt drauf an was man mit dem Returnwert macht. Man kann immer noch schreiben
    T* p = &(theCrazyFactoryFunction());

    Tu das.

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

    Und brauchst nicht mehr mit dem Dereferenzierungsoperator zu hantieren.

    Was ja wohl vollkommen wurscht ist.

    Was hässlich ist und du dir sparen kannst wenn du keinen Pointer brauchst.



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

    Du kannst jetzt anderer Meinung sein, aber das ist der de-Facto Standard was Funktionen die Referenzen zurückgeben angeht. Dass man es technisch betrachtet anders machen kann ist klar. Man macht es aber einfach nicht. Vielleicht solltest du mal das hier lesen: https://en.wikipedia.org/wiki/Principle_of_least_astonishment

    Als Programmierer muss man auch wissen was man tut. Es warten immer Überraschungen auf jemanden. Aber neuerdings auto dahinzuklatschen und nicht zu wissen, um welchen Typ es sich im entferntesten handelt und ob das Ding kopiert wird oder nicht zeugt nur von Inkompetenz.



  • Dieser Beitrag wurde gelöscht!


  • Dieser Beitrag wurde gelöscht!


  • @spiri Ich geb's auf. Tu was du willst.



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

    Doch als Rückgabetyp. Dann hast du einen konstanten Pointer den du nicht mehr umbiegen kannst. Und brauchst nicht mehr mit dem Dereferenzierungsoperator zu hantieren.

    Hmm sehe ich anders. Klar gönne ich mir auch gern den Luxus einer (const-)Referenz, aber gerade bei einer Factory-Funktion wird eigentlich suggeriert, dass man das Objekt selber in die Hand bekommt, weil man es dort gewissermaßen "produziert".

    Ich vermute, du willst auf folgendes hinaus: du hast irgendwo eine Art "ObjectRegistry" und dort wird das Objekt noch innerhalb der Factory-Funktion registriert.
    Aber selbst in dem Fall sehe ich da noch keine Referenz sondern eher einen shared_ptr. Ohne Registrierung dann den unique_ptr. Weil es eben trotzdem eine Factory ist und die sollte doch bitte das Objekt "zur freien Verfügung" zurückliefern. Die Smartpointer haben den Charme, dass sie den sauberen Umgang mit der "Lebenszeit" des Objekts garantieren.

    PS: Sportfreunde, es gibt keinen Grund einander anzupöbeln, nur weil man unterschiedliche Ansichten vertritt.



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

    Hmm sehe ich anders. Klar gönne ich mir auch gern den Luxus einer (const-)Referenz, aber gerade bei einer Factory-Funktion wird eigentlich suggeriert, dass man das Objekt selber in die Hand bekommt, weil man es dort gewissermaßen "produziert".

    Ja, und? Was hindert dich daran das Ding trotzdem als Referenz zurückzugeben?



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

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

    Hmm sehe ich anders. Klar gönne ich mir auch gern den Luxus einer (const-)Referenz, aber gerade bei einer Factory-Funktion wird eigentlich suggeriert, dass man das Objekt selber in die Hand bekommt, weil man es dort gewissermaßen "produziert".

    Ja, und? Was hindert dich daran das Ding trotzdem als Referenz zurückzugeben?

    Wenn ich eine Referenz zurück bekomme, bedeutet das, dass ich eigentlich gar nicht (alleiniger) Owner von dem Teil bin. Und bei einer Factory würde mich das nerven.


Anmelden zum Antworten