Im Programm werden verschiedene Punktvektoren benoetigt. Zum Beispiel:

std::vector<Point<double>*> dbl_pnt_vec;
std::vector<Point<size_t>*> size_t_pnt_vec;

Die Punktvektoren moechte ich in einem Vektor ablegen.

std::vector< std::vector< ??? > > pnt_vec;
pnt_vec.push_back (dbl_pnt_vec);
pnt_vec.push_back (size_t_pnt_vec);

Welcher Typ sollte fuer die Fragezeichen eingesetzt werden? Ich habe mir dazu eine Klasse AbstractPoint definiert, siehe Quelltext unten. Ich frage mich ob es andere / bessere Loesungen gibt?

/** Base class for all points */
class AbstractPoint
{
	~virtual AbstractPoint();
};

/** class Point */
template <class T> class Point : public AbstractPoint
{
public:
	/** constructor - constructs a Point object
	 \param x1
	 \param x2
	 \param x3
	 */
	Point (T x1, T x2, T x3);
	/** constructor - constructs a Point object
		 \param px array of type T and length 3
	 */
	Point (T px[3]);
	/** virtual destructor */
	virtual ~Point();

	/** const access operator */
	const T& operator[] (size_t idx) const {
#ifndef NDEBUG
		if (idx > 2) std::cerr << "Point::operator[] - idx error" << std::endl;
#endif
		return x[idx];
	}
	/** access operator (see book Effektiv C++ programmieren - subsection 1.3.2 */
	T& operator[] (size_t idx) {
		return const_cast<T&> (static_cast<const Point&> (*this)[idx]);
	}

	/** returns the coordinates of the point contained in an array */
	const T* const getData () const { return x; }

	/** write point coordinates into stream (used from operator<<) */
	virtual void write (std::ostream &os) const {
		os << x[0] << " " << x[1] << " " << x[2] << std::flush;
	}
	/** read point coordinates into stream (used from operator>>) */
	virtual void read (std::istream &is) {
		is >> x[0] >> x[1] >> x[2];
	}

private:
	Point (const Point & rhs); // compiler does not generate a copy constructor
	Point& operator= (const Point &rhs); // compiler does not generate an assignment op
	T x[3];
};

Ich bin auch an Verbesserungsvorschlaegen fuer die Punktklasse interessiert!

#ifndef NDEBUG 
        if (idx > 2) std::cerr << "Point::operator[] - idx error" << std::endl; 
#endif

dafür gibts assert

Point (T px[3]);

würd ich nicht anbieten
Point(x[0], x[1], x[2])
geht ja auch - und ist imho schöner zu lesen

const T* const getData () const { return x; }

so was empfind ich immer als ein wenig sinnlos...

obwohl du solche relativ überflüssigen Methoden anbietest, hast du keinerlei typedefs(z.bsp. value_type) oder container-typische funktionen wie begin() und end() (die du in ein- und ausgabefunktionen klasse nutzen könntest)

op<< und op>> überlädst du hoffentlich nur für AbstractPoint und nicht für jede ableitung einzeln?!

bb

PS: Sicher, dass Vererbung hier richtig ist (is-a Beziehung)?

Ist

assert (idx<=2);

eigentlich aequivalent zu

#ifndef NDEBUG
        if (idx > 2) std::cerr << "Point::operator[] - idx error" << std::endl;
#endif

? Dann waere deine Schreibweise in der Tat eleganter.

Den zweiten Konstruktor habe ich entfernt. Die Schnittstelle will ich so minimal wie moeglich halten. Vermutlich werde ich sehr viele Punkte haben und schon aus diesem Grund sollte der Punkt nur das noetigste enthalten. Das fuehrt mich zu deinem dritten Kritikpunkt, naemlich das du

const T* const getData () const { return x; }

ein wenig sinnlos findest. Ich habe mich hier fuer eine Methode entschieden, weil ich die Schnittstelle klein halten will. Aber ich ueberlege mir das vlt. noch mal.

Die Ableitung von AbstractPoint ist eigentlich nur wegen meines Design-Problems (siehe mein erster Beitrag). Meine eigentliche (nicht virtuelle) Basisklasse soll Point sein. Das Klassentemplate kann aber mit verschiedenen Typen instantiert werden. Damit habe ich verschiedene Punkttypen (std::vector< std::vector <???> >). Gibt es dafuer eine bessere Loesung?

Du könntest mal einen "Schritt zurück machen" und erklären, was Du damit eigentlich bezwecken willst. Immerhin heißt dieser Thread "Design-Frage". Das Thema schreit förmlich danach, dass Du das Problem beschreibst, was Du mit Deinem Design-Ansatz zu lösen verschst.

Gruß,
SP

template <class T> class NamedPoint : public Point <T>

oder eine Farbe, oder Materialeigenschaften tragen, ...

Ich habe daher Punkte von verschiedenen Typen. Fuer jeden Punkttyp existiert ein Vektor indem die Punkte gespeichert werden.

Beispiel:

std::vector<Point<double>*> dbl_pnt_vec;
std::vector<Point<size_t>*> size_t_pnt_vec;
std::vector<NamedPoint<size_t>*> named_size_t_pnt_vec;
std::vector<ColoredPoint<float>*> colored_float_pnt_vec;
...

Jetzt moechte ich all diese Vektoren in einem Vektor verwalten. Dazu benoetige ich ja eine Basisklasse, oder? Das ist die AbstractPoint-Klasse im ersten Post dieses Threads.

std::vector< std::vector< AbstractPoint* > > pnt_vec;

Die Klasse AbstractPoint ist meiner Meinung nach etwas kuenstlich. Gibt es da bessere Loesungen? Ist mein Design vlt. falsch?

Die Schnittstelle will ich so minimal wie moeglich halten.

Das ist eine gute Idee, aber es gibt da ein paar Dinge zu beachten:
1. Minimal gut, minimalistisch schlecht. Es geht nicht darum, immer das Minimum zu finden, sondern eine gut ausgewogene Sache.
2. Ist deine Schnittstelle dadurch wirklich so klein? Vergiss nicht, dank dem dass du ein Array zurück gibst, gibst du eigentlich deine ganze interne Struktur bekannt und zurück. Das hat nichts mehr mit Kapselung zu tun und macht die Schnittstelle eigentlich grösser. Du schreibst zwar weniger, aber für den Anwender ist die Schnittstelle komplexer. Weniger schreiben heisst nicht, dass die Schnittstelle kleiner ist.

123_tom_dabei schrieb:

Ich moechte Objekte beschreiben, welche aus Punkten bestehen. Es soll Objekte geben, die lediglich die Koordinaten haben (die von verschiedenen Datentypen sein koennen: double, float, int, ...). Die Punkte koennen aber auch zusaetzliche Eigenschaften haben. Dazu moechte ich Vererbung nutzen.

Eher die falsche Beziehung. Sowas ist doch keine is-a Beziehung. Sowas ist eine has-a Beziehung. Zum Beispiel deine NamedPoint Klasse, sie besteht aus einem Namen und einem Punkt.

123_tom_dabei schrieb:

Die Klasse AbstractPoint ist meiner Meinung nach etwas kuenstlich. Gibt es da bessere Loesungen? Ist mein Design vlt. falsch?

Wozu willst du alles in einen Vector werfen? Sowas ist meistens völlig unnötig. Halte lieber separate Listen, wenn die Objekte miteinander nix zu tun haben, was hier meiner Meinung nach der Fall ist.

Grüssli

Damit hast du einen zusätzlichen Zeiger pro Punkt, das ist zumindest nicht schlechter als wenn du die Punkt-Klasse polymorph machen würdest (dann hättest du nämlich einen vtable Zeiger statt des "properties" Zeigers).

Ich habe das Klassentemplate erweitert:

/** class-template for Points
 * \param T the coordinate type
 * \param P the properties of the point (name, color, material, ...) */
template <class T, class P> class Point : public AbstractPoint, public P
{
...
};

Mit der Klasse PropertyEmpty kann ich mir einen Punkt ohne weitere Eigenschaften erzeugen, mit der Klasse PropertyName habe ich einen Punkt mit Namen, usw.

Trotzdem bleibt die Frage: Gibt es eine Alternative zur Ableitung von AbstractPoint um die verschiedenen Vektoren in einem Vektor von Vektoren speichern zu koennen.

Eigentlich eine neue Frage: Kann man eine verschiedene Anzahl von Template-Argumenten uebergeben? Dann koennte man sich einen Punkt ganz flexibel mit
den benoetigten Eigenschaften, zum Beispiel Name, Farbe und ... durch

Point<T, PropertyName, PropertyColor, weitere Property-Klassen> p

zusammenbauen.

Ansonsten muesste man fuer die Kombination von Eigenschaften ja eigene Property-Klassen schreiben, oder?

Dravere schrieb:

Eher die falsche Beziehung. Sowas ist doch keine is-a Beziehung. Sowas ist eine has-a Beziehung. Zum Beispiel deine NamedPoint Klasse, sie besteht aus einem Namen und einem Punkt.

Dravere schrieb:

Wozu willst du alles in einen Vector werfen? Sowas ist meistens völlig unnötig. Halte lieber separate Listen, wenn die Objekte miteinander nix zu tun haben, was hier meiner Meinung nach der Fall ist.

Grüssli

123_tom_dabei schrieb:

Ich moechte Objekte beschreiben, welche aus Punkten bestehen. Es soll Objekte geben, die lediglich die Koordinaten haben (die von verschiedenen Datentypen sein koennen: double, float, int, ...). Die Punkte koennen aber auch zusaetzliche Eigenschaften haben.
...
Gibt es da bessere Loesungen? Ist mein Design vlt. falsch?

das beantwortet die Frage nicht. Was heißt 'beschreiben' und vor allem - wieseo und wofür?

Es ist keine gute Idee einen vector von vectoren zu bilden - das ist nachher recht umständlich beim Zugriff. Deine Beschreibung hört sich eher nach einem vector von Objekten an, wobei jedes Objekt wiederum einen vector aus Punkten beinhaltet.
Versuche mal ganz ohne Vererbung und ganz ohne Pointer in den vectoren aus zukommen.

Und ganz konkret nochmal nachgefragt: was hast Du mit der Farbe oder dem Namen, der an einem Punkt hängt, später vor?
Sollen in einem einzelnen vector sowohl ein Punkt mit Farbe als auch ein Punkt mit Namen untergebracht sein?

Gruß
Werner

123_tom_dabei, vllt. solltest du mal vom 'top-down-modell' ausgehen und die mögliche Benutzung des vectors beschreiben?

Die Punkte werden zur Beschreibung von Polylinien genutzt. Eine Folge von Polylinien begrenzt eine Oberflaeche. Die Oberflaechen umschliessen Volumen.

Es gibt also Punkte die zu Polylinien gehoeren die vlt. eine Farbe haben sollen. Eine Flaeche koennte Materialeigenschaften haben, die mit einer bestimmten Farbe dargestellt werden. In der Rechnung werden die Materialeigenschaften benoetigt, zur Visualisierung die Farbe. Im Inneren eines Volumen haben die Punkte vlt. keine weiteren Eigenschaften. Das ist nur ein moegliches Szenario. Mir ist auch bewusst, dass ich die Eigenschaften meist besser den anderen geometrischen Objekten (Polyline, Flaeche, Volumen) zuordnen sollte. Ich kann aber nicht alles auf einmal aendern

Ihr meint also, ich soll auf Vererbung von den Eigenschaftsklassen verzichten und das durch die folgende Aggregation loesen?

/** class-template for Points
 * \param T the coordinate type
 * \param P the properties of the point (name, color, material, ...) */
template <class T, class P> class Point : public AbstractPoint
{
public:
  P properties;
...
};

Dann waere der Zugriff auf eine Eigenschaft umstaendlicher als bei Vererbung.

Aber nach wie vor brauche ich fuer die durch die Templateklasse erzeugten verschiedenen Typen einen Basistyp - egal ob ich die Punkte in Vektoren oder Listen verwende.

@Th69 (zu deinem Nachtrag)
Genau das gefaellt mir ja auch nicht, dass AbstractPoint in der Vererbungshierarchie einfach oben drauf gesetzt wird. Das war aber bisher die einzige Loesung die mir eingefallen ist - deshalb ja der Thread.