call by reference?
-
Bei PODs: nein,
bei eigenen kleinen Datentypen: nein,
bei fetten Brummern: ja.
-
Im Bezug auf die Frage wann man const& T verwenden soll.
-
Sorry, bin nicht der klügste:
Was sind POD'S?
Sind das die eingebauten Datentypen wie int, float u.s.w.?
-
|M| schrieb:
Was sind POD'S?
]
Unter POD'S versteht man im englischen die Dinge die POD gehoeren, im Deutschen gibts nicht mal fuer das besitzanzeigende einen Apostroph.
Im Grunde sollte es eher built-in Types heissen, den PODs sind auch umfangreiche Strukturen, gemeint sind auf jeden Fall die eingebauten Datentypen!
-
POD = Plain Old Data
die guten alten Daten
-
Das wichtigste steht schon da, immer const wenn const geht.
Das zweit-wichtigste steht im Prinzip auch schon da, nämlich keine const Referenzen für kleine & billigst zu kopierende Dinge verwenden wie eben ints, longs oder doubles, oder auch Instanzen von klitzekleinen Klassen. Wo man die Grenze ziehen soll ist schwer zu sagen, aber ich denke 8 oder 16 Byte sind wohl nicht ganz verkehrt.
----
Sobald man halt ein Objekt an eine Referenz bindet die ein Parameter für eine Funktion ist macht man damit ja die Adresse des Objektes der entsprechenden Funktion bekannt. Wenn der Compiler die Implementierung der Funktion nicht sehen kann, hat er keine Chance rauszubekommen was die Funktion mit dieser Adresse gemacht hat, und muss davon ausgehen, dass z.B. jeder globale Zeiger u.U. jetzt auf das Objekt zeigt, bzw. jeder Programmteil nun dieses Objekt modifizieren oder auslesen kann. Ergo muss er an vielen Stellen wo es sonst nicht notwendig wäre Werte in das Objekt zurückschreiben bzw. neu davon einlesen -- wo er normalerweise die Werte in einem Register halten hätte können.
Und wenn das Objekt dessen Adresse man so bekannt macht Teil eines grösseren Objektes ist (z.B. ein Feld in einem Array, oder auch ein Member einer Klasse), dann wird ein "vorsichtiger" Compiler auch davon ausgehen dass das grössere Objekt nun global bekannt ist, und auch dort viele Optimierungen weglassen.
In vielen Fällen ist es egal, da in grossen, komplexen Programmen die Adressen der meisten Objekte sowieso "global bekannt" sind, aber wenigstens in diversen Performance-Kritischen Teilen kann man darauf achtgeben sich durch das "bekanntmachen" von Adressen nicht die Performance zu versauen.
-
cdfgasg schrieb:
Bei PODs: nein,
bei eigenen kleinen Datentypen: nein,
bei fetten Brummern: ja.es gibt auch fette PODs. ätsch!
alles, was man sonst mit call-by-value machen würde und fett ist, sollte stattdessen call by const-reference sein.
(ausnahme ist ein seltener fall, wo verdammt viele operationen auf dem objekt stattfinden, so richtig O(n^3) mal oder so.)
fett ist dabei meistens zeugs, das mehr bytes hat als der datenbus. also wenn sizeof(Object)>sizeof(long) dürfte man generell an const-referenzen denken.
-
volkard schrieb:
...
fett ist dabei meistens zeugs, das mehr bytes hat als der datenbus. also wenn sizeof(Object)>sizeof(long) dürfte man generell an const-referenzen denken.Das ist mal eine interessante, plausible und hilfreiche Definition für "fett".
Danke,
Simon2.
-
volkard schrieb:
fett ist dabei meistens zeugs, das mehr bytes hat als der datenbus. also wenn sizeof(Object)>sizeof(long) dürfte man generell an const-referenzen denken.
Genauso wenn das Objekt einen eigenen Kopier-Konstruktor mitbringt, könnte es zumindest eine gute Idee sein, auf Referenzen zu wechseln (selbst wenn das Objekt an sich "klein" ist, kann es ziemlich viele Daten hinterherschleppen)
-
Joa; da hab ich ja ne schöne Gesprächsrunde auf die Beine gestellt.
DANKE an ALLE!
PS: Ich liebe dises Forum!
