Compilerfehler durch const??

dot

SideWinder schrieb:

Übrigens: const int& als Rückgabetyp ist wohl eher sinnlos, was soll das bringen?

ist nicht sinnlos. ohne const könntest du das kompillieren:

my_object.get_i() = 40;

mit const beim rückgabewert führt sowas zu einem compilerfehler.

SideWinder

@camper: Warum ist A nicht CopyConstructable und Assignable? (Wenn der op= nicht implementiert sein würde)

@dot: Nicht "int&" sondern "int" statt "const int&". Das liefert dann:

error C2106: '=': Linker Operand muss ein L-Wert sein

MfG SideWinder

dot

jo, ich meinte ja auch int.

const int get_i() const {
    return Ai;
}

das meinte ich. hab mich leider ziemlich blöd ausgedrückt^^

SideWinder

Da kannst du aber auch int statt const int schreiben, liefert ebenfalls einen Compilerfehler. Siehe oben.

MfG SideWinder

camper

20.1.3
Table 30 CopyConstructible requirements

expression  return type  requirement
T(t)                     t is equivalent to T(t)
T(u)                     u is equivalent to T(u)
t.˜T()
&t          T*           denotes the addrss of t
&u          const T*     denotes the address of u

23.1/4
Table 64 Assignable requirements

expression  return type  post condition
t=u         T&           t is equivalent to u

(t ist ein Objekt vom Typ T, u ein Objekt vom Typ const T)
Der Standard definiert meines Wissens nicht, was genau Äquivalenz hier bedeuten soll - zweifellos soll diese Bedeutung aber in beiden Fällen gleich sein.
Ein implizit deklarierter Zuweisungsoperator kann nicht definiert werden, wenn die Klasse einen Referenzmember hat - damit würde A dann von vornherein das Assignable-Kriterium nicht erfüllen.

dot

SideWinder schrieb:

Da kannst du aber auch int statt const int schreiben, liefert ebenfalls einen Compilerfehler. Siehe oben.

stimmt sry, war grad ein bisschen verwirrt

hustbaer

camper schrieb:

Oft genug beruhen nicht-statische Referenzmember, ebenso wie konstante member, auf einem Denkfehler und sind den damit verbundenen Ärger im allgemeinen nicht wert.

Ich habe es eher öfter erlebt dass Leute eine Klasse schreiben die eigentlich noncopyable sein müsste, diese aber kopierbar machen (oder lassen, wenn der Compiler alles nötige erzeugen kann).

camper

hustbaer schrieb:

camper schrieb:

Oft genug beruhen nicht-statische Referenzmember, ebenso wie konstante member, auf einem Denkfehler und sind den damit verbundenen Ärger im allgemeinen nicht wert.

Ich habe es eher öfter erlebt dass Leute eine Klasse schreiben die eigentlich noncopyable sein müsste, diese aber kopierbar machen (oder lassen, wenn der Compiler alles nötige erzeugen kann).

Allerdings hat das Eine mit dem Anderen wenig zu tun. Klassen kopierbar zu machen, die es nicht sein sollten, ist zweifellos ein Fehler - andererseits sind genannte Member nicht in der Lage, Kopierbarkeit zu verhindern - folglich auch nicht das Mittel der Wahl dafür. Insofern entgeht mir, worauf du hinaus willst.

BorisDieKlinge

Geil, das wusste ich gar nich:

int &PropertyI(){

return iA;

}

jetzt kann ich iA lesen und iA schreiben, brauche keien getrennten Get/SEt methoden , weil es sich wie das Propertymethode in VB verhält:)

A obj;

int g= obj.PropertyI();

obj.PropertyI(); = 7;

Mann lernt nie aus, dachte sowas gwürd nich gehen;)

CStoll

Sowas würde ich lieber lassen - damit wirfst du die Zugriffsbeschränkungen durch private etc direkt über den Haufen (das hat den selben Effekt, als würdest du iA direkt public setzen, nur der Schreibaufwand für die Beteiligten wird etwas höher).