auto_ptr und normale Pointer
-
Wann verwendet man auto_ptr und wann normale Pointer?
Verwendet man auto_ptr nur wenn unbedingt nötig, oder ist es generell eine bessere Alternative?
-
nicht generell, nein. auto_ptr kannst du z.b. nicht in containern abspeichern. die bessere alternative ist boost::shared_ptr bzw. shared_ptr aus dem TR1.
auto_ptr jetzt noch einzusetzen könnte ich wohl nicht mehr empfehlen, da er ab 2009 als "deprecated" eingestuft sein wird.
-
queer_boy schrieb:
nicht generell, nein. auto_ptr kannst du z.b. nicht in containern abspeichern. die bessere alternative ist boost::shared_ptr bzw. shared_ptr aus dem TR1.
shared_ptr ist keine allgemein bessere Alternative zu auto_ptr. auto_ptr dient einem einzigen Zweck: der der exceptionsicheren Über- und Rückgabe von dynamisch allokierten Objekten in Funktionsaufrufen mit Besitzübernahme. Für diesen speziellen Zweck gibt es gegenwärtig keine bessere Alternative, shared_ptr erhöht dort nur unnötig die Komplexität und ist auch nicht entsprechend selbstdokumentierend, lediglich wenn man den custom-deleter benötigt ist dessen Einsatz gerechtfertigt.
queer_boy schrieb:
auto_ptr jetzt noch einzusetzen könnte ich wohl nicht mehr empfehlen, da er ab 2009 als "deprecated" eingestuft sein wird.
Ohne zu erwähnen, warum auto_ptr deprecated sein wird, ist das ein sinnfreies Argument. deprecated wird es nicht deshalb sein, weil auto_ptr plötzlich schlecht geworden wäre, sondern einfach deshalb, weil es eine bessere Alternative (die nicht shared_ptr heißt) geben wird. Das ist absolut kein Grund, auto_ptr jetzt nicht einzusetzen, wenn man später umsteigen will, ist das trivial möglich. Jedes korrekte Konstrukt mit auto_ptr ist auch noch korrekt und behält seine Bedeutung mit unique_ptr, das ist also eine simple Textersetzung.
-
der der exceptionsicheren Über- und Rückgabe von dynamisch allokierten Objekten in Funktionsaufrufen mit Besitzübernahme.
Fuer Quellen und Senken ja ...
Aber auch ohne "uebergabe" machen auto_ptr sinn.
wenn man ein objekt dynamisch knstruiert, und einen kritischen Block betritt, und nicht bei jeder abgefangenen exception den pointer extra zerstoeren will.
Also einfach um sich beim abfangen von exeptions die aufraeumarbeit zu sparen.Dadurch werden constante auto_ptr auch die perfekten partner fuer Compositionen mit dynamisch erzeugten Objecten.
PIMPL idom umsetzungen z.b.einfach nen constanten auto_ptr als member anlegen und in der initialisirungsliste mit nen new auf die Klasse befuellen.
Ums aufrauemen etc braucht man sich danna uch nimmer kuemmern....Gibt aber auch viele situationen wo auto_ptr ned geeignet sind, da kommen dann die anderen Pointer zum einsatz.
Viele Libs (QT, wxWidgets) bieten aber Objekte zeiger und new basierend an, welche aber ne eigene enladesemantik haben, die sollt man dann besser als rohe zeiger verwenden ..
Ciao ...
-
RHBaum schrieb:
Aber auch ohne "uebergabe" machen auto_ptr sinn.
wenn man ein objekt dynamisch knstruiert, und einen kritischen Block betritt, und nicht bei jeder abgefangenen exception den pointer extra zerstoeren will.
Also einfach um sich beim abfangen von exeptions die aufraeumarbeit zu sparen.Man kann auto_ptr dafür verwenden, aber die ideale Wahl ist er in der Regel nicht, scoped_ptr ist hier sinnvoller - es sei denn, der der auto_ptr ist als Ergebnis eines Funktionsaufrufs entstanden (was allerdings eigentlich ein Defekt von scoped_ptr ist: keinen geeigneten Konstruktor für auto_ptr zu haben).
Dadurch werden constante auto_ptr auch die perfekten partner fuer Compositionen mit dynamisch erzeugten Objecten.
PIMPL idom umsetzungen z.b.Gleiches Argument, es ist möglich, aber nicht ideal. Mit PIMPL ist auto_ptr nicht einsetzbar, denn auto_ptr darf, wie alle Templates der Standardbibliothek (gegenwärtig bilden shared_ptr&co die einzige Ausnahme, und das nur in TR1), nicht mit unvollständigen Typen als Templateargument instantiiert werden. auto_ptr ist für die Fälle, für die er konzipiert ist, nahezu ideal (abgesehen von einigen Defekten, bei denen wir auf unique_ptr warten müssen: unvollständig definierte Templateargumente, Customdeleter, Pointerkonvertierung aus rvalues), in allen anderen Fällen gibt es regelmäßig bessere Alternativen.
-
tr1 ist scho standard ? dacht momentan ist es nur ne erweiterung ?
Gibts ausser fuern gcc ueberhaupt schon lauffaehige Impls ?
wirds beim VS 2008 standardmaessig bei sein, oder wird man sie sich zupacken muessen. Lizensiert von Dinkumware habens ja scho ...Ciao ...
-
hmm kannst auch beim vc++ jetzt nutzen (musst das mfc update einspielen ...)
-
Aber nich beim 2005er
Und ja ich bin scho heilfroh das ich das 6.0er nimmer verwenden muss ^^
tr1 ist sicher toll, man muss es aber auch nutzen koennen. Und denk mal ner ganze menge anderer bleibts momentan auch noch verwehrt.
Ciao ...
-
Dann besorg dir doch den TR1 von woanders. Muß ja nicht von MS direkt kommen. Versteh ich nicht, was daran so schwer sein soll, sich das Ding von woanders zu besorgen.
-
RHBaum schrieb:
tr1 ist scho standard ? dacht momentan ist es nur ne erweiterung ?
Das Dokument TR1 selbst ist ein Standard im Sinne der ISO. Es ist aber keine neue Version des Sprachstandard C++, sondern eine Ergänzung hierzu.