list und abstrakte klassen

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.