Wann ein Zeiger als Parameter wann eine Referenz?
-
Da die "kritsche" Stelle schon mit
CAttachment *pAttachment = cAttachments[ndx]; if (pAttachment)ist das kein besonders geeignetes Beispiel für dein Argument (Pointer <-> Referenz) wie ich finde, da ein möglicher Null-Pointer die Verwendung von Referenzen an dieser Stelle weitestgehend ausschliesst. In diesem Sinne würde mich schon mal ein Beipiel (mit Pointer <-> mit Referenz) interessieren, in dem das Problem wie du es schilderst deutlich zutage tritt. Mir ist das nämlich auch nicht so ganz klar
mfg JJ
-
ok, schlechtes beispiel. dann muss ich wohl länger suchen.
wie sucht man gezielt schlechten code?
-
wie sucht man gezielt schlechten code?
na, hier im forum!
-
volkard schrieb:
wie sucht man gezielt schlechten code?
Such nach MFC oder WinApi Sources...
-
Such nach "Spiele". Da gibt's genug Leute, die nicht coden können, aber Spiele machen wollen.
-
Optimizer schrieb:
Such nach "Spiele". Da gibt's genug Leute, die nicht coden können, aber Spiele machen wollen.
jo, war auch mein gedanke. hab sofort zerbies code angeguckt. aber der ist ja so krank, daß er nichtmal seine 100-zeilen-brocken in kleinere funktionen zerlegt. war nicht verwertbar.
-
roflmao.
-
kann von hier aus nix suchen. die connection bricht immer nach ner minute ab. ich kann nur versuchen, das nächste ma, wenn ich code finde, der deutlich davn profitiert, ihn euch mitzubringen.
-
@Volkrad:
im Thread: http://www.c-plusplus.net/forum/viewtopic.php?t=81443 hast du eine Variante einer Funktion geschreiben, die der vorherigen entspricht, allerdings einen ostream entgegennimmt, damit man felxibler ist.
Wieso nimmst ud ihn als non-const-ref entgegen.De Regel lautet doch
benutze non-const-refs nur, wenn es echt notwendig ist.
-
rofl
-
nicht wirklich flexibler. in der hauptsache kaputter.
warum verwende ich std::swap?
aus historischen gründen.
-
Hab zwar keine Ahnung wo man im Netz miesen Code findet aber richtig guten Source findet man hier ~~> http://www.tw.ioccc.org/years.html#2000_anderson
-
Das erklärt immernoch nciht, warum du jetzt den ostream als nicht konstante Referenz entgegennimmst und somit gegen deine eigene Regel verstößt.
-
volkard schrieb:
mach das mal, wenn die leutchen ständig non-const-refs benutzen. da wirste innerhalb von tagen doch durchdrehen.
Sorry, Missverständnis.
Ich weiss, dass du Zeiger gerne nimmst. Ich wollte nur wissen, wann du denn dann non const Referenzen nimmst.
-
Helium schrieb:
Das erklärt immernoch nciht, warum du jetzt den ostream als nicht konstante Referenz entgegennimmst und somit gegen deine eigene Regel verstößt.
und du hast nicht über meine antwort nachgedacht.
warum verwende ich std::swap? aus historischen gründen. das ding hat sich in dieser form fest eingebürgert, bevor man erkannte, wie falsch es eigentlich ist. und das gleiche passierte anno dazumal mit virtual void Foo::printAt(ostream& out);. afair sah ich es 1995 beim borland c++ 3.1 in der lib zum ersten mal. das ändert sich nicht von heut' auf morgen. eventuell ändert sich das nie und dan läßt sich es auch mit ein paar ausnahmen leben. aber man muß es ja nicht drauf anlegen, und in völliug anderen zusammenhängen proggen wie die leutchen damals vor 10 jahren.
-
Shade Of Mine schrieb:
Ich weiss, dass du Zeiger gerne nimmst. Ich wollte nur wissen, wann du denn dann non const Referenzen nimmst.
kann mich gerade nur an swap und printAt erinnern. evtl immer bei streams. ob technische argumente dafürsprechen? vielleicht. sie werden auf jeden fall vom argument verdeckt, daß man in seinem code einigermaßen konsistent zum rest der welt baen muß. wenigstens bei swap kommt man nicht drumherum. wegen der neuen implementierung von op= mit dem swap-trick.
und halt, wo es sein muß. also operatoren.
refs als member habe ich nie. da hakt's bei mir dann einfach aus, daß ich ne ref als member habe, die meine klasse ganz zufällig genau sizeof(void*) bytes größer werden läßt.
-
Ist es nicht immer lästig bei Zeigern zu prüfen, ob sie 0 sind, bevor man sie dereferenziert?
-
nein, wenn du dir sicher sein kannst, dass die zeiger nicht null sind,musst du nicht prüfen.
eine frage hab ich aber:
dürfen funktionen, die einen pointer als parameter erwarten die aufgabe des "auf 0 testen" auf den rest des programms auslagern? oder soll in den fällen, wo der funktion kein nullpointer übergeben werden darf,immer innerhalb der funktion getestet werden?
-
am besten ist es wenn die funktion den null-test selber macht. Übersichtlicher und besser gekapselt, weil unsichtbar. das sieht nicht gut aus, wenn vor jeder Funktion, die pointer erwartet, mehrere if-Abfragen stehen.
-
otze schrieb:
nein, wenn du dir sicher sein kannst, dass die zeiger nicht null sind,musst du nicht prüfen.
eine frage hab ich aber:
dürfen funktionen, die einen pointer als parameter erwarten die aufgabe des "auf 0 testen" auf den rest des programms auslagern? oder soll in den fällen, wo der funktion kein nullpointer übergeben werden darf,immer innerhalb der funktion getestet werden?Ich halte es für sehr schwer von außen sicherzustellen, dass ein Pointer nie 0 ist. Selbst wenn dies am Anfang der Fall ist, wird durch Erweiterungen und Wartung immer wahrscheinlicher, dass mal ein 0 Pointer übergeben wird. Ein Parameter, der einen Zeiger erwartet, hat die semantische Aussage: "Da kannst du auch 0 reinstecken."
Dagegen verhindert bei einer Referenz schon der Compiler, dass eine 0 reingesteckt wird. (Mit den bekannten Ausnahmen) Die semantische Aussage ist jedoch: "Da muß ein gültiges Objekt rein."
Jemand, der das Programm wartet oder erweitert, wird bei Referenzen sicherstellen, dass gültige Objekte übergeben werden. Bei Zeigern wird er aber annehmen, dass 0 übergeben werden kann.