Konstante Parameter

[JnZn558]

ist es eigentlich sinnvoll kontante parameter zu verwenden. z.B.

int test( const int a, const int b, const int* c ){
   return a + b + *c;
}

oder lieber const float* const c??

[volkard]

Nein.

int test( const int a, const int b, const int* c ){
   int s=0;
   while(a<c)
      a+=b;
   return a;
}

[asc]

JnZn558 schrieb:

ist es eigentlich sinnvoll kontante parameter zu verwenden. z.B.

Kommt meines Erachtens ganz stark auf den Datentyp an:

Bei normalen Datentypen die per Copy-By-Value übergeben werden, macht dies eigentlich niemals Sinn (Betrifft in deinem Fall a und b), bei Referenzen und Zeigern sehe ich dies wieder ganz anders. Da hat ein const durchaus seinen Sinn, um dem Aufrufer zu zeigen: Ich ändere nichts.

Grundsätzlich versuche ich bereits in der Schnittstelle bei Zeigern und Referenzen eindeutig zu zeigen ob ich dafür garantiere, das nichts am Wert geändert wird.

[blue-tec]

Hi,

du sagst dass es bei einem eingebauten Datentyp keinen Performanceunterschied macht ob diese mit const übergeben werden oder nicht. Wenn ich das so richtig verstanden habe, kann es denn nicht sein das spätere Compiler für neuere CPUs daraus doch einen Performancegewinn generieren könnten und es somit durchaus sinnvoll sein kann auch elementare Datentypen ein const zu schenken, wenn sie nicht verändert werden?

Gruß Blue-Tec

[fr33g]

blue-tec schrieb:

Hi,

du sagst dass es bei einem eingebauten Datentyp keinen Performanceunterschied macht ob diese mit const übergeben werden oder nicht. Wenn ich das so richtig verstanden habe, kann es denn nicht sein das spätere Compiler für neuere CPUs daraus doch einen Performancegewinn generieren könnten und es somit durchaus sinnvoll sein kann auch elementare Datentypen ein const zu schenken, wenn sie nicht verändert werden?

Gruß Blue-Tec

Das hast du falsch verstanden
Er meinte wenn die Typen per Copy by value übergeben werden, sprich als Kopie und nicht als Referenz oder Zeiger, dann bringt einem das const ja nicht viel.
Denn bei einer Referenz oder Zeiger beziehen sich eventuelle Änderungen ja auf den ursprünglichen Wert und dort garantierst du ja dann mit einem const, dass der Wert nicht geüändert wird. Aber bei copy by value, kannst du den ursprünglichen Wert ja gar nicht ändern

Verstanden?

Lg freeG

[blue-tec]

Genau so hatte ich es auch verstanden, aber es anscheinend zu kompliziert beschrieben. Also noch mal meine Frage vereinfacht:

Bringt const bei Übergabe eines elementaren Datentyps(z.B int) einen Geschwindigkeitsvorteil?
Das wurde mit nein beantwortet. Meine Frage war nun ob nicht eventuell spätere Compiler, für neue CPUs, doch aus diesem const ein Vorteil ziehen könnten in Bezug auf Performance? Weil, keine Ahnung, es neue Opcodes gibt die irgendwas anders machen.

Gruß Blue-Tec

[SeppJ]

Nein, const gibt nie Performancevorteile, das ist ein Konstrukt einzig dazu da, die Absicht des Programmierers deutlich zu machen. Mit viel Mühe kann man eventuell Ausnahmefälle konstruieren, wo es ein ganz kleines bisschen bringen könnte, aber das ist definitiv nicht die Regel und wird es auch nie sein.

edit: Eine wichtige Ausnahme die ich vergessen habe sind Compilezeitkonstanten, die direkt eingesetzt werden können. Aber Variablen die erst zur Laufzeit feststehen als const zu markieren bringt keine Performance.

[asc]

SeppJ schrieb:

Nein, const gibt nie Performancevorteile...

Diese Aussage stimmt so nicht ganz. Ja, man kann, und sollte auch nicht davon ausgehen, das const automatisch einen Performancegewinn bedeutet. Aber in bestimmten Bereichen kann es unter Umständen zu Compileroptimierungen führen.

[blue-tec]

asc schrieb:

SeppJ schrieb:

Nein, const gibt nie Performancevorteile...

Diese Aussage stimmt so nicht ganz. Ja, man kann, und sollte auch nicht davon ausgehen, das const automatisch einen Performancegewinn bedeutet. Aber in bestimmten Bereichen kann es unter Umständen zu Compileroptimierungen führen.

Danke, so hatte ich das auch in Erinnerung und wollte es nur noch mal bestätigt haben.

Gruß Blue-Tec

[SeppJ]

asc schrieb:

SeppJ schrieb:

Nein, const gibt nie Performancevorteile...

Diese Aussage stimmt so nicht ganz. Ja, man kann, und sollte auch nicht davon ausgehen, das const automatisch einen Performancegewinn bedeutet. Aber in bestimmten Bereichen kann es unter Umständen zu Compileroptimierungen führen.

Deswegen habe ich die Aussage im nächsten Satz ja auch ein bisschen eingeschränkt. Aber zeig mir einen einzigen Fall außer Compilezeitkonstanten, wo tatsächlich etwas optimiert werden kann. Ganz schön schwer, so etwas zu konstruieren, nicht wahr?

[Nexus]

asc schrieb:

[...] bei Referenzen und Zeigern sehe ich dies wieder ganz anders. Da hat ein const durchaus seinen Sinn, um dem Aufrufer zu zeigen: Ich ändere nichts.

Stimmt, aber da ist ja auch nicht der Parameter const -qualifiziert, sondern das referenzierte Objekt.

Wir können also festhalten: Top-Level-CV-Qualifizierungen machen in der Schnittstelle der Funktion keinen Sinn.

[Eisflamme]

volkard:
Den Code verstehe ich überhaupt nicht, was hat das mit der Frage zu tun und wieso versuchst du diesen const Paramter zu ändern und wieso gibt es die lokale Variable s?

[volkard]

Eisflamme schrieb:

volkard:
Den Code verstehe ich überhaupt nicht, was hat das mit der Frage zu tun

Man schreibt eben gerne mal Funktionen, die die Parameter verändern.

und wieso versuchst du diesen const Paramter zu ändern

Unm zu zeigen, daß const hier stört.

und wieso gibt es die lokale Variable s?

Altlasten. Zuerst wollte ich was aufsummieren.

Überzeugendere Const-Ist-Quatsch-Beweise würden in diese Richtung http://pizer.wordpress.com/2009/06/25/c-exploiting-copy-elisions/ gehen.

[Nexus]

Herb Sutter:

<a href= schrieb:

http://www.gotw.ca/gotw/006.htm">Since the point object is passed by value, there is little or no benefit to declaring it const.
Normally const pass-by-value is unuseful and misleading at best.

[blue-tec]

Was mir jetzt zu const und Compileroptimierung einfällt ist, dass es doch der Compiler mit Sicherheit merkt ob in einer Funktion/Methode ein Wert verändert wird und dem entsprechend optimiert. Also nimmt das const dann doch mehr die Rolle des Überschreibschutzes ein als die Rolle einer Geschwindigkeitsoptimierung, jedenfalls bei elementaren Datentypen.

[asc]

blue-tec schrieb:

Was mir jetzt zu const und Compileroptimierung einfällt ist, dass es doch der Compiler mit Sicherheit merkt ob in einer Funktion/Methode ein Wert verändert wird und dem entsprechend optimiert.

Wenn der Compiler weiß, das eine Variable innerhalb eines Kontext unveränderlich ist, kann er Annahmen treffen die, die Performace theoretisch beeinflussen können (unabhängig von Compilezeitkonstanten).

Ob das in der Praxis aber eine Auswirkung hat, bleib dahin gestellt.

[Nexus]

blue-tec schrieb:

Was mir jetzt zu const und Compileroptimierung einfällt ist, dass es doch der Compiler mit Sicherheit merkt ob in einer Funktion/Methode ein Wert verändert wird und dem entsprechend optimiert. Also nimmt das const dann doch mehr die Rolle des Überschreibschutzes ein als die Rolle einer Geschwindigkeitsoptimierung, jedenfalls bei elementaren Datentypen.

Wie du vom ersten Satz auf den zweiten schliesst, ist mir nicht ganz klar. Das klingt für mich eher widersprüchlich.

Wie genau soll der Compiler im allgemeinen Fall bei const optimieren? Bei Referenzen und Zeigern auf const weiss er ja nicht, ob das Originalobjekt tatsächlich const -qualifiziert ist. const_cast ist in einem gewissen Rahmen ebenfalls erlaubt.

Jedenfalls ist es ein Irrglaube, dass const die Performance entscheidend verbessert. Es kann in vereinzelten Fällen vorkommen, aber dass nicht andere Programmteile viel zeitkritischer sind, kommt ziemlich selten vor.

[SeppJ]

Um mal zu erklären, warum const selten Optimierung erlaubt, die ohne const nicht da wäre:
a) mutable : Die Möglichkeit, dass eine Klasse mutable Member enthält, lässt keine Möglichkeit zu aus, bloß aus const zu folgern, dass tatsächlich sich nichts verändert.
b) volatile : Siehe oben
c) Wenn sich tatsächlich nichts ändert, sieht das der Compiler direkt am erzeugten Maschinencode, egal ob im ursprünglichen Code einmal const stand oder nicht und kann entsprechend optimieren (Ausnahme: volatile-Member, aber volatile soll ja gerade solche Optimierungen verhindern).

http://www.informit.com/guides/content.aspx?g=cplusplus&seqNum=372

edit: Da war Nexus schneller als ich. Ob er wohl const-qualifiziert ist?

[blue-tec]

Nexus schrieb:

blue-tec schrieb:

Was mir jetzt zu const und Compileroptimierung einfällt ist, dass es doch der Compiler mit Sicherheit merkt ob in einer Funktion/Methode ein Wert verändert wird und dem entsprechend optimiert. Also nimmt das const dann doch mehr die Rolle des Überschreibschutzes ein als die Rolle einer Geschwindigkeitsoptimierung, jedenfalls bei elementaren Datentypen.

Wie du vom ersten Satz auf den zweiten schliesst, ist mir nicht ganz klar. Das klingt für mich eher widersprüchlich.

Wie genau soll der Compiler im allgemeinen Fall bei const optimieren? Bei Referenzen und Zeigern auf const weiss er ja nicht, ob das Originalobjekt tatsächlich const -qualifiziert ist. const_cast ist in einem gewissen Rahmen ebenfalls erlaubt.

Jedenfalls ist es ein Irrglaube, dass const die Performance entscheidend verbessert. Es kann in vereinzelten Fällen vorkommen, aber dass nicht andere Programmteile viel zeitkritischer sind, kommt ziemlich selten vor.

Ich wollte damit ausdrücken dass const nicht zur Steigerung der Performance beträgt sondern eher als ein Schutz gegen ungewolltes Überschreiben da ist.

Ist das bei Objekten aus selbst erstellten Datentypen dann anders?

[SeppJ]

blue-tec schrieb:

Ich wollte damit ausdrücken dass const nicht zur Steigerung der Performance beträgt sondern eher als ein Schutz gegen ungewolltes Überschreiben da ist.

Ist das bei Objekten aus selbst erstellten Datentypen dann anders?

Eben nicht. Das was du beschreibst ist sogar die eigentliche Aufgabe von const. Eventuelle Performancevorteile die vielleicht unter gewissen Umständen auftauchen könnten, sind ein seltener Nebeneffekt.