[C++] Tutorial für mit Zeiger vs. Referenzen, Operatorüberl.

[Chewie]

Guten abend. Ich versuche gerade eine einfache Matrix-Klasse in C++ zu implementieren. Dabei möchte ich zunächst einige statische Methoden schreiben, die Objekte auf bestimmte ARt und Weise erzeugen, initialisieren und zurückgeben. Das ganze soll, falls das möglich ist, mit den &-Referenzen geschehen, da man dann beim Zugriff ja nicht zwischen Zeiger und dem eigentlichen Objekt unterscheiden muss.

Ich könnte auch damit leben, die Objekte per Zeiger anzusprechen. Dort taucht aber das Problem auf, dass ich für den Zugriff auf die Elemente der Matrix den ()-Operator überladen habe und das aber nicht bei Zeigern funktioniert (zumindest weiß ich nicht wie).

Lange Rede, kurzer Sinn: Ich habe bisher nur Tutorials gefunden, in denen diese Probleme tangiert werden, aber keins, welches sich speziell mit meiner Problematik beschäftigt. Falls jemand also so etwas kennt, wäre es sehr nett, den Link hier zu posten

Was in dem Tutorial u.a. erklärt werden sollte ist, wie man folgenden Delphi-Code in C++ unter Verwendung von Referenzen ausdrückt:

Delphi-Quellcode:

class TBlabla
public
  class function GetSpecialObject(type: Integer): TBlaBla;
end;

function TBlabla.GetSpecialObject(type: Integer): TBlaBla;
begin
  //hier irgendein Objekt erstellen oder auch ein vorhandes nehmen
  
  //z.B.
  Result := TBlabla.Create(-1, 1, type);
end;

[tommie-lie]

Zitat von Chewie:

Ich könnte auch damit leben, die Objekte per Zeiger anzusprechen. Dort taucht aber das Problem auf, dass ich für den Zugriff auf die Elemente der Matrix den ()-Operator überladen habe und das aber nicht bei Zeigern funktioniert (zumindest weiß ich nicht wie).

Du meinst den Typecast-Operator? "sometype somevar1 = (*somevar2);" tut's nicht?

Zitat von Chewie:

Delphi-Quellcode:

class TBlabla
public
  class function GetSpecialObject(type: Integer): TBlaBla;
end;

function TBlabla.GetSpecialObject(type: Integer): TBlaBla;
begin
  //hier irgendein Objekt erstellen oder auch ein vorhandes nehmen
  
  //z.B.
  Result := TBlabla.Create(-1, 1, type);
end;

Meinst du Referenzen auf das Result? Ich würde das schlechten Stil nennen. Meine Objekte sind immer Pointer, es sei denn sie sind strikt an einen Codeblock gebunden und ich will sie nicht manuell im Speicher verwalten.
However, folgendes sollte zumindest kompilieren:

Code:

class CSomeClass
{
  public:
    static CSomeClass& GetSpecialObject(type: int);
};

CSomeClass& CSomeClass::GetSpecialObject(type: int)
{
  CSomeClass *temp = new CSomeClass(parameters, for, constructor);
  return (*temp);
}

Ungetestet, ich weiß also nicht, ob er soetwas schluckt, aber auf jeden Fall das delete nicht vergessen
Schlecht ist es IMHO trotzdem

[Olli]

Zitat von tommie-lie:

Code:

class CSomeClass
{
  public:
    static CSomeClass& GetSpecialObject(type: int);
};

CSomeClass& CSomeClass::GetSpecialObject(type: int)
{
  CSomeClass *temp = new CSomeClass(parameters, for, constructor);
  return (*temp);
}

Ungetestet, ich weiß also nicht, ob er soetwas schluckt, aber auf jeden Fall das delete nicht vergessen
Schlecht ist es IMHO trotzdem

Igitt. Sowas darf garnicht. Denn der Aufrufer muß nicht extra wissen, daß er delete oder delete[] benutzen muß - oder was auch immer. Dazu gibt's ja gerade Datenkapselung.

Eine Matrixklasse habe ich schonmal geschrieben. Muß sie nur mal raussuchen. Evtl. wird's morgen, ansonsten erst am Freitag.

[Chewie]

Zitat von tommie-lie:

Du meinst den Typecast-Operator? "sometype somevar1 = (*somevar2);" tut's nicht?

Ne. ich mein den Operator, der in einem Tutorial als "subscript operator" bezeichnet wurde.
Damit kann ich so auf ELemente meiner Matrix zugreifen:

Code:

Matrix m(3);
m(0,1) := 56.45;

Was aber halt nicht geht ist sowas:

Code:

Matrix* m = new Matrix(3);
m(0,1) := 56.45;

Und warum ist so eine statische Methode schlechter Stil? Konkret möchte ich das dafür einsetzen, Translations- oder Spiegelungsmatrizen zu erzeugen. Mit zwei, drei statischen Methoden dafür ist das wesentlich besser als wenn ich den Code dafür 100 mal ins Programm schreibe.
Und wollte ich ein Singleton verwenden, muss ich das ja so machen, oder?


@Olli: Danke schon mal.

[tommie-lie]

Zitat von Olli:

Igitt. Sowas darf garnicht.

Ich habe zweimal drauf hingewiesen, daß der Stil sowas von schlecht ist, mehr kann ich auch nicht tun. Aber ja, ich geh' ja schon in die Ecke und schäme mich dafür, daß ich es überhaupt fertiggebracht habe, solchen Code zu tippseln...

Zitat von Olli:

Denn der Aufrufer muß nicht extra wissen, daß er delete oder delete[] benutzen muß - oder was auch immer. Dazu gibt's ja gerade Datenkapselung.

Ich weiß, aber Martin ist der, der Referenzen auf Objekte benutzen will *unschuldig.tut*

[Chewie]

Zitat von tommie-lie:

Zitat von Olli:

Denn der Aufrufer muß nicht extra wissen, daß er delete oder delete[] benutzen muß - oder was auch immer. Dazu gibt's ja gerade Datenkapselung.

Ich weiß, aber Martin ist der, der Referenzen auf Objekte benutzen will *unschuldig.tut*

Hehe Für andere Vorschläge bin ich gerne offen. Oben hab ich ja geschrieben, warum ich dies so machen will.

[Olli]

Referenzen sollte man da benutzen, wo sie sinnvoll sind. Das ist der Punkt.

Könntest du vielleicht erstmal spezifizieren welche Operatoren du mit welcher Funktion überladen willst und welche Operationen auf Matrizen du überhaupt haben willst?

Ich kann nur das Buch von Buzzi-Ferraris "Scientific C++" empfehlen. Mag zwar etwas älter sein, ist aber hervorragend geeignet.

[tommie-lie]

Zitat von Chewie:

Code:

Matrix* m = new Matrix(3);
m(0,1) := 56.45;

Ne, iss klar, mit ":=" kann das auch nicht gehen

Code:

Matrix* m = new Matrix(3);
(*m)(0,1) = 56.45;

geht immer noch nicht?

Zitat von Chewie:

Und warum ist so eine statische Methode schlechter Stil?

Nicht statische Methoden sind schlechter Stil. Schlechter Stil ist, Referenzen auf Dinge zurückzugeben, der der Caller freigeben muss, er aber aufgrund des Interfaces nicht darauf schließen kann, daß er das muss, ergo Referenzen auf dynamisch erzeugte Objekte. Gibst du einen Pointer zurück, ist klar, daß das Objekt wieder freigegeben werden muss. Eine Referenz auf den Rückgabewert macht allenfalls bei einigen Patterns Sinn.


Edit: Wieso ist da eigentlich immer jemand schneller als ich? Und warum kommt nie der rote Kasten? Und überhaupt, warum merke ich das immer erst 10 Minuten später? Fragen über Fragen... aber 42 kann's diesmal nicht sein...

[Olli]

War doch nur eine Vektorklasse, obwohl ich meine, ich hätte schon eine eigene Matrixklasse implementiert - aber die finde ich aktuell nicht. Vektorklasse siehe Anhang.

Ansonsten zu allen Fragen: http://www.parashift.com/c++-faq-lite/

"Scientific C++: Building Numerical Libraries the Object-Oriented Way"
von Guido Buzzi-Ferraris (Addison-Wesley). ISBN 0-201-63192-X

[Chewie]

Zitat von tommie-lie:

Zitat von Chewie:

Code:

Matrix* m = new Matrix(3);
m(0,1) := 56.45;

Ne, iss klar, mit ":=" kann das auch nicht gehen

Code:

Matrix* m = new Matrix(3);
(*m)(0,1) = 56.45;

geht immer noch nicht?

Hehe Ups.
Die (*m)(0,1) - Variante geht, ist aber hässlich. Naja, aber ist akzeptabel im Notfall.

Zitat von Chewie:

Und warum ist so eine statische Methode schlechter Stil?

Nicht statische Methoden sind schlechter Stil. Schlechter Stil ist, Referenzen auf Dinge zurückzugeben, der der Caller freigeben muss, er aber aufgrund des Interfaces nicht darauf schließen kann, daß er das muss, ergo Referenzen auf dynamisch erzeugte Objekte. Gibst du einen Pointer zurück, ist klar, daß das Objekt wieder freigegeben werden muss. Eine Referenz auf den Rückgabewert macht allenfalls bei einigen Patterns Sinn[/quote]

Ack. Ich hatte dich so verstanden, dass es generell schlechter Stil sei, dass eine statische Methode Objekte zurückliefert, sei es als referenz, als Zeiger oder als was-auch-immer.

Naja, so wies aussieht, werd ich mich damit abfinden, den Zeiger manuell zu derefenzieren.
Danke aber für die Literatur und die Vektor-Klasse, Olli.

Operatoren, die ich überladen möchte, sind halt dieser Subscript-Operator und Operatoren zum Multiplizieren. Ob ich sonst noch was brauch, weiß ich noch nicht.

Aber auf jeden Fall großen Dank schon mal.