const bei Variablen als Funktionsparameter

Shade Of Mine

dd++ schrieb:

kurze Zusammenfassung: in folgendem Code sind die Deklarationen für f und g gleich, für h werden aber 2 versch. Funktionen deklariert
void f (      int i);
void f (const int i);
void g (int *       pi);
void g (int * const pi);
void h (      int * pci);
void h (const int * pci);

Nur zur Ergänzung: das ganze wird logischer wenn man es so schreibt:

void f (int       i);
void f (int const i);
void g (int *       pi);
void g (int * const pi);
void h (int       * pci);
void h (int const * pci);

[/quote]
Dann ist nämlich immer wenn const das rechteste Element in der deklaration ist, das const nicht teil der funktionssignatur.

Ich persönlich schreibe deshalb lieber das const auf die rechte Seite - es liest sich dann auch logischer (von rechts nach links).

Eisflamme

knivil:
Aber wenn das Ding nicht konstant ist und sich ändern könnte, kann der Compiler es ja nicht so gut rausoptimieren wie eine klare Konstante

- wobei er vermutlich selbst merkt, dass kein Schreibzugriff erfolgt und es somit konstantiert.

hustbaer

Eisflamme schrieb:

knivil:
Aber wenn das Ding nicht konstant ist und sich ändern könnte, kann der Compiler es ja nicht so gut rausoptimieren wie eine klare Konstante

const heisst nur "du darfst nix ändern", nicht "da ändert sich nix".
-> der Compiler kann es sowieso nicht optimieren, ohne zu sehen was alle beteiligten Programmteile genau machen. Und dann kann er es sowieso, egal wie das Programm genau geschrieben ist.

Beispiel:

typedef void Callback();
void Foo(int const* p, Callback* cb)
{
    printf("%d\n", *p);
    cb();
    printf("%d\n", *p);
}

Und

#include <foo.hpp>

int x = 0;
void ModifyX()
{
    x++;
}

int main()
{
    Foo(&x, &ModifyX);
}

Ist auch ein gutes Beispiel dafür warum Aufrufe über Funktionszeiger bzw. virtuelle Methodenaufrufe so pöse Optimierungs-Barrieren sind.