C++ - Für was sind "const" funktionen?

[Forest D. (thecomet)]

Hallo zusammen. Kann mir mal jemand sagen wofür dieses "const" ist vor 
der Funktion?

const vec3 operator+( vec3 &e )

Und was ist der unterschied zwischen dem und wenn ich es erst am schluss 
schreibe?

vec3 operator+( vec3 &e ) const

Kann man auch "const" weglassen?

Hier das Ganze:

// Overloading Operators
// by Forest DUMP

#include <iostream>
#include <iomanip>

using namespace std;

// ---------------------------------------------------------------------------------
// vector 3 class
class vec3
{
    public:

        // vector 3 elements
        float x;
        float y;
        float z;

        // overload operators
        const vec3 operator+( vec3 &e );

        // constructor, destructor
        vec3( void );
        vec3( float x, float y, float z );
        ~vec3();
};

// ---------------------------------------------------------------------------------
// ability to set values on creation in the constructor
vec3::vec3(float x, float y, float z)
{
    this->x = x;
    this->y = y;
    this->z = z;
}

// ...or not
vec3::vec3( void )
{
}

// ---------------------------------------------------------------------------------
// destructor
vec3::~vec3()
{
}

// ---------------------------------------------------------------------------------
// Overload plus operator
const vec3 vec3::operator+( vec3 &e )
{
    vec3 result;
    result.x = x + e.x;
    result.y = y + e.y;
    result.z = z + e.z;
    return result;
}

// ---------------------------------------------------------------------------------
// main entry point (I think DarkGDK has some other form of this)
int main( int argc , char* argv[] )
{

    // define 2 vector objects
    vec3 myVector1(4, 4, 4);
    vec3 myVector2(6, 7, 3);

    // add vectors together and store in result vector
    vec3 result;
    result = myVector1 + myVector2;

    // output vectors
    cout << "Vector 1 : " << myVector1.x << "," << myVector1.y << "," << myVector1.z << endl;
    cout << "Vector 2 : " << myVector2.x << "," << myVector2.y << "," << myVector2.z << endl;
    cout << "result : " << result.x << "," << result.y << "," << result.z << endl;

    // end program
    cin.ignore();
    return 0;
}

[(prx) A. K. (prx)]

const vorne: bezieht sich auf die retournierten Daten.

const hinten: bezieht sich auf die Funktion. Eine Funktion, die den 
Zustand des Objekts nicht verändert (=> mögliche Optimierung).

[Peter II (Gast)]

> const vec3 operator+( vec3 &e )

liefer ein vec3 zurück der aber const ist, er darf/kann also nicht 
veändert werden. Macht aber nicht so viel sinn, wird im zusammenhang mit 
referenz verwenden.

z.b.

const vec3& operator+( vec3 &e )

damit verhindert man, das jemand ein objekt was man nur als Referenz 
rausgibt ändert.

Und was ist der unterschied zwischen dem und wenn ich es erst am schluss
schreibe?

vec3 operator+( vec3 &e ) const

hier sagt das const, das das objekt von der methode nicht durch den 
methoden aufruf geändert wird. (gibt auch wieder ausnahmen (mutable)

Kann man auch "const" weglassen?
kann man, aber ist sollte man nicht.

[Forest D. (thecomet)]

Aah, das ergibt jetzt ja viel mehr Sinn. Das heisst also dass das hier 
nicht funktionieren würde?

vec3 vec3::operator+( vec3& e ) const
{
   vec3 result;
   this->x = 10;        // Würde nicht funktionieren?
   return result;
}

Aber ohne das "const" würde das gehen?

[Peter II (Gast)]

Forest Dump schrieb:
> Das heisst also dass das hier
> nicht funktionieren würde?

wenn x nicht mutable ist - ja.

[Forest D. (thecomet)]

Super, vielen Dank!

[Forest D. (thecomet)]

Nochmals eine kleine Frage, was machen diese zwei consts die 
unterstrichen sind?

const int* const Method3(const int* const & ) const;

[(prx) A. K. (prx)]

Beide gleich: konstante Zeiger. In zweiten Fall als Referenz darauf.

Die Syntax von Typdeklarationen in C und infolgedessen C++ ist 
hoffnungslos verhunzt, da ist nichts mehr zu retten. Daher diese 
Konfusion. Mit Googles Go bin ich erstmals einer in syntaktischer 
Tradition von C stehenden Sprache begegnet, die sich davon etwas ablöst.

[Rolf Magnus (Gast)]

A. K. schrieb:
> Beide gleich: konstante Zeiger. In zweiten Fall als Referenz darauf.
>
> Die Syntax von Typdeklarationen in C und infolgedessen C++ ist
> hoffnungslos verhunzt, da ist nichts mehr zu retten.

Na komm, so schwer ist das in diesem Fall auch nicht. const bezieht sich 
immer auf das, was direkt links davon steht, mit einer Ausnahme:  Wenn 
links nichts mehr ist, bezieht es sich auf das, was direkt rechts davon 
steht.
Richtig lustig wird's eigentlich erst, wenn man Funktionen deklariert, 
die mit Funktionszeigern arbeitet. Ein gerne genommenes Beispiel ist die 
Standard-Funktion signal(), deren Deklaration so aussieht:

void (*signal(int signum, void (*handler)(int)))(int);

Aber auch das läßt sich mit einem Typedef entschärfen:

typedef void (*sighandler_t)(int);

sighandler_t signal(int signum, sighandler_t handler);

> Mit Googles Go bin ich erstmals einer in syntaktischer Tradition von C
> stehenden Sprache begegnet, die sich davon etwas ablöst.

Bei Java hat man das gelöst, indem man einfach die Hälfte weggelassen 
hat.

[Yalu X. (yalu) (Moderator)]

Rolf Magnus schrieb:
> Na komm, so schwer ist das in diesem Fall auch nicht. const bezieht sich
> immer auf das, was direkt links davon steht, mit einer Ausnahme:  Wenn
> links nichts mehr ist, bezieht es sich auf das, was direkt rechts davon
> steht.

Ich hätte eher gesagt, const bezieht sich in C immer auf das, was direkt
rechts daneben steht, und das ohne Ausnahme, also noch einfacher.

In C++ gibt es noch das const rechts neben einer Funktionsdeklaration.
Da kann diese Regel natürlich nicht gelten, aber hier hat const auch
eine ganz andere Bedeutung, weswegen man es sich getrennt merken muss.
Da wurde einfach nur Schlüsselwortrecycling gemacht, ähnlich wie bei
static, wenn es außerhalb eines Funktionsrumpfs benutzt wird.

Eigentlich ist die Typdeklaration in C und C++ ziemlich logisch und
konsistent, wenn man das Prinzip erst mal kapiert hat. Am besten ist es,
man arbeitet sich von innen, beginnend mit dem deklarierten Variablen-
namen, nach außen.

[Rolf Magnus (Gast)]

Yalu X. schrieb:
> Rolf Magnus schrieb:
>> Na komm, so schwer ist das in diesem Fall auch nicht. const bezieht sich
>> immer auf das, was direkt links davon steht, mit einer Ausnahme:  Wenn
>> links nichts mehr ist, bezieht es sich auf das, was direkt rechts davon
>> steht.
>
> Ich hätte eher gesagt, const bezieht sich in C immer auf das, was direkt
> rechts daneben steht, und das ohne Ausnahme, also noch einfacher.

Das ist aber falsch.

// zweimal ein nichtkonstanter Zeiger auf einen konstanten int
int const * p1;
const int * p2;

// ein nichtkonstanter Zeiger auf einen konstanten Zeiger
// auf einen konstanten int
int const * const * p3;

> In C++ gibt es noch das const rechts neben einer Funktionsdeklaration.
> Da kann diese Regel natürlich nicht gelten, aber hier hat const auch
> eine ganz andere Bedeutung.

Dennoch gilt aber meine Regel auch da: const bezieht sich auf die 
Funktion, also das Mehod3(...), was links davon steht.

[(prx) A. K. (prx)]

Klar, man kann damit umgehen, aber es bleibt Murks, der sich ergab, weil 
in Deklarationen abgeleitete Typen teils durch ein Symbol links vom 
Namen (pointer) und teils rechts vom Namen (array, function) 
gekennzeichnet werden.

Und sich folglich abgeleitete Typen ineinander schachteln, statt sich 
einfach linear aufzureihen.

Weiter verkompliziert wurde es dadurch, dass Klammern darin zweierlei 
verschiedene Bedeutungen haben, nämlich Funktionen und Prioritäten. Was 
in C++ zur Folge hat, dass
  int(a);
eigentlich gleichermassen Typumwandlung und Deklaration mit unnötiger 
Klammer sein könne.

Für die natürliche Platzierung von const und volatile entsprechend der 
Umgangssprache war schlussendlich kein Platz mehr, so dass die an für 
Anfänger irritierende Stellen wanderten. Ausser anfangs beim strukturell 
ähnlichen _far - das landete da, wo es der Anfänger vermutet aber es von 
der syntaktischen Logik her nicht hingehört.

Das ist schlicht ein Konstruktionsfehler von C.

[Yalu X. (yalu) (Moderator)]

Rolf Magnus schrieb:
> Das ist aber falsch.

Ich glaube eher, wie haben eine Unterschiedliche Leseweise für
Typdeklarationen.

> // zweimal ein nichtkonstanter Zeiger auf einen konstanten int
> int const * p1;

Mit meiner oben vorgeschlagenen "Von-Innen-Nach-Außen-Methode" (die IMHO
auch Ritchie bei der Konzeptioen der Deklarationssystax im Kopf gehabt
hat) lese ich das so:

p1 dereferenziert ist konstant und vom Typ int.

> const int * p2;

p2 dereferenziert ist vom Typ int und dieser int-Wert ist konstant.

> // ein nichtkonstanter Zeiger auf einen konstanten Zeiger
> // auf einen konstanten int
> int const  const  p3;

p3 dereferenziert ist konstant,
nochmals dereferenziert ist er wieder konstant und vom Typ int.

Diese Leseweise mag nach holprigem Deutsch aussehen, ist aber bei der
systematischen Analyse und Synthese stark verschachtelter Deklarationen
mit durchmischten Pointern, Arrays und Funktionspointern von Vorteil.

>> In C++ gibt es noch das const rechts neben einer Funktionsdeklaration.
>> Da kann diese Regel natürlich nicht gelten, aber hier hat const auch
>> eine ganz andere Bedeutung.
>
> Dennoch gilt aber meine Regel auch da: const bezieht sich auf die
> Funktion, also das Mehod3(...), was links davon steht.

Man könnte auch sagen, das const bezieht sich auf die Membervariablen,
die von der Methode nicht verändert werden. Dadurch, dass rechts vom
const nichts steht, wird angezeigt, dass die konstanten Dinge woanders
stehen, nämlich dort, wor die Membervariablen deklariert sind. Insofern
gilt meine Regel ebenfalls :)

[(prx) A. K. (prx)]

Nur zur Erinnerung: Die Reihenfolge der Schlüsselworte vor dem "*" ist 
irrelevant. Ob man
  long int extern const *p;
oder
  extern int const long *p;
oder
  const long extern int *p;
schreibt ist schnurzpiepegal. Es landet alles im gleichen Topf.

[Juergen (Gast)]

Yalu X. schrieb:
>> int const * p1;
>
> Mit meiner oben vorgeschlagenen "Von-Innen-Nach-Außen-Methode" (die IMHO
> auch Ritchie bei der Konzeptioen der Deklarationssystax im Kopf gehabt
> hat) lese ich das so:
>
> p1 dereferenziert ist konstant und vom Typ int.

Das ist falsch, const bezieht sich hier auf int.

>> const int * p2;
>
> p2 dereferenziert ist vom Typ int und dieser int-Wert ist konstant.

Das ist richtig.  Bei

int const * p1;
const int * p2;

haben p1 und p2 den gleichen Typ!

Für einen konstanten Zeiger mußt du

int * const p3;

schreiben.

Manche Leute schreiben die Qualifier auch einheitlich rechts neben den 
Typ, auf den sie sich beziehen.

Jürgen

[(prx) A. K. (prx)]

Juergen schrieb:
>> p1 dereferenziert ist konstant und vom Typ int.
>
> Das ist falsch, const bezieht sich hier auf int.

Passt schon. Er wird ja erst deferenziert und ist dann erst konstant. 
Sprachlich holpert das eben etwas, man muss da geistige "sequence 
points" bei der Zerlegung einfügen.

Intention von Ritche war es, die Deklaration übersichtlich zu machen, 
damit der Programmierer es einfacher hat. Aber bekanntlich ist "gut 
gemeint" das Gegenteil von "gut gemacht" und das heutige Ergebnis ist, 
dass der Mensch wie ein Compiler denken muss, um diesen Mist überhaupt 
verstehen zu können.

[Gelöscht (kami89)]

Wir haben es so gelernt, dass man immer von rechts nach links lesen 
soll.

int const * p1;
p1 ist ein Pointer auf ein konstanter Int.

const int * p1;
p1 ist ein Pointer auf eine Int-Konstante.

int * const p1;
p1 ist ein konstanter Pointer auf ein Int.

const int * const p1;
p1 ist ein konstanter Pointer auf eine Int-Konstante.

mfg

[(prx) A. K. (prx)]

Urban B. schrieb:
> Wir haben es so gelernt, dass man immer von rechts nach links lesen
> soll.

Was ist demzufolge
  int (*p)[];

Nope. Von innen nach aussen ist der korrekte Weg. Wobei es bei komplexen 
Type-Casts mangels Namen als Anker nicht unbedingt einfach sein muss, 
das innerste "innen" überhaupt zu finden.

[Gelöscht (kami89)]

A. K. schrieb:
> Urban B. schrieb:
>> Wir haben es so gelernt, dass man immer von rechts nach links lesen
>> soll.
>
> Was ist demzufolge
>   int (*p)[];

Diese Eselsbrücke ist nur für const-Sachen gedacht, also um rauszufinden 
ob nun der Pointer oder die Variable selbst konstant ist (oder beides) 
;-) Darum ging es ja in den letzten paar Beiträgen, deshalb habe ich 
diese Eselsbrücke mal erwähnen wollen.

[(prx) A. K. (prx)]

Ach ja, wo wir grad dabei sind. Wo fängt man bei diesem Ausdruck mit der 
Zerlegung an?
  (void(*(*)(int,void(*)(int)))(int))(f)

[Robert L. (lrlr)]

> Wo fängt man bei diesem Ausdruck mit der
>Zerlegung an?

als erstes Zerlegt man mal den Programmierer.. ;-)

[Roland H. (batchman)]

Juergen schrieb:
> Manche Leute schreiben die Qualifier auch einheitlich rechts neben den
> Typ, auf den sie sich beziehen.

Ich bin inzwischen einer davon. Und leide noch heute darunter, dass 
Teile der Code-Basis noch nicht konvertiert wurden.

Richtig toll ist das nicht, aber immerhin kann man dann die "qualifier" 
konsistent schreiben:

Zitat von 
http://stackoverflow.com/questions/2478151/why-is-volatile-parasitic-in-c

Always write the const / volatile qualifier after what you wanted to 
qualify. It is the only way to write qualifiers consistently, because 
you can write both volatile int and int volatile when you want a 
volatile integer, but only int * volatile will give you a volatile 
pointer.

[Rolf Magnus (Gast)]

Yalu X. schrieb:
> Rolf Magnus schrieb:
>> Das ist aber falsch.
>
> Ich glaube eher, wie haben eine Unterschiedliche Leseweise für
> Typdeklarationen.

Ja, du versuchst, die vermutlich ursprünglich gedachte Leseweise 
anzuwenden, ich versuche, die durch was zu ersetzen, das für mich mehr 
Sinn ergibt. Keine Ahnung, welche Variante nun die bessere ist. ;-)

> Mit meiner oben vorgeschlagenen "Von-Innen-Nach-Außen-Methode" (die IMHO
> auch Ritchie bei der Konzeptioen der Deklarationssystax im Kopf gehabt
> hat) lese ich das so:
>
> p1 dereferenziert ist konstant und vom Typ int.

Damit hab ich insofern schon meine Schwierigkeit, als daß für mich das * 
hier in der Deklaration ausschließlich die Bedeutung "Zeiger auf das, 
was davor steht" hat, während das dereferenzierungs-Sternchen damit 
erstmal direkt nichts zu tun hat.
Daß die Dereferenzierung und die Zeigerdeklaration das selbe Zeichen 
nutzen ist natürlich Absicht und resultiert wohl aus der von dir 
angegebenen Leseweise, aber ich finde das unlogisch, weil es zwei ganz 
verschiedene Dinge sind.

> Man könnte auch sagen, das const bezieht sich auf die Membervariablen,
> die von der Methode nicht verändert werden.

Genauer gesagt beziehen sie sich auf den this-Pointer innerhalb der 
Funktion. Dieser ist dann nämlich ein Zeiger auf const. Alle Zugriffe 
auf die Membervariablen werden (entweder implizit oder explizit) über 
diesen durchgeführt, also sind sie speziell in dieser Funktion auch alle 
const.

> Dadurch, dass rechts vom const nichts steht, wird angezeigt, dass die
> konstanten Dinge woanders stehen, nämlich dort, wor die Membervariablen
> deklariert sind.

Aber dennoch bezieht sich das const nicht ganz allegemin auf die 
Membervariablen, sondern nur auf Zugriffe auf diese aus der Funktion 
heraus.