Baseclass casten oder bessere Idee?

KayMcRay

Hallo liebe Community,

folgende Situation ich habe eine Klasse XMatrix, die erbt von einer anderen Matrix. In der ist eine Unterklasse Cell definiert.
Damit zu tun habe ich drei fragen, die ich euch gerne stellen würde. Danke schonmal im vorraus für erleuchtende Antworten.
Hier der Code:

class Matrix{
   class Cell{
      Cell( Matrix& matrix ) : _matrix(matrix) {}
      Matrix& _matrix;
   };
   ...
};

class XMatrix : public Matrix{
    void FancyStuff();
    void Print() const;
};

Das sollte die struktur gut darlegen... Wenn ich jetzt eine Cell erstellen möchte muss ich ein Objekt vom Typ Matrix übergeben. Ich habe aber erstmal nur Objekte vom Typ XMatrix.
Jetzt die erste Frage:
Gibt es eine gute alternative, bzw. was könnte denkbarer weise überhaupt schief gehen, wenn ich durch einen cast des XMatrix::this pointers oder eines entsprechenden Objekts auf einen Matrix-Pointer (Matrix*) eine Cell erzeuge?
Das slicing dabei dürfte egal sein... oder irre ich mich!?

Zweite Frage:
Wäre es angebrachter Cell in XMatrix neu zu implementieren? bzw. wäre das die koschere variante? Ich sträube mich gegen die Idee, sie fühlt sihc für mich an als wäre es unnötige nicht OOP Arbeit.

Dritte Frage:
die Methode Print in XMatrix soll const sein also:

void XMatrix::Print() const {
    Matrix::iterator( *this );
    ...
}

Problem der iterator den ich brauche/haben will um durch die matrix zu huschen will freilich keine const referenz, denn es kann ja passieren, dass er was verändern will in der matrix.
Print hat aber nur einen const this... Ich weiß das Problem wäre gelöst wenn ich const einfach entferne und nicht weiter darauf rumhacke.
Ich mag meinen Code aber gerne so, dass Methoden, die die membervaraiblen nicht verändern auch const deklariert werden.
Wäre es ratsam sich einen seperaten Readonly-iterator zurecht zu legen?
Oder gibts bessere Ideen?

SeppJ

Fragen 1 und 2:
Wenn die Vererbung sinnvoll ist, das heißt, jede XMatrix in jedem Kontext auch als eine Matrix gelten kann, dann kannst du auch gerne XMatrix* dort benutzen, wo Matrix* erwartet werden. Und natürlich erst recht eine XMatrix, wo eine Matrix erwartet wird. Die Gefahr, das Slicing, sollte dann schließlich keine Rolle spielen. Daher ist deine jetzige Konstruktion schon durchaus sinnvoll.

Frage 3:

Wäre es ratsam sich einen seperaten Readonly-iterator zurecht zu legen?

Ja.

P.S.: Was jedoch ein bisschen komisch wäre, wäre wenn XMatrix tatsächlich nur ein paar Memberfunktionen zu Matrix hinzu fügt und sonst nichts (falls das also nicht nur der verkürzte Beispielcode ist). Dann wäre es besser, die Funktionen frei zu implementieren und eine normale Matrix als Parameter zu nehmen.

KayMcRay

Vielen Dank für die Antwort - Sehr präzise und direkt!
Ja XMatrix erweitert Matrix nur um eine reihe von methoden. Komplexere Matrixspielereien... LR-Zerlegung, transformationen usw.

Nach deiner Antwort bezüglich der iteratoren las ich mich dann auch gleich mal schlauer und lernte in folge dessen gleich die const_iteratoren kennen. Hätte ich davon früher gewusst, wäre ich da vll. auch selber drauf gekommen. Danke dafür!
Die iteratoren sind vor allem für iterationsschritte gedacht wie quer durch die matrix zu iterieren oder nur die X-Achse, respektive Y-Achse entlang.