Wozu immer Zeiger?
-
Abgesehen von der natürlich besseren Benutzung von *=: Die Referenz. Ist lesbarer und es macht keinen Sinn, an eine Funktion dieser Art einen Nullzeiger zu übergeben, was der wichtigste Unterschied zwischen Referenzen und Zeigern wäre. Daher kann man es auch gleich ausschließen und hat so eine Fehlerquelle weniger.
-
Ist auch etwas schwierig zu beantworten, da das ein praxisfernes Beispiel ist. Die Referenz ist aus dem von SeppJ genannten Grund hier normalerweise zu bevorzugen, als Gegenargument könnte man sehen, dass eine Übergabe per Pointer deutlicher macht, dass die Funktion ihr Argument verändert. (Ebenso wie Pointerübergabe IMHO deutlicher machen kann, dass ein Argument polymorph verwendet wird)
-
wxSkip schrieb:
als Gegenargument könnte man sehen, dass eine Übergabe per Pointer deutlicher macht, dass die Funktion ihr Argument verändert.
Nö. Gibt wohl kaum was deutlicheres als eine Referenz auf non-const, um zu sagen "hey, ich verändere das Argument".
Gilt natürlich auch bei Pointern auf non-const, wobei Pointer zusätzlich besagen "Argument kann auch NULL sein".
Alternativ können Pointer natürlich auch C-Style bedeuten, wobei man sich dann auch auf const vs. non-const nicht mehr ernsthaft verlassen darf.wxSkip schrieb:
(Ebenso wie Pointerübergabe IMHO deutlicher machen kann, dass ein Argument polymorph verwendet wird)
Halte ich nicht für stichhaltig. Polymorphie funktioniert auf Referenzen genausogut wie auf Pointern. Ein Hinweis auf Polymorphie ist genau dann gegeben, wenn das Argument eine polymorphe Basisklasse ist - am Liebsten natürlich eine abstrakte.
-
@pumuckl: Dass die Funktion eine (nicht-konstante) Referenz nimmt, siehst du beim Aufruf aber nicht, nur bei Deklaration/Definition. Wenn du einen logisch sinnvollen Funktionsnamen/-aufruf hast, ist das aber sowieso unproblematisch.
-
wxSkip schrieb:
Dass die Funktion eine (nicht-konstante) Referenz nimmt, siehst du [...] nur bei Deklaration/Definition.
Und die kann man immer sofort sehen... (zumindest bei den neueren IDEs)
-
[Rewind] schrieb:
wxSkip schrieb:
Dass die Funktion eine (nicht-konstante) Referenz nimmt, siehst du [...] nur bei Deklaration/Definition.
Und die kann man immer sofort sehen... (zumindest bei den neueren IDEs)
Nix sofort. Bei jedem Funktionsaufruf den Mauszeiger dahin zu bewegen, auf den Tooltip zu warten und zu lesen ist bei weitem kein flüssiges Lesen von Quelltext.
"Sofort sehen" wäre, wenn die IDE Argumente für non-const Parameter irgendwie markieren oder einfärben würde. Und das kann die IDE meiner Wahl nicht.
-
Die IDE meiner Wahl zeigt alle Argumente bereits bei der Eingabe des Funktionsaufrufs und das ist "sofort".
-
Code::Blocks zeigt die Argumente manchmal bei der Eingabe und beim Lesen natürlich nicht.
-
@[Rewind]:
Während man Code schreibt, kann man mit allem möglichen mehr oder weniger gut zurecht kommen.Aber was macht man beim Lesen von Code? Beim Suchen von Fehlern?
Viel zu viele Programmierer machen sich darüber viel zu wenig Gedanken, und erzeugen viel zu viel schrecklichen Code.
-
Da bleibt wohl nichts anderes übrig als die Maus zu bemühen.
