Sind Pointer als Funktionsparameter schneller als Objekte?

[Nexus]

krümelkacker schrieb:

Für denjenigen, der solche Funktionen nutzt, ist es egal.

Ich bin zumindest kurz verwirrt, wenn ich in die Deklaration anschaue, dort ein const sehe und dann merke, dass es sich doch um einen Value-Parameter handelt (normalerweise assoziiere ich const in Parameterlisten mit Zeigern/Referenzen auf konstante Objekte). Da es für den Aufrufer auch keinen Unterschied macht, hat das const meiner Meinung nach nichts in der Schnittstelle zu suchen.

krümelkacker schrieb:

Das const ist trotzdem erlaubt und hindert Dich bei der Implementierung daran, den Parameter zu ändern. Es macht also schon Sinn.

Das ist mir bewusst. Und genau hier liegt mein Problem: Ich verstehe nicht ganz, weshalb der Funktion verboten wird, die Kopie zu verändern. Das kann der Aussenwelt ja egal sein. Ich meine, sie kann trotzdem immer noch beliebig viele Kopien anfertigen, aber auf diese Weise geht man unnötige Nachteile ein (mehr Code, schlechtere Performance).

Mir ist auch nicht ganz klar, inwiefern const -qualifizierte Value-Parameter von Vorteil für die Optimierung sein sollen. Bei temporären Objekten spielt es keine Rolle, ob das Argument verändert wird, und ansonsten muss sowieso eine Kopie angefertigt werden, da wäre const nur einschränkend. Oder übersehe ich etwas?

krümelkacker schrieb:

Genau, und der letzte Fall ist auch der, der bei der Parameterübergabe andwendbar ist.
[...]
Nein, so funktioniert das nicht. Wenn es sich um nicht trivial kopierbare Parameter/Return Typen handelt, werden beim GCC Zeiger übergeben. Das wird nicht vom Standard erzwungen, ist aber eine Implementierungsmöglichkeit, die genutzt werden kann, um intensiv "copy elisions" durchführen zu können. Der Trick dabei ist der, dass der Aufrufer einer Funktion entsprechend eine Kopie (falls nötig) eines pass-by-value Parameters anfertigt bzw Platz für das Rückgabebjekt schafft und die Adresse an die Funktion übergibt.

Okay, so ist es klar. Ich habe dich falsch verstanden (nämlich so, dass die besagte Regel für alle Argumente gelte und nicht nur für Temporaries). Wenn der G++ bei nicht-temporären Objekten schön eine Kopie anlegt, ist ja alles in Ordnung. Vielen Dank für die ausführliche Erklärung und das Codebeispiel!

Edit: Der letzte Absatz bezieht sich nur auf die Notwendigkeit zu kopieren. Die oberen Fragen sind immer noch offen.

[krümelkacker]

Nexus schrieb:

krümelkacker schrieb:

Für denjenigen, der solche Funktionen nutzt, ist es egal.

Ich bin zumindest kurz verwirrt, wenn ich in die Deklaration anschaue, dort ein const sehe und dann merke, dass es sich doch um einen Value-Parameter handelt (normalerweise assoziiere ich const in Parameterlisten mit Zeigern/Referenzen auf konstante Objekte).

Da es für den Aufrufer auch keinen Unterschied macht, hat das const meiner Meinung nach nichts in der Schnittstelle zu suchen.

Ich habe nicht gesagt, dass es für DeKLARAtion auch sinnvoll ist oder überhaupt irgend einen Effekt hat.

Nexus schrieb:

krümelkacker schrieb:

Das const ist trotzdem erlaubt und hindert Dich bei der Implementierung daran, den Parameter zu ändern. Es macht also schon Sinn.

Das ist mir bewusst. Und genau hier liegt mein Problem: Ich verstehe nicht ganz, weshalb der Funktion verboten wird, die Kopie zu verändern.

Wenn Du es verändern willst, stellt sich die Frage nach "const T&" vs "const T" einfach nicht. Natürlich gibt es Fälle, in denen Du nichts verändern musst und auch keine Kopie erstellen musst. Dann stellt sich die Frage "Referenz oder nicht?". Und ein const auch ohne Referenz wäre primär dazu da, Programmierfehler zu reduzieren. Wenn Du nicht vorhast, es zu verändern, und Du const benutzt, dann macht der Compiler dich schon eher darauf aufmerksam, wenn Du versehentlich etwas machst, was Du eigentlich nicht wolltest.

[Simon2]

SeppJ schrieb:

@Simon2: Ist das denn das Ergebnis eines optimierenden Compilers?
...

Gemeint war es eben als NICHT-optimierter Code!

Hintergrund ist:
- Ein Optimierer lässt aufgrund einer (vom Hersteller ausgedachten) Heuristik bestimmte Operationen/Optionen weg, die aber im Standard prinzipiell be-/vorgeschrieben sind.
- Ich habe ein Verhalten vor Augen, das bereits der Standard vorschreibt.
Ist zwar nur ein feiner Unterschied, aber bisweilen sind auch die interessant.
Mir kräuseln sich halt bei solchen Pauschalaussagen (auch, wenn sie eigentlich nicht als solche gemeint sind) wie "Referenzen sind auch nur Zeiger" die Fußnägel hoch, weil sich diese "Spezialfallbeschreibung" schnell zur "Eselbrücke" und bald auch zum "Lehrsatz" entwickeln.
Und in C++ werden Referenzen in vielen Zusammenhängen ganz anders behandelt als Zeiger. Und zwar in einer Art und Weise, dass ein Compiler bereits wissen kann, was er weglassen darf und nicht "raten" muss.

Aber natürlich: Reale (und erst recht ideale) Optimierer werden in zahllosen Fällen zum selben Ergebnis im Binary führen...

Gruß,

Simon2.

[Nexus]

krümelkacker schrieb:

Ich habe nicht gesagt, dass es für DeKLARAtion auch sinnvoll ist oder überhaupt irgend einen Effekt hat.

Gut, dann sind wir uns ja einig.

Ich dachte eben, du würdest dich generell für const bei Wert-Parametern aussprechen. In der Definition kann man das machen, halt wie man sonstige Konstanten deklariert. Ich persönlich fänds aber übertrieben, alle Parameter und lokalen Objekte, welche nicht verändert werden, als const zu deklarieren. Ich heb mir const lieber für die "wichtigen" Dinge auf. Aber das geht dann Richtung Codestil...