Zeiger oder Referenz

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.

volkard

groovemaster schrieb:

volkard schrieb:

die funktion verspricht dir, daß da nix geändert wird.

Nein, die Funktion *garantiert* mir, dass da nix geändert wird.

verspricht. ich lebe in einer welt der gentlemen, wo versprechen eingehalten werden.

Sowas braucht man doch höchstens für Fehlersuche.

aua. geht's nicht immer nur darum, die fehlersuchzeit zu minimieren? durch fehlervermeidung und wenn er passiert ist durch lesbaren code? ja, ich stehe dazu, daß mir die codierzeit schnurz ist und ich fast nur auf die fehlersuchzeit achte.

Ob ich das anhand des Namens erkenne oder die Doku nachlese, ist dabei egal.

tja, du hast wohl mehr erfahrung als ich und kannst besser mit schlechten namen umgehen.

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.

sicherer? wenn ich wirklich immer in die doku oder auf die tooltips gucke, dann isses egal. wenn ich das nicht mache und wenn ich mich drauf verlassen kann, daß die bisher existierenden funktionen meine richtlinie einhalten, habe ich definitiv einen sicherheitsgewinn.

sind denn die nachteile, die du siehst, wirklich nur ein gelegentliches * und & zu viel? muß wohl jeder für sich rausfinden, ob er das zahlen mag für einen leichten sicherheitsgewinn.

groovemaster

volkard schrieb:

sind denn die nachteile, die du siehst, wirklich nur ein gelegentliches * und & zu viel?

Als Nachteil würde ich es nicht sehen, es ist aber tatsächlich der einzige Unterschied, den ich als unschön empfinde (ist halt Geschmackssache). Und wenn ich schon mal einen Zeiger als Parameter habe, dann mach ich zu Beginn der Funktion idR eine Referenz daraus. Das liegt aber einfach daran, dass ich lieber 'foo.bar' als 'foo->bar' bzw. 'foo = bar' als '*foo = bar' schreibe.

volkard

groovemaster schrieb:

Und wenn ich schon mal einen Zeiger als Parameter habe, dann mach ich zu Beginn der Funktion idR eine Referenz daraus.

mach ich auch gerne, aber (noch?) nicht idR.

volkard schrieb:

edit2: so klar geht da zum problem "zeiger oder referenz als übergabeparameter" nix hervor.

Habe ich auch erst später gemerkt das es hier um die Parameter geht als ich die 1. ThreadSeite wieder gelesen habe. Deswegen auch ==>

Freak_Coder schrieb:

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

ohne jetzt den alten streit wieder zu entflamen, (ihr seit dem TCPHP ja schön auf den leim gegangen :p )
wie mach ich es denn ohne veränderbare übergabeparameter (ob jetzt zeiger oder referenz ist mir "fast" egal), wenn ich 2 oder mehr rückgabewerte brauche, um mein konzept umzusetzten? dazu brauchts eurer meinung nach wohl noch ne sprache mehr (nenn sie "c-dur" zum beispiel)?

oop behebt das problem doch ganz klar: hab ich mehr als ein einfaches ja oder nein oder 42 als rückgabe dann brauch ich ein objekt und entsprechende membervariablen, die innerhalb des funktionblocks gesettet werden. dann brauch ich maximal eine callbyconstref um den speicher zu schonen, stilfrage ist was anderes..

oder wie??

referenz
zeiger
harte valuta

kartoffelsack

für zwei Rückgabewerte:

std::pair< int, double> foo();

für mehr Rückgabewerte:

boost::tuple<int, double, float, std::string> foo();

Aber nur, wenn die Werte wirklich für sich stehen. Wenn es zusammengehört dann eher eine POD-Struct oder eine Object.
Getrennte Werte zurückgeben ist eher sinnvoll wie z.B. bei der find-methode der standar-Container. Ein Wert sagt, ob etwas gefunden wurde, der andere ist der iterator auf den gefundenen Wert (oder das Ende). Mehr als zwei getrennte Werte zurückgeben zu müssen kommt (nach meiner Erfahrung) eher selten vor.