Pointer vs. Referenz
-
[quote="Belli"]
Simon2 schrieb:
_matze schrieb:
Ich muss gestehen: Ich finde es schlimmer als gar nichts, weil bei mir bei der Verwendung von Zeigerparametern immer sofort die Alarmglocken schrillen: Warum Zeiger?
- 0 erläubt?
- Polymorphie erwartet ?(ich weiß, geht auch mit Referenzen, da sind Zeiger aber doch noch verbreiteter)
- irgendwelche "Speicherschweinereien" geplant?
- auto-Objekt ("Stack") erlaubt?
- ...Für mich geht es einfach und allein darum, daß ich bei Wartung, Pflege, Analyse von selbst geschriebenem Code beim Aufruf einer Funktion ohne Zeiger weiß, daß mein Parameter nach Rückkehr unverändert ist, OHNE daß ich mir die Funktionsdeklaration ansehen muß.
Bei Übergabe eines Zeigers weiß ich, daß der Parameter nach Rückkehr verändert sein KANN.
MIR erleichtert das Analyse und Fehlerrecherche.Wenn man Software im Team entwickelt und Teamintern eine solche Verfahrensweise einhält, ist das auch sehr hilfreich.
Selbst wenn du es in deinem Team einhältst bringt es noch nicht wirklich viel, weil externe Libs es nicht so machen müssen außerdem bedeutet Pointer ja nicht zwangsläufig, dass das Object verändert wird und dann musst du doch wieder nachschauen.
Und wirklich interessant ist das ganze auch nicht. Ich hab schon mit ner Menge fremden Code gearbeitet und debuggt, aber ob ein Objekt in einer Funktion verändert wird oder nicht, war eigentlich nie ein Problem.
-
Belli schrieb:
...Für mich geht es einfach und allein darum, daß ich bei Wartung, Pflege, Analyse von selbst geschriebenem Code beim Aufruf einer Funktion ohne Zeiger weiß, daß mein Parameter nach Rückkehr unverändert ist, OHNE daß ich mir die Funktionsdeklaration ansehen muß....
"Es geht sich um Folgendes ...."
Ich möchte hier diskussionstechnisch mal unterscheiden zwischen 2 Situationen:
A) Ich stolpere beim Maintance-Aufgabe über ein Stück Source der Formf(&x). Da kommt mir die Idee "Aha! Diese Funktion könnte den Zustand von x verändern.
Oder über ein Stück Code der Formstd::string const s="Simon2"; f(s);. Da kommt mir die Idee "Aha! Diese Funktion wird diesen String wahrscheinlich nicht verändern."[/c].
Diesen Gedankengang finde ich naheliegend und teile ihn auch.
Ich überlege mir eine neue Schnittstelle für meine Bibliothek und stehe vor der Frage "Wie soll die Parameterübergabe entworfen werden?".
Dann kommt mir der Gedanke: "Da das ein update-Parameter werden soll, nehme ich einen Zeiger oder eine Refernzen. Damit der Benutzer (bzw. ein späterer 'Maintainer') direkt erkennen kann, dass es sich um einen update-Parameter handelt, entscheide ich mich für einen Zeiger."
Diesen (kursiv hervorgehobenen) Gedankengang würde ich nicht teilen - aus den o.g. Gründen.Die Ausgangsfrage dieses Threads schien mir in Richtung
zu gehen ... aber vielleicht ist das Alles auch nur ein schrecklicher Irrtum. Gruß,
Simon2.
-
Simon2 schrieb:
Ich muss gestehen: Ich finde es schlimmer als gar nichts, weil bei mir bei der Verwendung von Zeigerparametern immer sofort die Alarmglocken schrillen: Warum Zeiger?
Das kommt daher dass man immer sagt: Zeiger sind böse. Aber das sind sie nicht. Zeiger sind deine Freunde.
- 0 erläubt?
uninteressant beim code lesen. ist aber ein standard precondition fall. hat man bei referenzen und auch bei by value übergaben ebenfalls (in welchem zustand muss das objekt sein)
- Polymorphie erwartet ?(ich weiß, geht auch mit Referenzen, da sind Zeiger aber doch noch verbreiteter)
Hat rein garnichts mit Zeigern zu tun
- irgendwelche "Speicherschweinereien" geplant?
Nein.
Du musst dem Code vertrauen - wenn du ihm nicht vertraust, dann warte ihn nicht.
Speicherschweinereien kann ich mit Referenzen genauso machen.- auto-Objekt ("Stack") erlaubt?
ja, immer.
Ich überlege mir eine neue Schnittstelle für meine Bibliothek und stehe vor der Frage "Wie soll die Parameterübergabe entworfen werden?".
Dann kommt mir der Gedanke: "Da das ein update-Parameter werden soll, nehme ich einen Zeiger oder eine Refernzen. Damit der Benutzer (bzw. ein späterer 'Maintainer') direkt erkennen kann, dass es sich um einen update-Parameter handelt, entscheide ich mich für einen Zeiger."
Diesen (kursiv hervorgehobenen) Gedankengang würde ich nicht teilen - aus den o.g. Gründen.Der Punkt ist nicht ob du es auch so machst sondern ob du verstehst warum es Sinn machen kann es so zu machen.
Ich persönlich verwende nicht für OUT parameter Zeiger - aber ich verstehe den Gedankengang und sehe die Probleme die man damit löst.
-
Shade Of Mine schrieb:
Simon2 schrieb:
Ich muss gestehen: Ich finde es schlimmer als gar nichts, weil bei mir bei der Verwendung von Zeigerparametern immer sofort die Alarmglocken schrillen: Warum Zeiger?
Das kommt daher dass man immer sagt: Zeiger sind böse. ...
Nicht ganz.
Sondern weil man
a) 99% der Dinge ohne Zeiger machen kann und das
b) in den allermeisten Fällen einfacher (nix mit -> oder 0-Prüfungen oder ...)Dafür haben Zeiger bestimmte Möglichkeiten, die sie für bestimmte Situationen ideal machen (deswegen sind sie auch meine Freunde).
Shade Of Mine schrieb:
...
Der Punkt ist nicht ob du es auch so machst sondern ob du verstehst warum es Sinn machen kann es so zu machen.
Ich persönlich verwende nicht für OUT parameter Zeiger - aber ich verstehe den Gedankengang und sehe die Probleme die man damit löst.Moment: Nirgendwo habe ich gesagt, dass ich den Gedankengang nicht verstünde .... ich halte es nur nicht für die beste (und nicht einmal für eine erstrebenswerte) Herangehensweise an ein Problem ("Wie erkenne ich OUT-Parameter?").
Gruß,
Simon2.
-
Eine Möglichkeit, in/out/inout Parameter sicher zu erkennen, wären z.B. SAL Annotations. Ist aber MS-only, glaube ich. Außerdem leidet je nach Anwendung die Lesbarkeit doch stark...
-
Simon2 schrieb:
Nicht ganz.
Sondern weil man
a) 99% der Dinge ohne Zeiger machen kann und das
b) in den allermeisten Fällen einfacher (nix mit -> oder 0-Prüfungen oder ...)0 überprüfung ist ein schwaches argument. man muss nicht auf 0 prüfen
referenzen und zeiger sind gleichwertig - zeiger bieten mehr möglichkeiten und man könnte referenzen aus c++ verbannen ohne dass es probleme geben würde.
im prinzip existieren referenzen nur aus performance gründen...
die meisten sprachen haben deshalb sogar garkeine referenzen sondern nur zeiger.
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.
deine argumentation ist also sehr schwach.
warum sind zeiger schlechter als referenzen für out parameter?PS:
und du hältst es also nicht als erstrebenswert out parameter zu kennzeichnen...?
-
Shade Of Mine schrieb:
... und ich denke das wird den meisten leuten so gehen...
Nein, tut es nicht. Weder in unserer Firma (die mehrere tausend Mitarbeiter hat, von denen ein recht großer Anteil aus Softwareentwicklern besteht), noch, wenn man sich mal Publikationen von Leuten ansieht, die sich wirklich mit C++ auskennen. Es wurden sogar extra Referenz-Wrapper ersonnen, damit man noch weitgehender auf Zeiger verzichten kann.
Das Referenzen nur aus Performance-Gründen eingeführt wurden, ist schlicht und ergreifend Blödsinn.
Natürlich sind Referenzen nicht unbedingt notwendig. Genauso wenig sind Funktionen, Klassen oder erweiterte Kontrollstrukturen notwendig. man kann auch alles mit goto und if Programmieren.PS: Eigentlich wurde zu dem Thema schon alles gesagt. Das hier ist nur noch ein Flamewar...
-
Tachyon schrieb:
Nein, tut es nicht. Weder in unserer Firma (die mehrere tausend Mitarbeiter hat, von denen ein recht großer Anteil aus Softwareentwicklern besteht), noch, wenn man sich mal Publikationen von Leuten ansieht, die sich wirklich mit C++ auskennen. Es wurden sogar extra Referenz-Wrapper ersonnen, damit man noch weitgehender auf Zeiger verzichten kann.
Schau nochmal genauer hin.
Wo verwendest du oder sonstwer non-const referenzen? Und dann zieh davon die out parameter ab...
Was genau bleibt?
Und zeig mir mal so einen referenz wrapper, klingt ja interessant...
-
war nicht an mich gerichtet was ich jetzt zitiere, aber ich geb trotzdem meinen senf dazu
zeiger bieten mehr möglichkeiten und man könnte referenzen aus c++ verbannen ohne dass es probleme geben würde.
nope. referenzen verhalten sich was "=" angeht komplett anders als zeiger. im zusammenspiel mit templates kann man damit dinge tun, die ohne zeiger nicht oder nur sehr umständlich möglich wären. mir fällt da z.B. boost::tie() ein.
und ich muss gestehen, wenn wir const& mal weglassen da diese ja nur aus performance gründen existieren
"const&" ist was performance angeht weder schneller noch langsamer als "&" -- was für performance-gründe meinst du? oder meinst du dass man "const&" statt "by value" verwendet? ja, klar, das stimmt, das macht man wegen der performance. oder auch mal gerne weil ein objekt nicht kopierbar ist. ist ja auch gut so.
die meisten sprachen haben deshalb sogar garkeine referenzen sondern nur zeiger.
die meisten sprachen haben referenzen, viele haben sogar *nur* referenzen, und z.t. sogar referenzen auf referenzen ("by ref" übergabe eines reference types unter C# z.B.). manche sprachen beschränken bloss referenzen auf parameterübergabe -- was daran besser sein soll weiss ich nicht. bzw. es ändert eben nix an der tatsache dass man beim call nicht sieht dass es "by ref" ist. in C# schon, da man es an der call-site explizit dazuschreiben muss. finde ich gut. würde uns in C++ aber das genick brechen - man denke bloss wieder an templates.
dann habe ich immer mehr zeiger als non-const referenzen in meinem code.
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.
warum sind zeiger schlechter als referenzen für out parameter?
PS:
und du hältst es also nicht als erstrebenswert out parameter zu kennzeichnen...?doch, am besten macht man das indem man die funktionen die out parameter nehmen so nennt, dass jeder sofort weiss dass sie objekte modifizieren, und welche.
Und zeig mir mal so einen referenz wrapper, klingt ja interessant...
boost::ref<>
-
Shade Of Mine schrieb:
im prinzip existieren referenzen nur aus performance gründen...
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 vermute, referenzen mußten erfunden werden, um eine nette syntax bei manchen überladenen operatoren zu erlauben.
ganz nebenbei ist es unfug, nur deswegen, weil sie für manche operatoren nötig sind, sie jetzt auf einmal überall zu nehmen, wo es erlaubt ist, aber da sind wir uns ja einig.
-
hustbaer schrieb:
doch, am besten macht man das indem man die funktionen die out parameter nehmen so nennt, dass jeder sofort weiss dass sie objekte modifizieren, und welche.
Du willst Funktionen so benennen, dass aus der Bezeichnung ersichtlich ist, ob und welche Parameter out (oder auch inout) sind? Bei mehreren Parametern wird das aber schwierig.
Da halte ich SAL Annotations (oder was Selbstgebasteltes wie "#define OUT" und "#define INOUT") für sinnvoller.
-
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.
