Rückgabe von Objekten
-
Obwohl ich eigentlich eurer Meinung bin (Nexus und Simon2), muss ich halt, weil es sonst atm niemand macht ein paar Gegenargumente bringe.
oh ja und dann bei Pointerpointern dann
mach_was_mit_parm2(&(******y));So viele Pointer braucht man grundsätzlich nie. Ansonsten ist es falsch designed.
hat man ja immer noch keine Garantie, dass x tatsächlich verändert wird
Um das ging es ja auch nicht. Es ging darum möglichst schnell zu erkennen, dass die Möglichkeit besteht, dass die Funktion das Objekt verändert.
-
Vielleicht sollten wir erst einmal lernen zu verstehen warum volkard vorschlägt es so zu machen. Es geht dabei nicht darum einfach mehr zu schreiben weil es lustig ist - sondern es geht darum ein konkretes problem zu lösen.
Ich habe ein Objekt und das ist in einem ordentlichen Zustand und etwas später ist es das nicht mehr. Warum?
Indem ich nun weiss dass überall dorthin wo ich das Objekt als Zeiger übergebe Änderungen stattfinden können, kann ich sehr sehr schnell die entsprechenden funktionen identifizieren. Denn ich weiß ja ob x ein Zeiger ist oder nicht -> ich muss nur umdenken:
foo(*x)
heisst nicht verändert aber
foo(x)
heisst möglicherweise verändert.Und das ist die Idee dahinter.
Es ist eine Lösung für ein Problem. Nicht mehr und nicht weniger.
Ich selber bin kein Fan davon, aber das hindert mich nicht daran die Idee dahinter zu verstehen und ok zu finden.
-
drakon schrieb:
...So viele Pointer braucht man grundsätzlich nie. Ansonsten ist es falsch designed. ;)...
Naja, ich würde das ja auch nie tun, aber wenn man halt überall mit Pointern auch "Veränderbarkeit" (und vielleicht noch ein paar andere Dinge) ausdrücken möchte, könnte es schon dazu kommen...
Wie soll das Ganze eigentlich bei templates aussehen? Oder bei Smartpointern? Oder ...
drakon schrieb:
...Obwohl ich eigentlich eurer Meinung bin (Nexus und Simon2), muss ich halt, weil es sonst atm niemand macht ein paar Gegenargumente bringe....
Man muss nicht auf ein Pferd steigen, bloß weil keiner (mehr) drauf sitzt.
drakon schrieb:
...Um das ging es ja auch nicht. Es ging darum möglichst schnell zu erkennen, dass die Möglichkeitbesteht, dass die Funktion das Objekt verändert.
Aha - das bedeutet: Ich weiß nicht nur NICHT, ob die Funktion nach der "Zeiger=Veränderung"-Regel gestrickt ist, sondern auch nicht, ob die Funktion (wenn sie es denn wäre) den Parameter tatsächlich verändert.
Gerade bei "schnell erkennen" wäre ich dafür, dass meine Sicherheit durch eine Regel wächst und nicht abnimmt.Gruß,
Simon2.
-
Simon2 schrieb:
Aha - das bedeutet: Ich weiß nicht nur NICHT, ob die Funktion nach der "Zeiger=Veränderung"-Regel gestrickt ist, sondern auch nicht, ob die Funktion (wenn sie es denn wäre) den Parameter tatsächlich verändert.
bei x+=y weißt du auch nicht, ob x geändert wird. und das ist sehr sehr oft so, daß ein funktionsaufruf nur die möglichkeit hat, was zu ändern und in manchen fällen doch nix ändert.
dein argument war so flach, als hättest du noch nie programmiert, daß ich auf so nen kinderkram einfach keine weitere lust habe. du weißt, daß ich programmiertechnisch kein vollidiot bin, also erwäge einfach die möglichkeit, daß mein ansinnen auch seine berechtigung hat. übrigens ist das argument, daß eine stilregel nix bringt, weil sie nix bringt, wenn sich keiner dran hält, leer.
-
Shade Of Mine schrieb:
...
Sehe ich auch so und darum habe ich auf simons Post so geantwortet..
Man muss nicht auf ein Pferd steigen, bloß weil keiner (mehr) drauf sitzt.
Das war eigl. nur ein kleiner Joke, der gerade gepasst hat, aber ich wollte halt die Idee dahinter verteidigen, welche ich schon auch verstehe. (auch wenn ich es so nicht machen würde..)
Aha - das bedeutet: Ich weiß nicht nur NICHT, ob die Funktion nach der "Zeiger=Veränderung"-Regel gestrickt ist, sondern auch nicht, ob die Funktion (wenn sie es denn wäre) den Parameter tatsächlich verändert.
Es geht ja in erster Linie ja nicht darum zu wissen, welche Funktionen etwas verändern, sonder zuerst einmal darum dijenigen herauszufilter, welche es sicher nicht machen.
@volkard:
Was ist dann aber z.B in einer Klasse? Wenn du dort z.B rausfinden musst, wo eine Member verändert wird, dann musst du ja dennoch alle Funktionen durchsuchen. (respektive dijenigen, welche auch aufgerufen werden..).
Kann es sein, dass das demfall noch eher von C her kommt, wo alles durch einen Paramter durch muss (mal abgesehen von globals)?
-
drakon schrieb:
Kann es sein, dass das demfall noch eher von C her kommt, wo alles durch einen Paramter durch muss (mal abgesehen von globals)?
ja. der fall, daß man out-objekte in der parameterliste hat, ist sehr selten. kommt vielleicht sogar nur als folge schlechter bibliotheken vor (außer beim globalen swap).
wie sieht das eigentlich mit rvalue referenzen aus? ergibt foo const&& f überhaupt sinn? mit && gebe ich f zur stillen zerstörung frei und mit const verhindere ich es wieder. oder hab ich da was falasch verstanden? muß mal nachdenken, was das bewirkt.
-
volkard schrieb:
drakon schrieb:
Kann es sein, dass das demfall noch eher von C her kommt, wo alles durch einen Paramter durch muss (mal abgesehen von globals)?
ja. der fall, daß man out-objekte in der parameterliste hat, ist sehr selten. kommt vielleicht sogar nur als folge schlechter bibliotheken vor (außer beim globalen swap).
Ich verstehe jetzt nicht ganz, was du meinst. Es ging mir darum, dass, wenn du Klasesn hast und eine Member kontrollieren musst, die ihren Zustand wechselt und du wissen musst, wo das passiert, dann musst du unter Umständen jede Funktion, die zur Klasse gehört, wo die Meber drin ist, untersuchen. Und in C++ tendiert ja alles dazu in Klassen zu sein..
-
drakon schrieb:
Es ging mir darum, dass, wenn du Klasesn hast und eine Member kontrollieren musst, die ihren Zustand wechselt und du wissen musst, wo das passiert, dann musst du unter Umständen jede Funktion, die zur Klasse gehört, wo die Meber drin ist, untersuchen. Und in C++ tendiert ja alles dazu in Klassen zu sein..
ja, stimmt.
-
volkard schrieb:
drakon schrieb:
Es ging mir darum, dass, wenn du Klasesn hast und eine Member kontrollieren musst, die ihren Zustand wechselt und du wissen musst, wo das passiert, dann musst du unter Umständen jede Funktion, die zur Klasse gehört, wo die Meber drin ist, untersuchen. Und in C++ tendiert ja alles dazu in Klassen zu sein..
ja, stimmt.
Also verstehe ich das richtig, dass du da in "modernen" C++ Code nicht wirklich was von dieser Technik hast?
Ich habe z.B i.d.R lediglich Zeiger auf Objekte, welche ich rumreiche und schlussendlich ist alles gekapselt. Und somit ist das Objekt immer "geschützt".
-
drakon schrieb:
Also verstehe ich das richtig, dass du da in "modernen" C++ Code nicht wirklich was von dieser Technik hast?
nein. nicht in "modernem" c++, sondern in in einer idealen welt, wo die bibliotheken wohldurchdacht sind.
dort hat die andere technik auch keine nennenswerte wirkung mehr, fürchte ich.
-
drakon schrieb:
...
Man muss nicht auf ein Pferd steigen, bloß weil keiner (mehr) drauf sitzt.
Das war eigl. nur ein kleiner Joke, der gerade gepasst hat, aber ich wollte halt die Idee dahinter verteidigen, welche ich schon auch verstehe. (auch wenn ich es so nicht machen würde..)...
Ich glaube, das hatte ich schon richig verstanden.
drakon schrieb:
...
Aha - das bedeutet: Ich weiß nicht nur NICHT, ob die Funktion nach der "Zeiger=Veränderung"-Regel gestrickt ist, sondern auch nicht, ob die Funktion (wenn sie es denn wäre) den Parameter tatsächlich verändert.
Es geht ja in erster Linie ja nicht darum zu wissen, welche Funktionen etwas verändern, sonder zuerst einmal darum dijenigen herauszufilter, welche es sicher nicht machen....
Aber das Problem ist doch für die Frage "Welche Funktion verändert das garantiert NICHT" analog ....
Naja, egal.Gruß,
Simon2.
-
Simon2 schrieb:
Aber das Problem ist doch für die Frage "Welche Funktion verändert das garantiert NICHT" analog ....
Nein. Du kannst nicht immer alles umkehren.
Wenn ich mit meinem Auto in die Werkstatt gehe und dort festgestellt wird dass die Probleme nicht vom Getriebe verursacht werden, dann weiss ich dennoch nicht wo das Problem liegt. Ich weiß nur wo es nicht liegt.Genauso hier.