danke für jede Antwort

lg c4f

Da kommt hinzu, dass man kopierte Objekte nicht verändern kann, per Referenz übergebene jedoch schon. Willst du sie trotzdem nicht verändern, aber wegen Geschwindigkeit als Referenz übergeben, kannst du das mit einer konstanten Referenz lösen.

wenn der copy-ctor trivial genug ist lohnt es sich ebenfalls auf (const) referenzen zu verzichten.
referenzen sind ja auch nichts anderes, als pointer (die intern verwaltet werden) - also müssen sie auch (intern) dereferenziert werden...

also _kann_ es (rein theoretisch) auch noch effektiver sein, ein 10 byte großes objekt per value und nicht per referenz zu übergeben - aber das muss man sich natürlich immer selbst überlegen und zur not mal mit dem profiler bissl rumspielen und vergleichen...

bb

das muss man sich natürlich immer selbst überlegen und zur not mal mit dem profiler bissl rumspielen und vergleichen...

Da möchte ich mal das zur Not hervorheben. Der c-tor wird in kaum einem Fall ein Problem werden, was die Geschwindigkeit anbelangt. Ich kann mir da kaum ein (realistisches) Szenario vorstellen, wo ein c-tor wirklich Geschwindigkeitsprobleme machen kann.

Ansonsten kann ich nur sagen, dass du hald von Fall zu Fall überlegen musst, was jetzt geeigneter ist. (Und mal nicht auf Geschwindigkeit achten). Sondern eher, wie es für den Programmierer/Leser ist. Also Handbarkeit, Sicherheit, Lesbarkeit usw.

Ob nun "call by value" oder "call by reference" das richtige ist, diese Frage stellte sich nur, wenn man sich vorher sicher war, ob man einen einer Funktion übergeben Wert verändern möchte oder nicht.

Nein, eben nicht. Referenzen haben abgesehen von der Möglichkeit zur Veränderbarkeit wie gesagt den Vorteil, dass grosse Objekte nicht kopiert werden müssen. Wieso sollte es sonst Const-Referenzen geben?

Und was die Geschwindigkeit angeht: Meistens hat man eh nicht so zeitkritische Bedingungen, dass man bei 10 Byte grossen Objekten überlegen muss, ob jetzt ein Call by Value oder Call by Reference von Vorteil ist. Ich würd mir einfach merken, Elementardatentypen sowie Typedefs von solchen und Enums zu kopieren, während grössere Datentypen wie Klassen als Referenz übergeben werden.

Und falls man doch derart mikrooptimieren muss, gibts ja wie gesagt noch Profiler.

lg c4f

Der c-tor wird in kaum einem Fall ein Problem werden, was die Geschwindigkeit anbelangt. Ich kann mir da kaum ein (realistisches) Szenario vorstellen, wo ein c-tor wirklich Geschwindigkeitsprobleme machen kann.

Ich schon...

class Matrix
{
std::vector < std::vector < my::BigInt > > array;
/*etc*/
};

Is nat nur ein Bsp. und das BigInt soll andeuten, dass die Zahl an sich auch noch mal bissl mehr zu kopieren sein könnte als nen einfacher int...
Klar ist das heutzutage üblicherweise zu vernachlässigen, aber auch nur, so lange man sich in nem rel. "normalen" Rahmen aufhält...

bb

Berufspenner schrieb:

Ob nun "call by value" oder "call by reference" das richtige ist, diese Frage stellte sich nur, wenn man sich vorher sicher war, ob man einen einer Funktion übergeben Wert verändern möchte oder nicht.

Nein, eben nicht. Referenzen haben abgesehen von der Möglichkeit zur Veränderbarkeit wie gesagt den Vorteil, dass grosse Objekte nicht kopiert werden müssen. Wieso sollte es sonst Const-Referenzen geben.

Stimmt, da hast du recht. Ich hab es gerade eher im Kleinen und nicht im Ganzen betrachtet.

Is nat nur ein Bsp. und das BigInt soll andeuten, dass die Zahl an sich auch noch mal bissl mehr zu kopieren sein könnte als nen einfacher int...
Klar ist das heutzutage üblicherweise zu vernachlässigen, aber auch nur, so lange man sich in nem rel. "normalen" Rahmen aufhält...

bb

Ich habe nicht gesagt, dass es nicht auch sehr viel Zeit in Anspruch nehmen kann, sondern, dass ich mir keine realistisches Szenario vorstellen kann, wo das wirklich etwas ausmacht. Da hast du andere Probleme, als einen grossen c-tor.

Ich denke, mit der von mir geposteten Grundregel oben fährt man eigentlich gut

Offtopic (sorry musste sein :D):

drakon
Mitglied

Benutzerprofil
Anmeldungsdatum: 28.01.2008
Beiträge: 1337