list und abstrakte klassen

das dachte ich bisher auch und habe mir ein set mit pointern gebastelt. jedoch wird das set nicht sortiert gehalten, da std::set nur mit const Object& diese funktion erfuellen kann, wenn der operator< ueberladen wurde. mit referenzen auf objekte geht das ja auch wunderbar, jedoch fuehrt es zu den oben genannten problem, das der polymorphismus nicht mehr funktioniert. also sind zeiger noetig dachte ich mir und siehe da es funktioniert auch mit den zeigern tadellos, bis auf das set die hinzugefuegten objekte nicht sortiert haelt, da es lediglich die zeiger sortiert haelt! frage: wie sieht eine moegliche sortierung eines sets aus, wenn es als std::set<Kunden*> definiert ist
und mit
mySet.insert(new FirmenKunde()) bzw. mySet.insert(new PrivatKunde()) gefuellt werden soll und anschliessend ein Zeiger aus dem Set geholt und
pKundenZeiger->ausgeben() aufgerufen werden soll , wobei gilt

virtual void FirmenKunde::ausgeben()
virtual void PrivatKunde::ausgeben()

mein operator< lautet:

int Kunde::operator<(Kunde* pKunde)
{
return mName < pKunde->mName;
}

allerdings wird der nie aufgerufen..

Du mußt dir schon ein eigenes Vergleichsprädikat für Pointer schreiben und dem Set bekanntgeben:

bool lower_pkunde(Kunde* l,Kunde* r)
{ return *l<*r; }

map<Kunde*,lower_pkunde> my_map;

hm, nach praedikaten habe ich schon gegoogelt...allerding verwirrt mich der ausdruck map etwas.

was meint ein vergleichspraedikat fuer pointer erstellen und dieses dem set bekanntgeben genau.. (das sagt mir leider nicht allzuviel )

Mathias

ichbinsnochmal schrieb:

hm, nach praedikaten habe ich schon gegoogelt...allerding verwirrt mich der ausdruck map etwas.

was meint ein vergleichspraedikat fuer pointer erstellen und dieses dem set bekanntgeben genau.. (das sagt mir leider nicht allzuviel )

Du kannst seinem Set beim Initialisieren ein Funktionsobjekt mitgeben dass er zum Vergleichen zweier Einträge in die Liste verwendet. Du musst ein solches Objekt definieren, dass als Parameter zwei Pointer auf die von dir verwendete Klasse und deinen Bedürfnissen zuschneiden.

CStoll

ichbinsnochmal schrieb:

hm, nach praedikaten habe ich schon gegoogelt...allerding verwirrt mich der ausdruck map etwas.

Sorry, mein Fehler - das da oben sollte "set<Kunde*,lower_pkunde>" heißen.

was meint ein vergleichspraedikat fuer pointer erstellen und dieses dem set bekanntgeben genau.. (das sagt mir leider nicht allzuviel )

Das heißt, du benötigst eine Funktion, die zwei Kunde* Pointer auf größer vergleichen kann. Da man Operatoren nicht für Pointer überladen kann, brauchst du eine "normale" Funktion - dort oben ist das "lower_pkunde".
Anschließend kannst du der set mitteilen, daß sie statt op<() deine Vergleichsfunktion verwenden soll, um Schlüssel zu vergleichen.

ok, ich glaub zumindest theoretisch weiss ich jetzt bescheid .
hier folgender code, der nicht kompliliert, aber so habe ich das bis jetzt verstanden...wo ist der haken?

...

#include "property.h"

using namespace std;
#include <vector>
#include <set>
#include <iterator>
#include <algorithm>

#include <iostream>

class PropertyCollection {
  public:
    PropertyCollection (  );
    virtual ~PropertyCollection (  );

    bool addElement(Property* property);
    //bool addElement(Property& property);

    AbstractProperty* first();
    AbstractProperty* next();

    inline int lowerProperty(Property* p1, Property* p2)
    {
                return p1->mName < p2->mName;
    }

36:     set<Property*, lowerProperty> mSet;
        set<Property*, lowerProperty>::iterator it;

};

#endif

Fehlermeldung:
propertycollection.h:36: template argument 2 is invalid
propertycollection.h:36: ISO C++ forbids declaration of mSet' with no type propertycollection.h:37: invalid use of undefined typeclass
PropertyCollection'

der eintrag 36: ist nur zur orientierung

? muss lowerProperty(..) in die Klasse Property oder PropertyCollection?
? wie sieht die deklaration fuer den iterator aus?
? wie rufe ich sort auf? sort(mSet.begin(), mSet.end(), lowerProperty) ??

CStoll

ichbinsnochmal schrieb:

? muss lowerProperty(..) in die Klasse Property oder PropertyCollection?

entweder als globale Funktion oder in die PropertyCollection (in letztem Fall jedoch static - normale Member erwarten einen zusätzlichen this-Parameter, der für die set<> zu viel ist)

? wie sieht die deklaration fuer den iterator aus?

Die sieht so richtig aus, wie du es geschrieben hast.

? wie rufe ich sort auf? sort(mSet.begin(), mSet.end(), lowerProperty) ??

Eine set<> brauchst du nicht zu sortieren, die hält die Elemente von sich aus in sortierter Reihenfolge.

7H3 N4C3R

tntnet schrieb:

7H3 N4C3R schrieb:

Auch auto_ptr "gehen". Erzeugen aber absolut sinnloses verhalten. Die Requirements (Assignable) sind einfach nicht erfüllt.

auto_ptr gehen, ausser daß sie nicht gehen, ansonsten gehen sie oder wie war das gemeint?

Also Smart-pointer gehen. Gibt es leider noch nicht in der Standardbibliothek.

Ist auto_ptr etwa kein Smartpointer? Smartpointer heißt nicht "referenzgezählt und tiefe Kopie". auto_ptr können syntakisch korrekt mit einem Container verwendet werden. Deshalb gehen sie. Semantisch ist es aber völliger Schwachsinn, da bei Zuweisung eine Besitzübertragung und keine Kopie stattfinden. Deshalb gehen sie doch nicht, obwohl sie anscheinend gehen. Geht das so?

.filmor

Also wenn die Liste auch die Verwaltung der Objekte übernimmt, sprich ihr einziger Aufbewahrungsort ist, so sollte man vielleicht das in Betracht ziehen. Dann müssten auch die STL Algorithmen und Prädikate auf Anhieb funktionieren und man spart sich die unübersichtliche zweite Dereferenzierung eines Iterators.

HumeSikkins

7H3 N4C3R schrieb:

auto_ptr können syntakisch korrekt mit einem Container verwendet werden. Deshalb gehen sie.

Nope. Standard-konforme auto_ptr können nicht zusammen mit Standard-konformen Containern verwendet werden, da die Signatur des Copy-Ctors dies nicht erlaubt.

Nun gibt es aber Libraries die die Instanziierung eines Containers mit einem auto_ptr doch erlauben. In diesem Fall trifft dann aber der Teil mit dem "semantischen Schwachsinn" zu. Es sei denn natürlich man hat eine nicht-konforme auto_ptr-Implementation wie z.B. dies des VC 6. Hier ist es sogar semantisch ok. Dafür dann aber "Portabilitätsblödsinn".

Oder kurz: Never create containers of auto_ptrs (Scott Meyers: Effective STL - Item 8).

7H3 N4C3R

HumeSikkins schrieb:

Nope. Standard-konforme auto_ptr können nicht zusammen mit Standard-konformen Containern verwendet werden, da die Signatur des Copy-Ctors dies nicht erlaubt.

Hmm..
auto_ptr( auto_ptr&);

okay das erfüllt nicht die CopyConstructible Requirements, da T(t) != t ist und die const-Variante fehlt.
Und sollte beim Einfügen Ärger machen, da const T& reinkommen.

Und wieder was dazugelernt...

so jetzt hab ichs..

anscheinend reicht ihm die inline funktion nicht aus, sondern er erwartet ein funktionsobject und beklagt sich, dass er dies nicht finden kann.
deshalb habe
ich die inline entfernt und eine neue funktion nun als

struct lowerProperty{

//funktionsoperator ueberladen
        bool operator() (Property* prop1,  Property* prop2)
	{
                return prop1->mName < prop2->mName;
	}

};

vor der class PropertyCollection gesetzt.
dann klappt alles wunderbar.

danke fuer eure hilfe!!! und sonst so? hat jemand einen einwand gegen diese loesung?

camper

eine member function ist niemals ein prädikat (wegen des impliziten objektparameters).

dein operator() muss im übrigen const sein, andernfalls wirst du preobleme erhalten, wenn du const member fuktionen, die diesen funktor benötigen, instanziieren willst.