Kann sowas wahr sein???
-
TS++ schrieb:
Die können das?
Die arbeiten sofort mit dynamisch erzeugten Instanzen und Pointern, die darauf zeigen. Der wesentliche Unterschied zur Arbeit mit einer PointerHashMap der STL ist, dass mir meine eigene HashMap die Speicherverwaltung abnimmt. D.h.: wird z.B. die gesamte HashMap gelöscht, so werden auch alle darin verankerten ContentObjekte gelöscht. So wie's auch sein soll. Doch gearbeitet wird wirklich nur mit Pointern. Ich kann also damit problemlos Polymorphismus nutzen.
Nicht wirklich weitsichtig von SGI! Etwas ernüchternd!ok.
ähnliche gründe bewogen mich, bei meinem alten PtrHeap und Heap zu bleiben und nicht zu versuchen, alles in eine klasse zu mogeln. es muß nicht alles stl sein.
-
sind PtrHeap und Heap zwei unabhängige Klassen oder ist PtrHeap mit Hilfe von Heap implementiert?
-
Shade Of Mine schrieb:
@volkard:
sind PtrHeap und Heap zwei unabhängige Klassen oder ist PtrHeap mit Hilfe von Heap implementiert?2
wenn ich sie wiedermal anfassen muß, mach ich aber eine draus. normalerweis emüssen meine heaps nie löschen, falls ich doch mal nen löschenden brauche, kommt da ne löschpolicy rein und in dem zuge kann ich auch die beiden klassen zu einer machen.
-
Wenn man Polymorphie in Standardcontainern braucht, ist KPCs Vorschlag mit den Smart-Pointern imho die einfachste Lösung. boost::shared_ptr kann man bedenkenlos in einem oder mehreren Containern gleichzeitig verwenden. Man muss also nicht jeden Container neu für Pointer schreiben. Und außerdem:
binnen 5 minuten kann sich jeder einen wrapper um einen STL Container schreiben der die pointer gleich deleted wenn sie aus dem container geloescht werden.
So einfach ist das unter Berücksichtigung aller möglichen Exceptions imho auch wieder nicht... Da verlasse ich mich lieber auf die STL und boost, auch wenn der Referenzzähler in einigen Fällen vielleicht unnötiger Overhead ist.
-
operator void schrieb:
So einfach ist das unter Berücksichtigung aller möglichen Exceptions imho auch wieder nicht... Da verlasse ich mich lieber auf die STL und boost, auch wenn der Referenzzähler in einigen Fällen vielleicht unnötiger Overhead ist.
gib mal n beispiel wo das schwer ist...
-
Das Interface des Containers ist weniger das Problem. Aber wie will der Container z. B. das Leaken verhindern, wenn man z. B. std::remove() auf ihn anwendet? Und was macht er, wenn in einem anderen Algorithmus das Prädikat etwas wirft und ein Element doppelt im Container bleibt? (Bei std::sort könnte ich mir sowas vorstellen...)
-
wo soll bei remove das problem liegen?
gerade bei remove() oder aehnlichem wird doch nix geloescht, sondern nur kopiert.
das tut ja keinem weh (denn wenn da ne exception fliegt, muss es remove() ausbaden und nicht unser wrapper)gib mal n code beispiel wo wir nicht exception sicher sein koennen...
-
Eben, es wird kopiert, nicht geswappt. Nimm einen Vektor mit 10 ints:
0123456789
Wenn du dann remove(intvec.begin(), intvec.end(), 5) auf diesen Vektor anwendest, erhältst du (VC7.1):
0123467899
Auf Pointer umgedacht: Wenn du keine smarten Iteratoren verwendest, merkt der Container nichts davon, dass der Zeiger 5 verschwunden ist - Leak. Durch die anschließende Verkürzung des Vektors wird der Zeiger 9 doppelt gelöscht - Access Violation.
(Hier braucht es nichtmals Exceptions, damit etwas schief geht. Aber mit Exceptions werden noch mehr Algorithmen gefährlich.)
-
ok, solche probleme hat man aber auch mit eigenen containern...
btw: in diesem punkt verstehe ich den standard nicht.
-
Shade Of Mine schrieb:
ok, solche probleme hat man aber auch mit eigenen containern...
Aber nicht mit shared_ptr. Da können die Container und Algos praktisch nichts kaputt machen.
Shade Of Mine schrieb:
btw: in diesem punkt verstehe ich den standard nicht.
Sie hätten shared_ptr nur mit reinnehmen sollen
-
Hi!
Für alle die sich damit rumplagen:
Am WE ist mir diese Problemstellung auch untergekommen.
Und zwar im Buch "Effectiv STL" von Scott Meyers.Sehr aufschlussreich und interessant geschrieben.
Ich mache eigentlich keine Werbung, aber es passt einfach zu gut
zu diesem Problem.Greetz
Richie