3. const bei Variablen als Funktionsparameter

const bei Variablen als Funktionsparameter

  • V

    Eisflamme schrieb:

    Das Weglassen vom top-level-const bezieht sich aber jetzt nur auf Nicht-Zeiger/Nicht-Referenz-Typen, oder? Würde ja auch keinen Sinn ergeben - nur um ganz sicherzugehen.

    Nur um ganz sicherzugehen, welches const meinst Du?

    //     A     B             C      D              E
int const* const foo(int const* const cpci,int const& ri);
    0
  • N

    Eisflamme schrieb:

    Das Weglassen vom top-level-const bezieht sich aber jetzt nur auf Nicht-Zeiger/Nicht-Referenz-Typen, oder? Würde ja auch keinen Sinn ergeben - nur um ganz sicherzugehen.

    "Top-Level" bezieht sich ja gerade auf das äusserste const .

    Referenzen qualifiziert man ohnehin nicht const , und für konstante Zeiger gilt das gleiche wie für andere Parameter (nämlich das, was hustbaer gesagt hat).

    0
  • D

    ISO/IEC 14882:2011 8.3.5 Functions 5

    ... The type of a function is determined using the following rules. The type of each parameter (including function parameter packs) is determined from its own decl-specifier-seq and declarator. After determining the type of each parameter, any parameter of type “array of T” or “function returning T” is adjusted to be “pointer to T” or “pointer to function returning T,” respectively. After producing the list of parameter types, any top-level cv-qualifiers modifying a parameter type are deleted when forming the function type. ...

    0
  • E

    Ich meine C und E, das wäre ja sinnlos, wenn die wegfallen/ignoriert werden.

    Aber den Standardauszug von dd+ hilft mir leider nicht, weil ich decl-specifier-seq, declarator und cv-qualifier nicht verstehe. Wo würde man C-E denn in diese Begriffe einordnen?

    Edit: Ah, nach Nexus' post habe ich erst kapiert, dass ich top-level missverstanden hatte. Trotz der mir fehlenden Begriffsdefinitionen des Standardauszugs verstehe ich diesen nun, danke. 🙂

    0
  • D

    E ist kein top-level Qualifier, denn der Typ ist "Referenz auf const int" und der top-level Typ ist "Referenz", E gehört aber zum untergeordneten Typ "const int"

    cv-qualifier ist const oder volatile

    0
  • E

    Ja, stimmt natürlich, top-level ist das nicht. Nach Verständnis des Wortes "top-level" verstand ich das auch. Gemeint war meine Frage nur darauf bezogen, ob C und E auch ihr const verlieren, was natürlich keinen Sinn ergibt und mir jetzt auch nach Definition klar ist. 🙂 Also C ist demnach ja auch kein top-level, D aber eben schon.

    Danke auch für cv-Qualifier-Erklärung! Ich könnte jetzt noch nachfragen, ob es denn überhaupt noch andere Qualifier gibt, aber ich will den Thread ja nicht sprengen. Außerdem müsste man mir dann vorwerfen, dass ich nicht so faul sein soll und gefälligst selbst Mal im Standard die Definitionen nachlesen könnte.

    0

  • ...

    0
  • D

    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);
    0
  • K

    tommy_tom_tom schrieb:

    Mit -O2 ist's rille wie man's formuliert.

    Ja, ist auch nicht verwunderlich. const existiert im kompilierten Code nicht mehr.

    0
  • S

    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).

    0
  • E

    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.

    0

  • 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.

    0
Anmelden zum Antworten