datenrepräsentation

Nexus

Kylanysik schrieb:

habe ja nicht so wirklich lust, punkt und vektor neu zu schreiben und möchte diese beiden klassen so übernehmen, dass sie in allen geometrischenFiguren - unterklassen verwendbar sind.

Da verstehe ich jetzt den Zusammenhang nicht - wieso müsstest du diese neu schreiben? Sind die so gestaltet, dass sie nicht kompatibel wären zu meinem oberen Beispiel? Oder wie sehen diese Klassen denn aus?

Kylanysik schrieb:

[problem 2] ist, dass ich nicht weiß, wie ich dann eben ein solches viereck bauen soll.

ein punkt, bzw. ein vektor ist nach folgendem schema aufgebaut:
punkt/vektor a;
a.data_[0] = x;
a.data_[1] = y;
a.data_[2] = z;

-> nun habe ich also 4 davon und möchte das viereck bauen..

Ich dachte, es geht um die Ebene (also zwei Dimensionen)? Aber das spielt ja keine Rolle. Trotzdem verstehe ich dein Problem nicht ganz. Was willst du im Viereck selber speichern? Nicht ein Array aus 4 Punkten? Falls doch, kannst du ja mein obiges Beispiel verwenden.

Tut mir leid, wenn ich deine Fragen nicht ganz beantworten konnte, aber du solltest sie vielleicht ein wenig genauer stellen. Manchmal hilft es auch, sein Problem anhand eines Codebeispiels zu modellieren...

Kylanysik

ersteinmal vielen dank für die antwort..
das eine problem was ich "damals" versucht habe zu beschreiben ist gelöst..
-> also bitte nicht weiter beachten
es bleibt lediglich die frage, wie ich das viereck selbst am besten intern repräsentieren sollte...
meine idee wäre diese hier:
viereck.cpp

viereck::viereck(point const& A, point const& B, point const& C, point const& D)
: data_()
{
  data_[0] = vector(A,B);
  data_[1] = vector(B,C);
  data_[2] = vector(C,D);
  data_[3] = vector(D,A);
}

vector.cpp

vector::vector(point const& a, point const& b)
  {
    data_[0] = b[point::x] - a[point::x];
    data_[1] = b[point::y] - a[point::y];
    data_[2] = b[point::z] - a[point::z];
  }

jedoch denke ich, dass sich dann das drauf zugreifen auf die einzelenen elemente problematisch werden könnte..
hättet jemand vielleicht eine bessere idee, dies problem zu lösen?
-> sollte ich den konstruktor anders bauen? würdet ihr mir vielleicht ein beispiel gleich mit schicken? ^. (da lässt es sich immer schneller nachvollziehen )
vielen dank
grüße kylanysik

asc

Kylanysik schrieb:

es bleibt lediglich die frage, wie ich das viereck selbst am besten intern repräsentieren sollte...

Auf jedenfall mit sprechenden Bezeichnern. data_ ist dies jedenfalls nicht. Wobei ich mich eh frage wie bei dir die Klassen aussehen.

Wenn ich etwas wie folgendes sehe:

punkt/vektor a;
a.data_[0]

Frage ich mich, warum man nicht gleich mit öffentlichen Membern x,y,z gearbeitet hat. Wenn man die Daten eh nach draußen gibt. Oder wenn man schon mit dem Indexoperator arbeiten will, diesen zu definieren ("punkt1.data_[0] = x" halte ich für schlechter lesbar als "punkt1[0] = x", noch besser wäre aber von der Lesbarkeit "punkt1.x = x"). Wenn man schon Daten veröffentlicht, kann man dies wenigstens sprechend tun.

Und wie du es intern darstellen willst, hängt auch davon ab, wie die Daten für deine Anwendung am sinnvollsten sind. Arbeitest du in der Regel mit Vektoren oder mit Punkten?

Davon abgesehen, erwarte ich das ein Viereck auch genau an den Koordinaten liegt, die ich übergebe. Vielleicht bin ich mit Vektorrechnung gänzlich unvertraut. Aber ich verstehe nicht deine Vektoren als interne Daten.

Ich gehe davon aus das ein Viereck, wie folgt definiert: (1,1), (1,4), (4,1), (4,4)... etwa so aussieht:

4 *******
  3 *     *
  2 *     *
  1 *******
 -0-1-2-3-4-
  |

Mit deinen Vektoren speicherst du aber, wenn ich das richtig verstehe:
(0,3,0), (3,-3,0), (0,3,0), (-3,-3,0). Ohne einen Ausgangspunkt sehe ich hier keine Möglichkeit ein Viereck wie oben zu bilden.

Kylanysik

mmh, weiß was du meinst und habe das problem auch gelöst.. jedoch ergibt sich jetzt die frage, was ist, wenn ich zwar ein viereck erzeugen kann, aber es sich nicht um ein viereck handelt. also soetwas in der art:

____d
________*|
___c_*|
________*|
_________|*
_______|*
__________a-----b

ist es mir irgendwie möglich im konstruktor noch zu fragen, ob es sich um ein viereck handelt? wenn ja, wie?
also wenn wir mal annehmen würde, ich möchte eigentlich ein quadrat bauen. dann möchte ich doch eine abfrage in einer form der art:
wenn (laenge == breite) dann konstruiere, ansonsten nicht!

grüße kylanysik

Nexus

Kylanysik schrieb:

ist es mir irgendwie möglich im konstruktor noch zu fragen, ob es sich um ein viereck handelt? wenn ja, wie?

Du könntest beispielsweise die Winkel prüfen. Die Innenwinkelsumme bei einem Viereck muss 360° betragen. Bei Fliesskommazahlen solltest du aber noch einen Toleranzbereich einbauen. Eine Alternative wäre, zu prüfen, ob sich die Verbindungsstrecken schneiden. Aber dann hättest du wahrscheinlich ein wenig mehr Aufwand...

Um die Konstruktion eines Objekts abzubrechen, wirfst du am besten im Konstruktor eine Exception. Das ist sauberer, als ein halbwegs konstruiertes, ungültiges Objekt herumliegen zu lassen.
P.S. Du kannst die [code]-Tags für Zeichnungen verwenden.

Kylanysik

erstmal vielen dank für die schnelle antwort.. und absofort werd ich auch für zeichnungen die tags nutzen
würde es dir was ausmachen mir zu erklären
wie und wo ich die abfrage explizit im konstruktor einbauen muss?
also mein konstruktor sieht bisher so aus:

quadrat::quadrat(point const& A, point const& B, point const& C, point const& D) 
:
  m_A(A), m_a(vector(A,B)),
  m_B(B), m_b(vector(B,C)),
  m_C(C), m_c(vector(C,D)),
  m_D(D), m_d(vector(D,A))
{

}

ein solches quadrat enthält also die informationen von 4 punkten und 4 seiten.
und die if-abfrage soll halt sein, ist die länge von m_a == m_b == m_c == m_d
(4 seiten aus dem grund, weil ich ja noch garnicht weiß, ob es sich beim konstruieren wirklich um ein quadrat handelt)

vielen dank
grüße kylanysik

Es ist doch ganz einfach, konstruiere das Quadrat aus Werten, bei denen du davon ausgehen kannst, dass daraus ein Quadrat wird. Der Konstruktor eines Quadrats soll doch nicht überprüfen, ob die Werte wirklich ein Quadrat ergeben, er soll eines erstellen. Also lass ihn zwei Punkte nehmen, die Kantenlänge bestimmen und daraus ein Quadrat basteln. Wenn du dich im R3 befindest, dann halt noch eine Normale oder irgendetwas anderes, aus dem du angenehm ein Quadrat basteln kannst. Der Code, der ein solches erstellt, muss sich ja sicher sein, dass es sich um ein Quadrat handelt. Schmeißen kannst du dann, wenn der Normalenvektor ein Nullvektor ist.

Viele Grüße,
Michael

asc

Kylanysik schrieb:

...quadrat...

Bisher sprachen wir doch von Vierecken, oder?

Weil: Wenn du ein Quadrat wirklich behandeln willst, was ist dies anderes als ein Spezialfall des Vierecks?

Im Gegensatz zu der Klassischen Vererbung ist hier das Problem das Quadrat zwar ein Viereck ist, ein Viereck im Gegenzug auch eins sein kann, und das auch durch nachträgliches Ändern eines Punktes.

Lieber würde ich der Viereckklasse noch eine Methode "IsQuadrat" geben, die dann konkret prüft ob dieser Sonderfall erfüllt ist, Ggf. auch einen Konstruktor der ein Quadrad direkt aus zwei Punkten generiert oder so ähnlich.

asc schrieb:

Kylanysik schrieb:

...quadrat...

Ggf. auch einen Konstruktor der ein Quadrad direkt aus zwei Punkten generiert oder so ähnlich.

Das wäre dann aber ungenau!
Außer wenn es egal ist wie das Quadrat aussieht, gibt es von zwei Punkten ja immer 2 mögliche Quadrate...
Entweder man müsste dazu noch eine Richtung für das Quadrat angeben oder diese Konstruktion funktioniert nicht!

Nexus

Kylanysik schrieb:

ein solches quadrat enthält also die informationen von 4 punkten und 4 seiten.

Das ist aber redundante Information. Ein Viereck ist durch 4 Punkte eindeutig bestimmt. Für die Seitenvektoren kannst du ja immer noch Memberfunktionen schreiben. Wenn du jedoch separate Variablen anlegst, musst du nur immer schauen, dass diese auch gleich geändert werden, wenn ein Punkt neu gesetzt wird. Zudem verschwendest du Speicherplatz.

Kylanysik schrieb:

und die if-abfrage soll halt sein, ist die länge von m_a == m_b == m_c == m_d
(4 seiten aus dem grund, weil ich ja noch garnicht weiß, ob es sich beim konstruieren wirklich um ein quadrat handelt)

Wie bereits angetönt: Ich dachte, das Problem bestünde darin, ein Viereck zu erstellen, dessen Seiten sich nicht schneiden. Wieso geht es jetzt plötzlich um ein Quadrat?