Pointer oder Referenzen bei Übergabeparameter?



  • chrische5 schrieb:

    ... weil ich bei Funktion, die ein Parameter ändert dann immer & davorschreiben muss und somit gearnt bin: Aha, die Funktion ändert den Parameter.

    Ich kann diesen Grund nicht nachvollziehen. Ich bin der Ansicht: Wenn man eine Funktion aufruft, dann sollte man sowieso unbedingt wissen, was sie tut. Und wenn man das weiß, dann weiß man auch, ob sie Parameter verändert. Diese Warnsymbol-Argumentation (gibt es ja auch in anderen Bereichen, z.B. diese Regel, SYMBOLISCHE_KONSTANTEN groß zu schreiben) kann ich daher generell nicht nachvollziehen.



  • chrische5 schrieb:

    Also ich mach es auch wie Volkard, weil ich bei Funktion, die ein Parameter ändert dann immer & davorschreiben muss und somit gearnt bin: Aha, die Funktion ändert den Parameter.

    Darum gibt es ja das kleine aber feine Schlüsselwort "const" 😉 Wenn ein "const" vor dem Parameter steht, wird dieser nicht verändert - kann man ja auch gar nicht.



  • Zu dem Beispiel mit der ungültigen Referenz
    Die gülitgkeit von Parametern wird bei Referenzen vom Aufrufer erledigt und bei einem Pointer Parameter von der Funktion.

    Nur so meine Faustregel



  • PointRef schrieb:

    volkard schrieb:

    bei const immer referenz.

    Wieso ist das so? In welchem Zusammenhang steht die Frage nach const oder nicht-const mit der Frage nach Referenz oder Pointer?

    ich hab keinen unterschied zwischen print(student)//by val und print(strudent)//by const ref.

    Zur Idee, dass Referenzen besser wären: Man muss sie zumindest nicht auf Gültigkeit (if (reference)) überprüfen.

    das halte ich für veraltet. zugriffe auf nullzeiger passieren nicht und dagegen prüfen ist zeitverschwendung.



  • templäd schrieb:

    und bei einem Pointer Parameter von der Funktion.

    wozu das denn? lass die kiste doch abschmieren, wenn du strlen(0) berechnen willst. und überhaupt, was sollte denn das ergebnis sein? -1? und was willste bei strcpy(0,"hallo") machen? nix? dann wir der nachste, der die 0 benutzt, das roblem haben. lass den rechner ruhig in die schutzverletzung laufen und gut ist's.



  • Meiner Meinung nach tritt das Problem ja nur bei Operator Überladung auf.
    Eine "gute" Funktion/Methode sollte nicht einen Übergabeparameter verändern dürfen. Ergebnisse sollten nur mit return zurückgegeben werden.



  • 1310-Logik schrieb:

    Meiner Meinung nach tritt das Problem ja nur bei Operator Überladung auf.

    bei operatoren ist aber wiederum sonnenklar,m ob zeiger oder referenz.

    Eine "gute" Funktion/Methode sollte nicht einen Übergabeparameter verändern dürfen. Ergebnisse sollten nur mit return zurückgegeben werden.

    jo. und zweimal im jahr findet sich ne unwichtige ausnahme.



  • Neku schrieb:

    chrische5 schrieb:

    Also ich mach es auch wie Volkard, weil ich bei Funktion, die ein Parameter ändert dann immer & davorschreiben muss und somit gearnt bin: Aha, die Funktion ändert den Parameter.

    Darum gibt es ja das kleine aber feine Schlüsselwort "const" 😉 Wenn ein "const" vor dem Parameter steht, wird dieser nicht verändert - kann man ja auch gar nicht.

    Wäre ich paranoid oder bösartig, könnte ich das const mit const_cast einfach wegcasten und fröhlich das Objekt verändern :p 😉



  • GPC schrieb:

    Neku schrieb:

    chrische5 schrieb:

    Also ich mach es auch wie Volkard, weil ich bei Funktion, die ein Parameter ändert dann immer & davorschreiben muss und somit gearnt bin: Aha, die Funktion ändert den Parameter.

    Darum gibt es ja das kleine aber feine Schlüsselwort "const" 😉 Wenn ein "const" vor dem Parameter steht, wird dieser nicht verändert - kann man ja auch gar nicht.

    Wäre ich paranoid oder bösartig, könnte ich das const mit const_cast einfach wegcasten und fröhlich das Objekt verändern :p 😉

    Wieso braucht eine Programmiersprache eigentlich ne "Kindersicherung"? Man sollte meinen, es seien Vernünftige Menschen am Werk.. :p 😉



  • Ich halt es so:

    Referenzen da wo geht,
    Pointer da wo man referenzen nicht nutzen kann.

    Faelle wo Referenzen nicht so geeignet sind:

    - wenn man nen explizieten nicht definiert / nicht gueltig Wert braucht ... (NULL Pointer)
    - Wenn ich extensiv caste. Geht zwar prinizipiell auch mit referenzen, aber gefuehlsmaessig nehm ich da doch lieber pointer. (denk mal haengt eher damit zusammen das man bei nem logischen cast gern mal nen ungueltigkeitswert haett, also eher siehe punkt 1)
    - referenzen kann man ned in standardcontainer pappen ... da muss man pointer nehmen ....

    Ciao ...



  • Wo ich keinen Weg mit Referenzen sehe: bei der Behandlung polymorpher Objekte



  • 1310-Logik schrieb:

    Eine "gute" Funktion/Methode sollte nicht einen Übergabeparameter verändern dürfen. Ergebnisse sollten nur mit return zurückgegeben werden.

    Das halte ich für nicht konsequent umsetzbar. Was machst Du, wenn eine Methode mehrere Parameter ändern muss?

    Ich halte es so, wie viele bereits gesagt haben:
    - wenn nichts geändert wird: const-Referenz
    - wenn nichts geändert wird, aber eine Referenz nicht geht, aus welchem Grund auch immer: const-Pointer auf const-Daten
    - wenn geändert wird: Referenz
    - wenn geändert wird, aber Referenz nicht geht, aus welchem Grund auch immer: Pointer (wobei da noch zu überlegen ist, ob der Pointer const deklariert wird und nur die Daten nicht const sind)

    Wobei ich alle Fälle schon einsetzen musste.

    1310-Logik schrieb:

    Wieso braucht eine Programmiersprache eigentlich ne "Kindersicherung"? Man sollte meinen, es seien Vernünftige Menschen am Werk..

    Ich sehe das const eher als eine Hilfestellung, die dem Benutzer einer Methode sagt, diese Parameter werden von der Funktion geändert und diese eben nicht. Umgehen kann man alles, auch an eine private-deklarierte Klassenvariable kommt man von außen heran, wenn man will.



  • Cosmixx schrieb:

    1310-Logik schrieb:

    Eine "gute" Funktion/Methode sollte nicht einen Übergabeparameter verändern dürfen. Ergebnisse sollten nur mit return zurückgegeben werden.

    Das halte ich für nicht konsequent umsetzbar. Was machst Du, wenn eine Methode mehrere Parameter ändern muss?

    Ein Tupel zurückgeben. Gut, in C++ ist das mit einer nicht sehr schönen Syntax verbunden. In anderen Sprachen (wohl hauptsächlich funktionalen) ist es aber gang und gäbe.



  • 1310-Logik schrieb:

    Wo ich keinen Weg mit Referenzen sehe: bei der Behandlung polymorpher Objekte

    😕

    Nochmal zur Erinnerung, zum Speichern sind Referenzen sowieso nicht gemacht.



  • .filmor schrieb:

    1310-Logik schrieb:

    Wo ich keinen Weg mit Referenzen sehe: bei der Behandlung polymorpher Objekte

    😕

    Nochmal zur Erinnerung, zum Speichern sind Referenzen sowieso nicht gemacht.

    Ich meinte zB beim Observer Pattern. Wie willst du da ne Referenz übergeben?

    virtual void update( Subject* subject )
    {
        Foo* foo = dynamic_cast< Foo* >( subject );  //Foo ist abgeleitet von Subject (Abstrakte Klasse)
        foo->doBar();
    }
    


  • Mit dem dynamic_cast setzt du dich ja auch eigentlich über das Konzept der Polymorphie hinweg, normale virtuelle Methoden funktionieren mit Referenzen ohne Probleme.

    Btw, so gehts auch mit Referenzen:

    virtual void update( Subject& subject )
    {
        Foo* foo = dynamic_cast< Foo* >( &subject );
        foo->doBar();
    }
    

    😉



  • Ja, aber doBar() ist eine Methode von Foo, nicht von Subject, also muss ich ja casten.
    So sieht doch die "offizielle" Implementierung vom Observer aus?
    Warum denn nun Referenzen?



  • [edit] war Blödsinn [/edit]

    Greetz, Swordfish



  • 1310-Logik schrieb:

    Ja, aber doBar() ist eine Methode von Foo, nicht von Subject, also muss ich ja casten.
    So sieht doch die "offizielle" Implementierung vom Observer aus?

    virtual void update( Subject* subject )
    {
        Foo* foo = dynamic_cast< Foo* >( subject );  //Foo ist abgeleitet von Subject (Abstrakte Klasse)
        foo->doBar();
    }
    

    Was ist denn das für eine Implementierung des Observer-Patterns?
    Wenn Du in der update-Methode ein Subject als Pointer übergibst, kannst Du den doch nicht in der Methode pauschal zu einem Typ einer abgeleiteten Klasse casten.




Anmelden zum Antworten