ich dachte... ich hätte das Konzept verstanden. Soweit ich weiß dürfen in const-Methoden keine Membervariablen verändert werden u. aus diesem Grund auch keine (nicht-const)Methoden aufgerufen werden.

Jetzt scheint es aber noch eine andere Eigenart zu geben. Der Compiler spuckt mir hier folgende Fehlermeldung (an den fett markieren stellen im Code) aus:

error C2440: 'return': 'const float [2]' kann nicht in 'float *const ' konvertiert werden

[code="cpp"]
class Grundstueck {
private:
float Ecke1[2];
float Ecke2[2];
public:
Grundstueck(float x1=0,float y1=0,float x2=0, float y2=0);
float * const get_Ecke1() const;
float * const get_Ecke2() const;
...

};

Grundstueck::Grundstueck(float x1, float y1, float x2, float y2){
Ecke1[0]=x1; Ecke1[1]=y1;
Ecke2[0]=x2; Ecke2[1]=y2;
}
float * const Grundstueck::get_Ecke1() const{
return Ecke1;
}
float * const Grundstueck::get_Ecke2() const{
return Ecke2;
}

[/code]

Kann mir einer erklären was hier genau passiert ?

Ich hab das ganze jetzt erstmal so belassen:

float * const Grundstueck::get_Ecke1(){
	return Ecke1;
}

Hier gebe ich ja einen konstanten Zeiger auf meinen float Member zurück... nehmen wir mal an ich wöllte diesen Zeiger manipulieren (was hier nicht funktionieren sollte). Wie würde ich das überhaupt anstellen? So wie ich es kenne landet der zurückgegebene Wert in einer neuen Variablen z.B.

float * p;
p=g.get_Ecke1();
p=p+1;

Damit wäre das ganze doch hinfällig

struct foo
{
  int i_;

  int bar() const
  {
    return i_;
  }
};

Ist auch kein Problem, auch wenn das int nicht const ist. Aber wer das int verändert, verändert nichts am Objekt. Du brauchst also, wie schon geschrieben, keinen konstanten Pointer, sondern einen Pointer auf ein konstantes Objekt.

Ich hab das ganze jetzt erstmal so belassen

Und somit bleibt der Fehler wie er ist ist...

Dein return paßt nicht zur Signatur deiner Methode.

ok d.h. schonmal.... in dieser Variante hat das "const" keinen praktischen Nutzen?

typ * const bsp(){
    ...
}

const int foo();

Nicht besonders sinnvoll ist.

in dieser Variante hat das "const" keinen praktischen Nutzen?

Nicht nur hat es keinen Nutzen, es wird vollkommen ignoriert.

typ * const bsp();

ist genau die gleiche Signatur wie

typ * volatile bsp();

und

typ * bsp();

Ich habe gerade mal vollkommen auf das "const" verzichtet und über den Pointer den Member verändert.

Wundert mich nur, das unser Dozent diesen getter in der Musterlösung auch ohne "const" definiert hat:

C++:
class Grundstueck {
private:
float Ecke1[2];
float Ecke2[2];

Das bricht doch mit der Kapselung oder liege ich da falsch?

class Grundstueck {
private:
	 float Ecke1[2];
	 float Ecke2[2];   
public:
	Grundstueck(float x1=0,float y1=0,
			   float x2=0, float y2=0);
	float *get_Ecke1();
	float *get_Ecke2();
	void set_Ecke1(float, float);
	void set_Ecke2(float, float);
    float Flaeche();
};

Ich denke ich habs verstanden. Danke dir/euch.

John D schrieb:

in dieser Variante hat das "const" keinen praktischen Nutzen?

Nicht nur hat es keinen Nutzen, es wird vollkommen ignoriert.

typ * const bsp();

ist genau die gleiche Signatur wie

typ * volatile bsp();

und

typ * bsp();

nein. Das sind durch aus unterschiedliche Signaturen. Top-level cv-Qualifikation wird nur bei Parametern ignoriert.
Allerdings geht ein cv-Qualifikation des Rückgabetyps beim Funktionsaufruf verloren, wenn dieser Typ ein Skalar ist.

Ob es die Kapselung bricht ist wohl Ansichtssache

Ähh, es bricht eindeutig die Kapselung. Die Funktion get_Ecke1() ist wohl das Paradebeispiel wie man es nicht machen sollte. Damit kann man herliche Sauereien wie folgendes machen:

int main ()
{
  Grundstueck g;
  float* f;

  f = g.get_Ecke1();
  *f = 1;
  f++;
  *f = 2;
  // Och woher weis ich denn dass ein Grundstück keine 3D Punkte als Grenze hat ?
  f++;
  *f = 3;
  // Och wir wollen aber double Koordinaten setzen 
  double* f2;
  f2 = (double*) g.get_Ecke1();
  *f2 = 5;
}

Effetive C++ Regel:
1.) Baue deine Klassen so dass sie einfach zu bedienen aber schwer zu missbrauchen sind.
2.) Gebe niemals eine Referenz, ein Zeiger auf interne Dinge zurück, wenn es eine Kopie auch tut.

int main ()
{
  Grundstueck* g = new Grundstueck;
  float* f;

  f = g->get_Ecke1();
  delete g;
  *f = 1;
  f++;
}

C++ ist auch scheiße, guck mal!

*((void*)0)

Das kompiliert auch nicht.

@komplimat
Ja, es geht um's Prinzip.

Es ist immer noch Schwachsinn, auch wenn ein Mod den Beitrag gelöscht hat.

Den Satz verstehe ich nicht. Gelöschten Beitrag? Schwachsinn? Häh???

Was spricht gegen folgendes?

Point Grundstueck::get_Ecke2() const;

Den Satz verstehe ich nicht. Gelöschten Beitrag? Schwachsinn? Häh???

Ein Moderator hat einen Beitrag gelöscht. volkard löscht gerne einfach weg, was ihm nicht zusagt. Siehe Posting von komplimat, da ist das gelöschte Posting noch halb im Zitat drin.

Frevelthat

volkard editiert gerne einfach weg

...oder hin, bis es ihm zusagt

@Bitte ein Bit
Die Argumentation kann man genau so auf jede Container-, Vektor- und Matrixklasse der Welt anwenden. (Und wahrscheinlich auf noch viel mehr.)

Die Argumentation kann man genau so auf jede Container-, Vektor- und Matrixklasse der Welt anwenden. (Und wahrscheinlich auf noch viel mehr.)

Was verstehst du denn überhaupt unter Kaspelung?

Die Verteilung von Aufgaben an eine Klasse? Oder die Verteilung von Aufgaben an eine Klasse und die Sicherstellung der Konsistenz der Daten?

Dein Spruch verwirrt mich trotzdem. Wieso sollte ich auf die Interna's einer doppelt verketteten Liste zugreifen wollen bzw. können? Welchen Sinn hätte das außer Fehler zu provozieren? Jaja, dann kommt der nächste Java Programmier, nimmt die bereits bestehende doppelt verketteten Liste, implementiert in C++ und reserviert sich auf einen neuen Zeiger auf einen bereits bestehenden Zeiger. Wie man das halt so in Java macht.

Kaspelung dient für mich unter anderem dazu den Benutzer in ein Schema zu pressen. Eine gute Klasse hat für mich Ähnlichkeit mit einem Lego Baustein. Interne Dinge interresieren mich nicht, nur das ich diese kombinieren kann um mein Problem zu lösen.

Übrigens, die zweite Argumentation stammt aus Effektive C++.