class CFoo
{
private:
    int m_i;
public:
    CFoo(int i) :m_i(i) {}
    int GetI() { return(m_i); }
};

Klasse 2:

class CFoo
{
private:
    const int m_c_i;
public:
    CFoo(const int i) :m_c_i(i) {}
    const int GetI() const { return(m_c_i); }
};

Das wären in dieser kleinen popeligen 8-Zeiler-Klasse schon 4-mal const.
Wenn das jetzt noch umfangreicher wird, ergibt das finde ich ein ganz schönes Chaos!

Was haltet ihr davon?
Welches const kann man sich sparen, was muss unbedingt sein?

class Foo //brrr, bei dem C graust es einem ja
{ 
private: 
    const int m_c_i; //aendert es sich echt nie?
                     //das kommt _sehr_ selten vor
public: 
    Foo(int i) :m_c_i(i) {} //kein const
    int GetI() const { return(m_c_i); } 
    //kein const beim return, sondern nur const fuer die methode
};

parameter die by value uebergeben oder zurueck gegeben werden muessen nicht const sein. macht meistens auch 0 sinn sie const du deklarieren, denn das ist nichtssagend. es sind ja kopien und was mit den kopien geschieht ist eigentlich egal...

PS:
bei dem m_c_i graust es mir ja noch mehr als bei dem CFoo

Jeder empfiehlt das SChlüsselwort const so oft wie möglich zu benutzen.

Glaub nie, man müsste etwas benutzen, nur weil man es kann. Code dient schließlich nicht der Dekoration, sondern ist Ausdruck eines Konzeptes.

Blaze schrieb:

Welches const kann man sich sparen, was muss unbedingt sein?

Sparen kann und sollte man sich alles, was keinen eigenen Sinn hat.
Ist die Konstanz von CFoo::m_i etwas, das unabhängig einer evtl. bestehenden Konstanz eines CFoo-Objektes existiert bzw. wäre CFoo::m_i für ein gedachtes nicht-konstantes CFoo-Objekt immer noch konstant? Wenn ja, dann muss es auch so deklariert werden, andernfalls eben nicht.
Der konstante Rückgabetyp von CFoo::GetI ist de facto überflüssig. Er verändert zwar den Typ der Funktion, nicht aber den Typ eines Funktionsaufrufes (der ist trotzdem nur int).
Ist ein Konstrukt ohne Bedeutung, verwende ist nicht.
Ist es nicht bedeutungslos, verwende es genau dann, wenn seine Bedeutung dem entspricht, was du ausdrücken möchtest.
Ganz einfach - verlangt im Gegensatz zu "const wo nur möglich" aber natürlich Mitdenken, und das scheint mitunter schon zu viel verlangt zu sein.

parameter die by value uebergeben oder zurueck gegeben werden muessen nicht const sein. macht meistens auch 0 sinn sie const du deklarieren, denn das ist nichtssagend.

für den aufrufer, für den programmierer der funktion aber nicht. er will einen parameter in der funktion vllt. wirklich unveränderbar haben.

Shade Of Mine schrieb:

parameter die by value uebergeben oder zurueck gegeben werden muessen nicht const sein. macht meistens auch 0 sinn sie const du deklarieren, denn das ist nichtssagend.

für den aufrufer, für den programmierer der funktion aber nicht. er will einen parameter in der funktion vllt. wirklich unveränderbar haben.

Mit anderen Worten: es ist ein Implementationsdetail, dass in einer bloßen Deklaration nichts zu suchen hat.

für den aufrufer, für den programmierer der funktion aber nicht. er will einen parameter in der funktion vllt. wirklich unveränderbar haben.

dann kann man das ja gerne wenn man so verrueckt ist in der implementierung auch so machen (wobei es halt sinnlos ist und nur die lesbarkeit des codes reduziert) aber bitte NIE NIE NIE in einer interface definition. Denn das erschwert nur das verstehen und lesen.

und bringen tut es ja absolut garnichts...

Jeder empfiehlt das SChlüsselwort const so oft wie möglich zu benutzen.

Mich würde echt mal interessieren, wer so etwas empfiehlt. Jeder bestimmt nicht...

Steht in manchen Büchern.
Mal ne Frage, wie soll man das bitte trennen? Entweder der Parameter ist const
oder nicht. Und das sollte in der Deklaration sowie in der Definition gleich
sein, wegen unseren beliebten Compilern.

Blaze schrieb:

Jeder empfiehlt das SChlüsselwort const so oft wie möglich zu benutzen.

Mich würde echt mal interessieren, wer so etwas empfiehlt. Jeder bestimmt nicht...

Und wenn steht diese Empfehlung wohl immer im Zusammenhang mit sinnvoller const-Behandlung (Thema const-correctness). Ich gehöre auch zu der Fraktion, die const überall wo möglich und sinnvoll einbaut. Und nein, die Lesbarkeit leidet bei entsprechender Formatierung nicht darunter.

Das Codebeispiel vom OP ist mehr als grausam (von den fehlerhalften const-Verwendungen mal abgesehen).
a) Trennt man ohnehin im Regelfall Definition von Deklaration
b) Muss man nicht alles zwangsweise in eine Zeile quetschen

Daher: Unabhängig von const oder nicht const, kann Code lesbar bleiben. Und const-correctness macht auch Sinn - sofern man diese sinnvoll anwendet.

cu André

Ich gehöre auch zu der Fraktion, die const überall wo möglich und sinnvoll einbaut.

Das ist ja auch gut so. Mich hat es nur stutzig gemacht, wenn behauptet wird, const sollte man überall einsetzen, wo es möglich ist.

Wann ist eigentlich ein const -Rückgabetyp bei eigenen Typen von Bedeutung? Mir fällt gerade nur das folgende Beispiel (und ähnliche) ein:

struct Vec2D
{
	int x;
	int y;
	Vec2D(int nx, int ny) : x(nx), y(ny) {}
};

/*const*/ Vec2D operator+ (const Vec2D& Left, const Vec2D& Right)
{
	return Vec2D(Left.x + Right.x, Left.y + Right.y);
}

int main() 
{
	Vec2D A(3, 4), B(7, -2);

	(A + B) = Vec2D(8, 0); // geht nicht, wenn op+ const-Rückgabetyp
}

Wann ist eigentlich ein const -Rückgabetyp bei eigenen Typen von Bedeutung?

Zum Beispiel für sowas:

class Test
{
private:
  std::string m_name;

public:
  std::string const& get_name() const;
}

Damit erspart man sich eine Kopie und erst recht, wenn man nur lesen möchte und nicht schreiben. Das kann der Compiler dann auch extrem optimieren.
Und das gilt natürlich nicht nur für std::string , sondern für jedes grössere Objekt.

Grüssli

Ich hab mich wohl zu wenig genau ausgedrückt. Ich dachte eher an einen Rückgabetypen wie const MyClass (also keine Referenz); also wo das noch eine Anwendung findet...

Wann ist eigentlich ein const -Rückgabetyp bei eigenen Typen von Bedeutung?

Const bei eigenen Rückgabetypen sind genau aus den Gründen sinnvoll die du schon als Beispiel heranziehst:

Nexus schrieb:

int main() 
{
	Vec2D A(3, 4), B(7, -2);
	
	(A + B) = Vec2D(8, 0); // geht nicht, wenn op+ const-Rückgabetyp
}

Und um ein weiteres Beispiel von Scott Meyers (Effektiv C++ Programmieren, 3te Auflage; Tipp 3; Seite 35) zu bringen: Es macht auch sinn um bestimmte weitere Fehlerfälle zu verhindern:

if(a * b = c) // Ausversehen = statt ==

Gut, je nach Warnungseinstellungen sollte dies eh angemeckert werden, aber dies ist ja nur eines von vielen Beispielen.

if(a * b = c) // Ausversehen = statt ==

Gut, je nach Warnungseinstellungen sollte dies eh angemeckert werden, aber dies ist ja nur eines von vielen Beispielen.

Müsste a*b nicht eh eine temporäre Variable liefern die nicht als lvalue fungieren kann? Sprich: sollte der sich der Compiler da nicht weigern, egal ob op* const liefert oder nicht?

Müsste a*b nicht eh eine temporäre Variable liefern die nicht als lvalue fungieren kann? Sprich: sollte der sich der Compiler da nicht weigern, egal ob op* const liefert oder nicht?

Der Ausdruck a*b ist (wenn es sich nicht gerade um einen überladenen Operator mit Referenzrückgabe handelt) ein rvalue. Ist der Typ des Ausdrucks der einer Klasse, verweist er zudem auf ein Objekt, nämlich ein temporäres.
Ist der linke Operand des = Operators ein Klassenobjekt, wird der Scope der Klasse nach Überladungen durchsucht (und wenigstens eine wird immer gefunden werden). Überladungen des Zuweisungsoperators sind stets nicht-statische Memberfunktionen. Das Argument des Objektparameters einer nichtstatischen Memberfunktion kann sowohl ein lvalue als auch ein rvalue sein.

std::bitset<10> x;
x[8] = true;

Das Ergebnis von x[8] ist hier ein temporäres Objekt des Typs std::bitset<10>::reference - und diese Zuweisung ist zweifellos nicht sinnlos.