Const in methode (a.k.a. Wer Fehler findet darf sie behalten)

Naja, es ist nicht ganz sinnlos, da man sonst die temporäre Variable (sinnloserweise) verändern könnte. Man kann so einige triviale (aber selten auftretende) Fehler verhindern.

#include <iostream>
using namespace std;

struct A {
  void foo() { cout << "foo\n"; } // foo ist nicht const!
};

A a() { return A(); }

int main() {
  a().foo();
}

Nexus

Es besteht kein fundamentaler Grund, wieso temporäre Objekte nicht verändert werden dürfen. Zu dem const bei nicht-skalaren Rückgabetypen wurde vor einiger Zeit etwas geschrieben (zweiter Beitrag von camper), der Post ist sicher lesenswert.

Auch Anfänger schrieb:

Rückgabeltyp

Ist das nun Absicht?

blub* 0

Auch Anfänger schrieb:

Hallo,
ich mische mich hier mal ein. Wie sieht das bei Funktionen aus:
const Rational add(const Rational& a, const Rational& b) {
was macht da das erste const? das steht ja vor dem Rückgabetyo. Aber ein Konstanter Rückgabeltyp ist doch sinnlos, oder? Er ist ja eh nur temporär.

In dem Fall ist er tatsächlich sinnlos. Es gab hier ja aber schon das Beispiel mit dem Getter. Hier mal ein Stück Code:

class Foo
{
public:
    const GanzArgGrossesStruct &getPrivateData();

private:
    GanzArgGrossesStruct privateData;
};

So kannst du beispielsweise eine Referenz auf private Daten zurückgeben. (Daten müssen so nur 1x kopiert werden, wenn das Struct groß ist, wirkt sich das durchaus aus.) Trotzdem kannst du es nachher aus der const Referenz in ein "normales" Objekt reinkopieren. Also z.B.

Foo foo;

GanzArgGrossesStruct meineKopie = foo.getPrivateData();

pumuckl

blub² schrieb:

[...]

Das Beispiel bei dir war allerdings eine konstante Referenz als Rückgabe. Dass die const sein müssen können (!) ist klar. Ebenso kann es durchaus sein, dass Pointer-to-const zurückgegeben werden. Wird aber ein Wert zurückgegeben, ist es meist kein Vorteil, wenn der const gemacht wird.