Frage zur Klassenstruktur:

BorisDieKlinge

Folgende Klassenstruktur besteht, die Klasse Allokation besteht aus Teilallokationen:

class Allokation{

 std::list<TeilAllokation> LIST;

 class TeilAllokation{
  std::string Name;
  double Start,Ende;
    TeilAllokation(std:string Name, double S, double E){
     ......
    }
  .
  .
  .
 };

 void add(std::string Name, double Start , double Ende){
   LIST.push_back(TeilAllokation(Name,Start,Ende);
  }
};

nun will ich aber auch Teilallokationen mit zusätliche parameter in der liste speichern... die wäre ja möglich wenn ich diese von Teilallokation ableiten würde.

das problem liegt aber darin das in der methode add imm eine Objekt der basis klasse erzeugt wird.. wie könnte ich nun realisieren damit auch abgeleite Objekt der Teilallokationklasse gespeicehrt werden können, ohne die bereit bestehende implementation groß zu verändern...

Wahrscheinlich gibts es da keine elganter möglichkeit..

thordk

das problem ist schlicht, dass du die methode add nicht flexibel gestaltet hast, sondern auf ein spezifisches objekt zugeschnitten. nutz einfach polyphormie aus, dafür ist sie ja da.

class Basis;
class DerivedA : public Basis;
class DerivedB : public Basis;

list<Basis*> objekte;

void add(Basis *obj) {
  objekte.push_back(obj);
}

wenn du unbedingt eine methode add mit fixen parametern brauchst, dann definier dir einfach mehrere, die das jeweilige erweiterte objekt erzeugen und in die liste stecken.

BorisDieKlinge

jepp.. hab ich auch schon sowei.. ar eigentlich klar.. nur noch ein problem jetzt:

wenn ich nun ein iterator auf ein Element der Liste habe, veweist der iterator ja nur auf das basis element und nicht auf die abgeleitenen klassen..
muss ich dann ein dynamic_cast anwenden?

nur wenn du methoden aufrufst die nicht in der basis klasse sind

LordJaxom

Nicht wenn die Basisklasse sinnvoll gestaltet ist und alle Funktionen von abgeleiteten Klassen virtuell überschrieben/ergänzt werden können.

BTW: Wenn Du Zugriff auf std::tr1 oder boost hast, könntest Du Dir mit shared_ptr (tr1) oder ptr_vector (boost) die Sorgen der Speicherverwaltung ersparen, da Du die im Vector gespeicherten Zeiger ja auch irgendwo löschen musst.

BorisDieKlinge

musst ich bei der std::list<Basis> LIST; delakration angeben das die klasse polymorphisch ist oder so? weil die parameter der abgeltie nkalssen nich gespeichert werden irgendwie...

CStoll

Polymorphie funktioniert nur über Zeiger und Referenzen - d.h. du benötigst eine list<Basis*****> (und mußt dich selber darum kümmern, deren Elemente freizugeben).

BorisDieKlinge

ohje... as ist scheisse.. ich hab jetzt anfangen direkt Objekte in die Liste zu schreiben, weil dies schneller ist (oder nich)) wenn ich über zeiger arbeitet, ist alles langsamer...

CStoll

Nicht langsamer, nur komplizierter

PS: Nur mal aus Interesse: Wie unterscheiden sich die "Teilallokationen mit zusätzlichen Parametern" von der Normalversion?

BorisDieKlinge

eine Teilallokation , wie der Name Allokation schon sagt besteht primär aus zwei double werten, startzeit der allokation und endzeit der allokation. Zusätzlich parameter bspw. allokationstyp etc. sind sekundär..

wieso hast paar tipps?

P.S.: Dachte wenn ich objekte direkt in einer liste verwalte ist travesieren,zugriffe etc. schneller...

CStoll

BorisDieKlinge schrieb:

eine Teilallokation , wie der Name Allokation schon sagt besteht primär aus zwei double werten, startzeit der allokation und endzeit der allokation. Zusätzlich parameter bspw. allokationstyp etc. sind sekundär..

Unter "Allokation" verstehe ich eine Speicheranforderung - darum war ich mir nicht ganz sicher, was das mit Start- und Ende-Zeiten zu tun haben soll.

P.S.: Dachte wenn ich objekte direkt in einer liste verwalte ist travesieren,zugriffe etc. schneller...

Für die Geschwindigkeit beim Travarsieren ist es egal, ob in der Liste Objekte oder Zeiger stehen. Lediglich der Elementzugriff wird ein wenig langsamer durch die notwendige Dereferenzierung (aber das fällt in den Bereich Mikro-Optimierung) - und der Verwaltungsaufwand steigt etwas, weil sich die list<> nicht mehr dafür verantwortlich fühlt, was mit den Daten passiert. Aber wenn du polymorphe Objekte verwalten willst, mußt du damit leben (wobei du den Verwaltungsaufwand noch auf boost::shared_ptr abwälzen könntest). Eine list<Basis> enthält nur Basis-Objekte - und wenn du ein davon abgeleitetes Objekt reinpacken willst, wird es auf seinen Basis-Anteil zusammengestaucht, womit die Polymorphie verlorengeht.

BorisDieKlinge

Naja muss ich das ganze wohl ummodeln...

Naja Allokation ist in meinem Zusammenhang als reservierung eines Moduls für einen bestimmten Zeitraum defineirt (hat nichts mit speicher zu tun)..