2009-01-13 11 views
13

Was ist der beste Weg, um anzugeben, dass ein Objekt Besitz eines anderen Objekts übernehmen möchte? Bis jetzt habe ich eine std::auto_ptr in der öffentlichen Schnittstelle verwendet, so dass der Client weiß, dass die Schnittstelle das übergebene Objekt übernehmen will.Übergeben von Objektbesitz in C++

Allerdings sagt mir der neueste GCC auto_ptr ist veraltet, also frage ich mich, was ist zu empfehlen? boost::interprocess::unique_pointer sieht aus wie ein guter Kandidat, aber ist das wirklich die beste Lösung da draußen?

Antwort

9

boost::interprocess ist eine Bibliothek für Interprozesskommunikation, also würde ich es nicht für andere Zwecke verwenden.

Wie in diesem Forum diskutiert:

http://objectmix.com/c/113487-std-auto_ptr-deprecated.html

std::auto_ptr wird erklärt in der nächsten Version des Standards veraltet, wo es die Verwendung von std::unique_ptr empfohlen werden, die Semantik rvalue Referenzen und bewegen erfordert implementiert werden (das ist ein ziemlich kompliziertes Feature).

Bis der neue Standard veröffentlicht wird, würde ich einfach versuchen, die Warnung zu deaktivieren, wenn möglich, oder sie für maximale Portabilität zu ignorieren.

Wenn Sie bereits zum nächsten Sprachstandard wechseln möchten, ist es möglich, da Rvalue-Referenzen implementiert wurden (siehe http://russ.yanofsky.org/rref/), so dass auch std::unique_ptr unterstützt werden sollte.

Einer der Vorteile der neuen Semantik ist, dass Sie dem Move-Konstruktor auch einen temporären oder beliebigen Rvalue übergeben können; in anderen Fällen kann dadurch vermieden werden, dass zum Beispiel Objekte, die in einem std::vector enthalten sind (während der Neuzuweisung), kopiert werden, bevor die ursprünglichen zerstört werden.

+0

'Wird veraltet sein' ist zu stark. Der aktuelle Entwurf schlägt diese Änderung vor. Wartet darauf, dass es ein Standard wird. –

+0

ja. Aber es wäre sehr überraschend, wenn auto_ptr nicht veraltet wäre. es dient dem gleichen Zweck wie unique_ptr, nur auf eine schreckliche Art und Weise :) (Missbrauch der cctor) –

+0

@litb: Obwohl ich AutoPtr zu respektieren bin, stimme ich Ihnen zu, es kann schwierig sein, richtig zu verwenden. Aber C++ ist viel zu komplex, um einfach davon auszugehen, dass unique_ptr ein akzeptabler Ersatz sein wird, ohne viel zu studieren und zu testen, zumindest sind die Schwächen von auto_ptr gut verstanden. –

0

std :: auto_ptr implementiert Eigentum Abwälzung Kopie und Zuordnung, so gibt es nichts Besonderes, was man tun sollte:

std::auto_ptr<T> p = somePtr; // not p owns object, referenced by somePtr 
std::auto_ptr<T> q = myObj.GetAutoPtr(); // not q owns object referenced by auto_ptr in myObj 

Aber Eigentums Objekt vorbei ist kein gutes Design der Praxis führt es zu Lecks und Objektlebensdauer relative Fehler.

+2

Völlig nicht einverstanden mit Ihrer Schlussfolgerung. Ownership Passing ist gut etabliert und eine gute Möglichkeit zu beschreiben, was Ihr Code tut. –

+0

Wir könnten zustimmen sagen, dass es eine chaotische Design-Praxis sein kann, nur wenn es gute Gründe gibt. – Blaisorblade

0

Ich kann mich nicht erinnern, dass std :: auto_ptr veraltet ist.
Jeder hat einen Link zu den entsprechenden Standards Treffen, wo sie das diskutieren?

Ein schnell Google Google: http://objectmix.com/c/113487-std-auto_ptr-deprecated.html

>> In fact the latest publicly available draft lists auto_ptr in appendix 
>> D, meaning that there is clear intent to formally deprecate it in the 
>> next revision of C++. A new class named unique_ptr is going to provide 
>> a replacement for auto_ptr, the main difference being that unique_ptr 
>> uses rvalue-references instead of voodoo magic to properly achieve 
>> move semantic. 
> 
> Is a reference implementation available? Is it too early to start using it? 
> 

In order to use unique_ptr you need first to have a compiler which 
properly supports rvalue references. These can be hard to find nowadays, 
as the feature has not yet been standardized, although the situation is 
quickly improving. For example GCC has very recently added the feature 
in v4.3 (http://gcc.gnu.org/gcc-4.3/cxx0x_status.html). If you are lucky 
enough to have one of those compilers, most probably they already ship a 
version of unique_ptr (it's a sort of benchmark for the feature, you 
know). In any case, you can find reference implementations on the 
internet by just googling unique_ptr. 

So sieht es aus wie ihre Bewegungen sind für unique_ptr deprecate auto_ptr (die die gleiche Semantik). Aber es benötigt einen Compiler, der die vorgeschlagenen neuen Funktionen in der kommenden Version von C++ unterstützt.

Aber es gibt noch ein weiteres Treffen und somit stimmen wir ab, damit sich die Dinge ändern können, bevor der Standard konkretisiert wird.

3

std::unique_ptr ist in der Tat der neue empfohlene Weg. Mit C++ 0x werden Containers bewußtseinsbewußt, was bedeutet, daß sie mit Typen umgehen können, die korrekt beweglich sind (d. H. std::vector<std::auto_ptr<x> > funktioniert nicht, aber std::vector<std::unique_ptr<x>> wird es tun).

Für boost unterstützen die boost::interprocess Container bereits bewegliche Typen, wobei boost::interprocess::unique_ptr einer davon ist. Sie ähneln beweglichen Typen in pre C++ 0x, indem sie einige der "normalen" Boost-Template-Assistenten verwenden und r-Wert-Referenzen verwenden, wo sie unterstützt werden.

Ich wusste nicht über die auto_ptr dedizierte Abwertung, obwohl, aber ich habe nicht die neue Standardentwicklung eng verfolgt.

(bearbeiten) Die Umsetzung der boost::interprocess::unique_ptr ist in der Tat nicht um einen „öffentlichen“ smart-Zeiger wie boost::shared_ptr oder boost::scoped_ptr, aber es ist (siehe boost.interprocess's site) nicht nur für Shared-Memory, sondern auch für Allgemein- verwendet werden kann, Zweck.

Allerdings bin ich mir ziemlich sicher, dass, wenn GCC die auto_ptr Vorlage veraltet, sie bereits ihre eigene unique_ptr Implementierung bereitstellen (nicht viel zu verwerfen, wenn Sie noch keine brauchbare Alternative haben).

Wenn Sie jedoch an einer C++ 0x-Plattform arbeiten, verwenden Sie unique_ptr, die in der lib des Compilers verfügbar ist. Wenn nicht, bleiben Sie bei auto_ptr.

+0

Beachten Sie, dass die Frage zu boost :: interprocess :: unique_pointer (eigentlich unique_ptr) gestellt wird. Dies ist ein intelligenter Zeiger für gemeinsam genutzten Speicher, der von dieser Bibliothek unterstützt wird. – Blaisorblade

+0

Ja, ich habe das wirklich ignoriert, mehr als ich hätte. Dennoch ist die unique_ptr-Implementierung von boost.interprocess ein allgemeiner Zweck, nicht nur für den gemeinsam genutzten Speicher von Interprocess. Ich hoffe, dass der Schnitt das deutlicher gemacht hat, obwohl ich es immer mehr bezweifle ... – gimpf

+0

fragte der Questioner nicht, warum auto_ptr veraltet ist. Ich denke, das ist eine ausgezeichnete Antwort –

2

Ich stimme zu, wo möglich sollten Sie Typen verwenden, bei denen der Compiler bei der Eigentumsübertragung unterstützt.

Wo Sie nicht, dass die Wahl von Datentypen und rohe Zeiger sind vorbei, folge ich den Taligent Programmierrichtlinien von Methoden zu benennen, die das Eigentum als orphanBlah und Parameter verzichten, den Besitz nehmen, wie adoptBlah.

Verwandte Themen