Pointer vs. Referenz
-
volkard schrieb:
nein. nichts geht mit referenzen performanter als mit zeigern. immer, wenn so optimierungen möglich sind, daß eine referenz nur ein zuätzlicher symboltabelleneibtrag auf ein anderes objekt ist, kann der entsprechenden zeiger auch wegoptimiert werden.
Ich dachte dabei eher en const& um unnötige kopien zu verbieten.
ein T& ansich ist nur syntax zucker.
@hustbaer:
warum genau ist ein
tie(&a,&b) = get_pair();
nun unmöglich?ich auch, wenn man smart pointer und "char const*" mitzählt. sonst nicht, da ich generell auch dann referenzen verwende wenn sie nicht const sind. wobei ich versuche diesen fall weitestgehend zu vermeiden, da ich output parameter nicht mag. weder mit zeigern noch mit referenzen.
bring mir nochmal schnell ein beispiel wo du non-const referenzen für etwas anderes als für out parameter gebraucht hast.
meistens sind da wegen kopiersemantik zeiger notwendig - nur selten sind referenzen dass was man will.
und smart pointer sind natürlich zeiger - char* lassen wir mal als neutral stehen...
boost::ref ist nur ein performance gimmick und verwendet intern sogar zeiger...
referenzen sind syntaktisch nett, aber sie bieten selber keinen relevanten mehrwert - bis auf eben bequemeres zugreifen.
was ich sagen will ist: zeiger sind nicht böse. referenzen sind nicht unnötig. referenzen sind einfach zeiger die man bequemer verwenden kann. deshalb sind aber referenzen nicht zwangsläufig immer das bessere mittel, denn die bequemlichkeit hat ihren preis. nämlich dass referenzen und values sich identisch verhalten und das führt zu unklarheiten. referenzen sind deshalb aber auch nicht immer schlechter...deshalb, noch einmal:
warum sind referenzen für out parameter besser als zeiger?
-
Shade Of Mine schrieb:
0 überprüfung ist ein schwaches argument. man muss nicht auf 0 prüfen
Das habe ich schon in einigen Projekten erlebt ("Nein, die Prüfung ist unsinnig, 0 kann nicht vorkommen" => BUMM).
Shade Of Mine schrieb:
im prinzip existieren referenzen nur aus performance gründen...
Sowie einer schöneren Syntax (Spätestens bei Mehrfachzeigern ist die Syntax, nun ja, zweifelhaft zu nennen).
Shade Of Mine schrieb:
die meisten sprachen haben deshalb sogar garkeine referenzen sondern nur zeiger.
Die aber meist die Syntax von Referenzen verwenden, und gewisse Einschränkungen haben um Fehlbedienung zu vermeiden.
Shade Of Mine schrieb:
und ich muss gestehen, wenn wir const& mal weglassen da diese ja nur aus performance gründen existieren - dann habe ich immer mehr zeiger als non-const referenzen in meinem code. und ich denke das wird den meisten leuten so gehen.
Das mag dir vielleicht so gehen, auch vielen anderen die entweder von C kommen, oder aus der C++ Anfangszeit stammen, nicht aber allen. In jedem Programm wo ich mitgearbeitet habe entstanden mehr Fehler bei der Zeigerverwendung als mit Referenzen. Zudem war der Code mit Referenzen häufig deutlich besser Lesbar.
Shade Of Mine schrieb:
warum sind zeiger schlechter als referenzen für out parameter?
1. Sehe ich einem Zeiger nicht an wer die Eigentümerschaft steuert.
2. Kann es doch schneller mal passieren das Unzulässige (0) Zeiger übergeben werden, ich persönlich habe auch noch nie einen Code gesehen wo dies konsequent und wenigstens per Assertion abgeprüft wurden ist.
3. Wenn es nach der Argumentation mit dem & als Markierung für out-Parameter geht, möchte ich mal denjenigen sehen der konsequent bei Zeigerübergaben eine notation ala &(*ptr) macht, um dies zu kennzeichnen.Nein, das heißt nicht das Zeiger immer Schlechter als Referenzen wären, nur es heißt für mich, das Zeiger ebenso nicht besser als Referenzen sind. Soll halt jeder so entwickeln wie er will. Mir jedenfalls sind seit ich versuche konsequent wo möglich Referenzen zu verwenden (und const ebenso intensiv zu nutzen) deutlich weniger Fehler unterlaufen (und viele davon sind auf die Compilezeit verlagert wurden).
Shade Of Mine schrieb:
und du hältst es also nicht als erstrebenswert out parameter zu kennzeichnen...?
Auch wenn es nicht in meine Richtung geht: An sich hätte ich nichts gegen eine Kennzeichnung von Out-Parametern, aber nicht durch "&" sondern durch ein Schlüsselwort das keine leichte Missinterpretation zulässt, und wo der Compiler dies auch anmeckern kann.
cu André
-
asc schrieb:
Shade Of Mine schrieb:
0 überprüfung ist ein schwaches argument. man muss nicht auf 0 prüfen
Das habe ich schon in einigen Projekten erlebt ("Nein, die Prüfung ist unsinnig, 0 kann nicht vorkommen" => BUMM).
assert und gut ist... bumm ist gut.
Das mag dir vielleicht so gehen, auch vielen anderen die entweder von C kommen, oder aus der C++ Anfangszeit stammen, nicht aber allen. In jedem Programm wo ich mitgearbeitet habe entstanden mehr Fehler bei der Zeigerverwendung als mit Referenzen. Zudem war der Code mit Referenzen häufig deutlich besser Lesbar.
auch du mein freund. bring mir ein beispiel wo du letztens non-const referenzen für etwas anderes als out params verwendet hast.
1. Sehe ich einem Zeiger nicht an wer die Eigentümerschaft steuert.
zeiger != dynamische speicher allokation
2. Kann es doch schneller mal passieren das Unzulässige (0) Zeiger übergeben werden, ich persönlich habe auch noch nie einen Code gesehen wo dies konsequent und wenigstens per Assertion abgeprüft wurden ist.
und was genau ist an dem assert so schwer?
und selbst ohne assert - 0 zeiger sind kein problem, da macht es immer peng.3. Wenn es nach der Argumentation mit dem & als Markierung für out-Parameter geht, möchte ich mal denjenigen sehen der konsequent bei Zeigerübergaben eine notation ala &(*ptr) macht, um dies zu kennzeichnen.
du hast meine posts nicht gelesen. bitte hol dies nach. dann wird dir klar warum dieser punkt schwachfug ist.
Nein, das heißt nicht das Zeiger immer Schlechter als Referenzen wären, nur es heißt für mich, das Zeiger ebenso nicht besser als Referenzen sind. Soll halt jeder so entwickeln wie er will.
Es geht nicht darum dass die out parameter als zeiger deutlich besser sind, sondern darum dass es sinn machen kann.
ich argumentiere nicht dass es besser ist, sondern dass es nicht schlechter ist. und ich habe immer noch kein argument gehört warum es schlechter ist. bis auf "man muss auf 0 prüfen". nur finde ich das schwach weil dann garantiert eh eine assertion fliegt, wenn nicht von mir dann vom compiler weil ich 0 dereferenziert habe...
Auch wenn es nicht in meine Richtung geht: An sich hätte ich nichts gegen eine Kennzeichnung von Out-Parametern, aber nicht durch "&" sondern durch ein Schlüsselwort das keine leichte Missinterpretation zulässt, und wo der Compiler dies auch anmeckern kann.
der compiler kann es heute schon anmeckern und ein out ist unpraktisch wenn man es dauernd beim caller schreiben muss...
also auch nicht 100% perfekt
-
Shade Of Mine schrieb:
Wo verwendest du oder sonstwer non-const referenzen? Und dann zieh davon die out parameter ab...
Ich verstehe die Frage nicht. Ich benutze ständig non-const Referenzen. Boost.ASIO macht das z.B. ebenfalls. io_service-Objekte werden als non-const übergeben. Überhaupt passiert das überall bei boost.
Den zweiten Teil des Satzes verstehe ich erst recht nicht.
Bei freien Funktionen, die auf Objekten arbeiten, benutze ich Referenzen übrigens für in/out-Parameter. Und überall da, wo valide Objekte übergeben werden müssen.
Und überhaupt sehe ich gar kein Argument. Du sagst lediglich, es wird nirgends gemacht, was a) nicht stimmt, und b) auch nicht wirklich ein Argument ist.Shade Of Mine schrieb:
Was genau bleibt?
s.o.
Shade Of Mine schrieb:
Und zeig mir mal so einen referenz wrapper, klingt ja interessant...
Bei boost.ref z.B.
Die Tatsache, das dort intern eh Zeiger werwendet werden, spricht wohl auch ganz eindeutig dagegen, dass es um irgendeinen Performancegewinn geht.Und ein assert IST eine Prüfung auf 0.
-
Shade Of Mine schrieb:
...
0 überprüfung ist ein schwaches argument. man muss nicht auf 0 prüfen...Es hilft nichts, wenn Du Dir einn Fitzel aus meiner Argumentation rauspickst ....
aber: Doch - bei optionalen Argumenten, ist eine Prüfung auf 0 seeehr sinnvoll. Wie Dir vielleicht aufgefallen ist, schrieb ich nicht, dass man bei Zeigern auf 0 prüfen müsste (so wie man auch nicht -> verwenden muss), sondern lediglich, dass das Möglichkeiten/Thematiken sind, die nur bei Zeigern auftauchen.Shade Of Mine schrieb:
...
...dann habe ich immer mehr zeiger als non-const referenzen in meinem code. und ich denke das wird den meisten leuten so gehen....Ist bei mir anders - spielt aber IMHO hier gar keine Rolle.
Shade Of Mine schrieb:
...
deine argumentation ist also sehr schwach.
warum sind zeiger schlechter als referenzen für out parameter?
...
Also wie Du nun zu dieser Aussage kommst, ist mir total schleierhaft.
Meine Aussage war bislang immer nur: "Zeiger nur deshalb zu verwenden, weil man damit [u]beim Aufruf OUT-Parameter kennzeichnen will[/i] ... finde ich nicht nicht überzeugend."Shade Of Mine schrieb:
...
und du hältst es also nicht als erstrebenswert out parameter zu kennzeichnen...?
Auch das habe ich nie behauptet... ich habe den Eindruck, dass Du mir jetzt Positionen unterschiebst, die Dir Andere aus Anderen Diskussionen entgegengebracht haben....
@Frage: Natürlich "kennzeichne" ich out parameter: Sie sind (in der Schnittsteller und nicht im Aufruf) non-const Zeiger (wenn die Angabe optional ist) oder Referenzen (wenn sie es nicht ist) - aber mit der Betonung auf "non-const" - das schlägt der Standard vor, das unterstützt der Compiler.Gruß,
Simon2.
-
Tachyon schrieb:
Ich verstehe die Frage nicht. Ich benutze ständig non-const Referenzen. Boost.ASIO macht das z.B. ebenfalls. io_service-Objekte werden als non-const übergeben. Überhaupt passiert das überall bei boost.
Langsam wird es langweilig. Ich sagte non-const Referenzen die nicht als out parameter verwendet werden...
Das ist mein letzter Post in diesem Thread, ich wiederhole mich ja nur noch.
Shade Of Mine schrieb:
Was genau bleibt?
s.o.
Nein, du hast kein einziges Beispiel fuer non-const Referenzen fuer etwas anderes als Out Parameter genannt. Kein einziges Beispiel.
Bei boost.ref z.B.
Die Tatsache, das dort intern eh Zeiger werwendet werden, spricht wohl auch ganz eindeutig dagegen, dass es um irgendeinen Performancegewinn geht.Aeh... boost.ref hat mit referenzen erstmal recht wenig zu tun.
boost::ref ist dafuer da um unnoetige kopien zu vermeiden (entweder aus performance gruenden oder um eine bestimmte semantik zu bekommen oder um zu garantieren dass immer auf dem selben objekt gearbeitet wird) und das ganze in einer netten syntax. boost::ref ist komplett ohne referenzen implementierbar...Und ein assert IST eine Prüfung auf 0.
ist ein
*p=0
auf eine pruefung auf null?
wenn ja, ok.
aber nochmals: null zeiger sind kein problem. ein zugriff darauf asserted eh immer. da muss ich garnicht assert(p) schreiben - man macht es nur aus konsistenz gruenden (es kann aber ohne probleme entfallen).Simon2 schrieb:
Shade Of Mine schrieb:
...
...dann habe ich immer mehr zeiger als non-const referenzen in meinem code. und ich denke das wird den meisten leuten so gehen....Ist bei mir anders - spielt aber IMHO hier gar keine Rolle.
Und ich habe immer noch kein einziges Beispiel fuer non-const Referenzen fuer etwas anderes als out Parameter bekommen.
Sollte einem zu denken geben
Shade Of Mine schrieb:
...
deine argumentation ist also sehr schwach.
warum sind zeiger schlechter als referenzen für out parameter?
...
Also wie Du nun zu dieser Aussage kommst, ist mir total schleierhaft.
Meine Aussage war bislang immer nur: "Zeiger nur deshalb zu verwenden, weil man damit [u]beim Aufruf OUT-Parameter kennzeichnen will[/i] ... finde ich nicht nicht überzeugend."[/quote]
Aber Referenzen zu verwenden weil "a so halt" ist besser?
Mein Punkt ist, dass beides gleichwertig ist - nicht dass eins besser ist. Ergo muss ich nicht agumentieren dass zeiger besser sind sondern nur dass sie nicht schlechter sind. Was basierend darauf dass es immer noch keinen einzigen grund gibt warum referenzen fuer out parameter sinnvoller sind recht leicht war bisher...@Frage: Natürlich "kennzeichne" ich out parameter: Sie sind (in der Schnittsteller und nicht im Aufruf) non-const Zeiger (wenn die Angabe optional ist) oder Referenzen (wenn sie es nicht ist) - aber mit der Betonung auf "non-const" - das schlägt der Standard vor, das unterstützt der Compiler.
Themenverfehlung.
Es geht um Kennzeichnung der Out Parameter dort wo es wichtig ist: im caller.
Im callee sind sie eh immer gekennzeichnet, das ist nie ein problem. Das problem ist die Kennzeichnung im caller.Aber wie gesagt, da ich wieder nur alles wiederholt habe was ich eh schon gesagt habe und keine antworten auf meine fragen bekomme erachte ich die diskussion als beendet.
-
Shade Of Mine schrieb:
...
Themenverfehlung.
Es geht um Kennzeichnung der Out Parameter dort wo es wichtig ist: im caller....Gut, ich denke, jetzt ist klar, warum niemand hier im Thread Deiner Meinung sein oder Deine Fragen zufriedenstellend beantworten kann: Weil Du über etwas ganz Anderes redest als der Rest der Mannschaft hier.
Macht ja nichts, aber ich werde mich dann zu Deinen Thesen und Fragen äußern, wenn wir Dein Thema in Deinem eigenen Thread diskutieren (und mir der Sinn danach steht).
... oder wenn wir irgendwie anders ein gemeinsames Diskussionsthema finden.
Gruß,
Simon2.
-
Shade Of Mine schrieb:
...bla...
Das Problem ist, dass Du absolut lernresistent bist. Die meisten Leute hier, sind noch meiner Erfahrung durchaus bereit, von Ihrem Standpunkt abzuweichen, wenn man Ihnen mit guten Argumenten kommt. Bei Dir ist das nicht der Fall.
Boost benutzt an vielen Stellen keine const-Referenzen, die auch keine reinen out-Paramter sind. Ich nannte bereits asio als Beispiel.
Und Zugriffe auf 0 asserten ganz sicher nicht immer. Sowas denkt man nur, wenn man nicht über Windows und *nix hinausgekommen ist...
Ansonsten ist es echt müßig, mit Dir zu diskutieren. Es führt eh nicht zu irgendwelchen tieferen Einsichten.