Zeiger oder Referenz

hehejo

Natürlich hat man selbst etwas mehr zu schreiben, aber der Aufrufer weißt dann gleich Bescheid.
Muss er ein '&' schreiben, wird die Methode bestimmt seinen Wert verändern.

Power Off

hehejo schrieb:

Natürlich hat man selbst etwas mehr zu schreiben, aber der Aufrufer weißt dann gleich Bescheid.
Muss er ein '&' schreiben, wird die Methode bestimmt seinen Wert verändern.

Das muss nicht so sein:

void func( const A* a ) { /* ... */ }

A b;

func( &b ); // !!!!!!!!!!

volkard

Power Off schrieb:

Nach volkard's Modell programmierte String-Funktion:

#include <string>

using std::string;

void func( string* dest, const string& src ) {
   dest->operator+=( src );
}

Bzw.:

void func( string* dest, const string& src ) {
   *dest += src;
}

Mit Referenzen:

void func( string& dest, const string& src ) {
   dest += src;
}

zeig auch die aufrufe, damit der sinn erkennbar ist.

func(&a,b);

a wird offensichtlich verändert und b nicht.
veränderliche parameter sind eh fast immer mist. also ist das anzuwarnen doch voll klug. so wie auch die lange schreibweise von reinterpret_cast und konsorten absichtlich lang ist.

volkard

User--- schrieb:

Und wer ein v.add( f ); schreibt, das v auf f addiert, der gehört kräftig angebrüllt. Wenn auf f was addiert werden soll, dann schreibt man das f.add( v ); und nicht umgekehrt.

a.print(b) macht was?
es ist leider die pur virtuelle void print(ostream&), die man braucht, um polymorphe objekte mit op<< auszugeben.
klar hieß die beim borland ursprünglich printAt, aber heute heißt sie meistens nur print. die namen verschlechtern sich also messbar. hab ich jetzt recht?

volkard

Walli schrieb:

Btw: Was unterscheidet eigentlich jetzt genau einen Kommentar von deiner Art der Kennzeichnung? Du hast durch die Zeigerlösung ja auch keinen Mehrwert außer dem '&', welches dir anzeigt, dass der übergebene Parameter modifiziert wird.

was ist an irgendeinem stil mehr als kommentar, wenn du es ganz eng nimmst?
das warn-& ist ein wenig mehr als kommentar, weil es im code steht und weil es was wichtiges vermittelt. und bei löschen des & gibts compilerfehler! es ist mehr als nur warnung, es ist ein automatisches verhüterli. kommentare hingegen sind doof und die liest man nicht und sie sind natürlichsprachlich.

volkard

User--- schrieb:

Volkard dein Argument gilt aber nur für Objekte die auf dem Stack liegen, sobald ich das Objekt auf dem Heap habe, oder selbst nur nen Zeiger habe, dann ist ein foo( bar ); keine Eindeutigkeit mehr für ein veränderbarer Parameter.

warum sollte ich nicht

Student* ps=new Student;
read(ps);//verändert
print(*ps);//nicht verändert

schreiben?

Walli

Mal angenommen du siehst nicht eine Zeile drüber, dass es ein Pointer ist. Schreibst du dann konsequenterweise so was? Oder markierst du deine Pointer immer mit p?

read(&(*ps));

Oder markierst du deine Pointer immer mit p?

Machst du das nicht? Ich markiere die nicht nur, ich baue mir durch Kuerzel sogar noch den Datentyp in den Variablennamen, was meiner Meinung nach seehr sinnvoll ist...

Walli

Jaja, die Diskussion hatten wir mindestens schon 25 Mal.

volkard

Walli schrieb:

Mal angenommen du siehst nicht eine Zeile drüber, dass es ein Pointer ist. Schreibst du dann konsequenterweise so was? Oder markierst du deine Pointer immer mit p?
read(&(*ps));

ich kann nicht &*ps programmieren. kannst du das?
natürlich markiere ich meine pointer nicht mehr mit p.
und ich kenne den typ meiner variablen, weil ich kleine funktionen baue.

Walli

volkard schrieb:

Walli schrieb:
Mal angenommen du siehst nicht eine Zeile drüber, dass es ein Pointer ist. Schreibst du dann konsequenterweise so was? Oder markierst du deine Pointer immer mit p?
read(&(*ps));
ich kann nicht &*ps programmieren. kannst du das?

Habs ehrlich gesagt noch nie versucht. Ich schätze mal einfach dass ich es nicht kann .

volkard schrieb:

und ich kenne den typ meiner variablen, weil ich kleine funktionen baue.

Ich auch. Aber ich verstehe nicht warum du bei deinen übersichtlichen Codes noch Markierungen brauchst. Das Argument warum du nicht mit p deine Pointer markierst sollte doch eigentlich auch bei der Sache mit & in der Parameterübergabe ziehen.

volkard

Walli schrieb:

Ich auch. Aber ich verstehe nicht warum du bei deinen übersichtlichen Codes noch Markierungen brauchst.

sie nehmen mir noch ein wenig denkarbeit ab.

Das Argument warum du nicht mit p deine Pointer markierst sollte doch eigentlich auch bei der Sache mit & in der Parameterübergabe ziehen.

nicht ganz. zeiger sehe ich nicht als gefahr an. schreibende (also zerstörende) funktionen schon.

Sovok

Power Off schrieb:

Das macht nix, weil es einen operator+( const char*, const string& ) gibt, den Volkard ja aufgelistet hat.

cool gut zu wissen
thx volkard

Tc++H

Also, dass so endet wollte ich nicht. Nun könnt ihr mir ja mal zum Abschluss sagen, wofür ich am besten Zeiger oder Referenzen verwenden soll.

mfg Tc++H

Konrad Rudolph

Tc++H schrieb:

Also, dass so endet wollte ich nicht. Nun könnt ihr mir ja mal zum Abschluss sagen, wofür ich am besten Zeiger oder Referenzen verwenden soll.

Wenn man sich denn einig wäre ...

Tc++H schrieb:

Also, dass so endet wollte ich nicht. Nun könnt ihr mir ja mal zum Abschluss sagen, wofür ich am besten Zeiger oder Referenzen verwenden soll.

mfg Tc++H

Referenzen

Tc++H schrieb:

Nun könnt ihr mir ja mal zum Abschluss sagen, wofür ich am besten Zeiger oder Referenzen verwenden soll.

Am besten gehst du in eine Bibithek, nimmst dir "More effective C++" von Scott Meyers zur Hand und ließt dir "Richtlinie 1 : Der Unterschied zwischen Ziegern und Referenzen" durch.

Oder ich zitiere mal den letzten Absatz aus dem Kapitel:

Zitiert von Scott Meyers -Mehr Effektiv C++-

Referenzen sind die erste Wahl, wenn wir wissen, dass wir uns auf ein 
existierendes Objekt beziehen und wenn wir niemals möchten, dass sich die
Variable auf ein anderes Objekt bezieht; auserdem noch, wenn die 
Implementierung von Operatoren die Benutztung von Zeiger unerwünscht macht. In
allen anderen Fällen benutzen wir Zeiger.

EDIT:( Auch wenn das jetzt nicht so genau passt zum Thema )

volkard

Tc++H schrieb:

Also, dass so endet wollte ich nicht. Nun könnt ihr mir ja mal zum Abschluss sagen, wofür ich am besten Zeiger oder Referenzen verwenden soll.

lies dir den thread hier durch, wäge die argumente gegeneinander ab und entscheide dann selber. oder noch besser, probiere beides aus.

volkard

Freak_Coder schrieb:

Oder ich zitiere mal den letzten Absatz aus dem Kapitel:

naja, der erste konkrete punkt, afair, wo meyers nicht meine meinung trifft.
edit: kann gar nicht sein, ich lese selber nach.
edit2: so klar geht da zum problem "zeiger oder referenz als übergabeparameter" nix hervor. und aus den anderen büchern auch nicht, weil verönderliche parameter zu selten sind. deswegen ist das problem einfach nicht offiziell ausgeleuchtet und der referenzwahn ist noch nicht korrigiert worden.

groovemaster

volkard schrieb:

Walli schrieb:

Ob die Funktion etwas mit dem übergebenen Objekt macht erkenne ich daran ob die übergebene Referenz const ist oder nicht

das ist aber nur die eine richtung. die funktion verspricht dir, daß da nix geändert wird.

Nein, die Funktion *garantiert* mir, dass da nix geändert wird. Oder hast du schon mal versucht, eine const referenziertes Objekt zu ändern? Klar, mit Casten geht das. Ob's dann aber noch definiert ist, ist eine andere Geschichte.

volkard schrieb:

ich brauche aber auch nicht anhand des namens zu überlegen, und das klappt eh nicht immer.
f.add(v);
soll jetzt v zu f addiert werden oder f zu v?

v zu f, alles andere macht keinen Sinn, sofern man konform zu Operatoren bleiben will. Dazu muss ich nicht wissen, ob v verändert wird oder nicht. Und um das mit dem oben genannten zu verbinden, wenn v eine const Referenz ist, dann *weiss* ich, dass nichts verändert wird.

volkard schrieb:

deswegen will ich keine semantischen feinheiten ausdeuteln müssen, sondern *sofort* sehen, was los ist. insbesondere will ich *nicht* überlegen müssen, was die funktion denn bewerkstelligt. ich kann nicht immer aus dem namen genau folgern, was die funktion macht. vor allem, wenn fremde leute die funktionsnamen erfunden haben.

Erstmal, das was du machst, ist eine reine Definitionsgeschichte. Du nimmst halt Zeiger auf non-const für veränderbare Parameter, andere nehmen non-const Referenzen. Sprachlich gesehen, macht das kaum Unterschied. Bis auf den zusätzlichen Adressoperator und die zusätzliche Indirektion bei Zeigern. Du willst also einfach am & erkennen, ob der Parameter verändert wird oder nicht? Deshalb sprach ich von semantischen Feinheiten, da es sowas in anderen Sprachen nicht unbedingt geben muss. VB bietet hier zB ByRef und ByVal für Parameter. Aus meiner Erfahrung kann ich sagen, dass für mich bisher weniger interessant war, ob ein Parameter verändert wird oder nicht. Sowas braucht man doch höchstens für Fehlersuche. IdR sieht man anhand des Codeflows, was passiert. Ein 'a = b + c' oder 'ship.move(d)' ist da doch ziemlich intuitiv, oder? Ein 'e = ship.position()' ist auch schöner als 'ship.position(&f)'.
Deshalb ist für mich viel interessanter, was die Funktion denn wirklich macht. Ob ich das anhand des Namens erkenne oder die Doku nachlese, ist dabei egal. Zudem ist es imo sicherer, man erkennt anhand der Funktionssignatur, ob ein Parameter verändert wird (bzw. werden kann) oder nicht, als an der Übergabe selbst.
Ich will dich aber nicht von deiner Vorgehensweise abbringen. Wenn du damit besser leben kannst, dann ist das ok. Nur sehe ich da keine Vorteile. Wobei ich mich lediglich auf die Frage des Threaderstellers beziehe. Einige scheinen das hier in einem generellen Referenz vs Zeiger Thread ausarten zu lassen. Denen sei nur noch mal gesagt, dass dieser Vergleich Blödsinn ist, Referenzen sind kein Ersatz für Zeiger.

Walli schrieb:

Ich finde die beiden ergänzen sich hervorragend.

Tja, dem kann ich eigentlich nichts hinzufügen.