Nutzen von boost::scoped_ptr

http://en.wikipedia.org/wiki/Auto_ptr

Upcoming C++0x standard is due to make auto_ptr deprecated, replacing it with the unique_ptr class template.

EOutOfResources

Shade Of Mine schrieb:

Die Doku zu lesen.

Schon gemacht. Und der einzige Unterschied ist, dass boost::scoped_ptr nicht kopierbar ist. std::auto_ptr kann ~~auch nicht kopiert~~ transferiert werden.

Shade Of Mine

EOutOfResources schrieb:

Shade Of Mine schrieb:

Die Doku zu lesen.

Schon gemacht. Und der einzige Unterschied ist, dass boost::scoped_ptr nicht kopierbar ist. std::auto_ptr kann auch nicht kopiert werden.

Das ist ein Unterschied, ja. Was genau ist die Frage?

EOutOfResources

Shade Of Mine schrieb:

Das ist ein Unterschied, ja. Was genau ist die Frage?

Was er kann, was std::auto_ptr nicht kann.

theta

scoped_ptr kann AFAIK kein owenership transfer, auto_ptr hingegen schon.

Michael E.

EOutOfResources schrieb:

Shade Of Mine schrieb:

Die Doku zu lesen.

Schon gemacht.

Nochmal, bitte.

Und der einzige Unterschied ist, dass boost::scoped_ptr nicht kopierbar ist. std::auto_ptr kann auch nicht kopiert werden.

Der Unterschied zwischen den beiden ist, dass beide nicht kopiert werden können?

Zeus

Shade Of Mine schrieb:

EOutOfResources schrieb:

Oder habe ich etwas übersehen?

Ja.
Die Doku zu lesen.
http://www.boost.org/doc/libs/1_46_1/libs/smart_ptr/scoped_ptr.htm

Auto_Ptr kann den Ownership transferieren, lesen bildet

EOutOfResources

theta schrieb:

scoped_ptr kann AFAIK kein owenership transfer, auto_ptr hingegen schon.

Habe ich bereits gesagt. Und aus welchem Grund sollte man boost::scoped_ptr statt std::auto_ptr nutzen (ohne dem Argument, dass std::auto_ptr deprecated wird)?

CStoll

Doch, leider kann er kopiert werden - mit entsprechend unangenehmen Folgen für denjenigen, der es versucht:

void test(auto_ptr<meine_klasse> ptr)
{
  // macht etwas
} // zerstört 'ptr' und damit das Objekt, auf das er zeigt

void hauptfunktion
{
  auto_ptr<meine_klasse> tgt = new meine_klasse(...);
  // ...
  test(tgt);      // kopiert den auto_ptr -> ptr übernimmt dein Objekt, tgt zeigt auf NULL
  tgt->machwas(); // BUMM
}

Mit scoped_ptr wäre dir das nicht passiert.

Shade Of Mine

EOutOfResources schrieb:

Habe ich bereits gesagt.

Nein, hast du nicht. Du sagst immer nur die haelfte von dem was du dir denkst. Das funktioniert auf dauer nicht.

Und aus welchem Grund sollte man boost::scoped_ptr statt std::auto_ptr nutzen (ohne dem Argument, dass std::auto_ptr deprecated wird)?

Die Frage ist eher:
wer der bei Verstand ist nutzt auto_ptr?

Nexus

EOutOfResources schrieb:

Was er kann, was std::auto_ptr nicht kann.

auto_ptr hat implizite Move-Semantik (im Sinne von C++98). Das ist eine Gefahrenquelle. Steht übrigens genau so auf der Boost-Homepage, bitte lesen. Ausserdem besitzt scoped_ptr ein swap() , ein sicheres operator bool -Äquivalent und einen Destruktor, der vollständige Typen erfordert.

Aber mit std::unique_ptr aus C++0x und dessen expliziter Move-Semantik macht man gleich beide anderen Smart-Pointer überflüssig.

EOutOfResources

CStoll schrieb:

Mit scoped_ptr wäre dir das nicht passiert.

Achso...

Nexus

Shade Of Mine schrieb:

Die Frage ist eher:
wer der bei Verstand ist nutzt auto_ptr?

Bei auto_ptr in seiner momentanen Implementierung bin ich aufgrund der genannten Punkte mit dir einverstanden, doch für C++98 finde ich die grundsätzliche Idee dahinter gar nicht so schlecht. Ich habe sogar einen ähnlichen Smart-Pointer mit implizitem Move gebaut. Finde ich praktisch, um sicher Ownership zu transferieren (z.B. von einer Factory). Zudem erkennt man die Ownership-Semantik gleich an der Schnittstelle, wohingegen ein roher Zeiger alles bedeuten kann.

Oder was würdest du in solchen Fällen verwenden, wenn dir keine RValue-Referenzen zur Verfügung stehen?

Shade Of Mine

Nexus schrieb:

Bei auto_ptr in seiner momentanen Implementierung bin ich aufgrund der genannten Punkte mit dir einverstanden, doch für C++98 finde ich die grundsätzliche Idee dahinter gar nicht so schlecht.

Du meinst unique_ptr? Der ist super.

auto_ptr ist ja im Prinzip auch eine wahnsinnig gute Idee gewesen. Man ist nur spaeter drauf gekommen dass er technisch falsch implementiert wurde - nur dann lies es sich halt nicht mehr aendern.

Im Prinzip ist ja das einzige Problem der implizite ownership transfer.

Nexus

Shade Of Mine schrieb:

Du meinst unique_ptr?

Nein, ich meinte einen selbstgebastelten C++98-Smart-Pointer mit implizitem Ownership-Transfer, der aber die anderen Unzulänglichkeiten (kein swap() , kein operator SafeBool , keine sichere Zerstörung) behebt. Was würdest du in C++98 für Ownership-Transfer wie bei einer Factory verwenden? shared_ptr hat manchmal unnötigen Overhead, rohe Zeiger sind eine Fehlerquelle und sagen nichts über Ownership aus.

Den Vorteil eines eigenen Smart-Pointers sehe ich darin, dass man ihn wirklich intelligent machen kann. Zum Beispiel überlege ich mir, den dynamischen Typen des Pointees zu merken, und somit aus dem verschiebbaren einen kopierbaren Smart-Pointer zu konstruieren, welcher genügend Typinformationen für eine tiefe Kopie hat. So kann man sicher Zeiger hin- und herschieben und bei Bedarf polymorph kopieren – der dynamische Typ ist komplett wegabstrahiert, und die Klassen kommen ohne Clone() aus. Sag mir, falls du ein Codebeispiel brauchst

Shade Of Mine

Ich mag impliziten ownership Transfer nicht.

Was wuerdest du das denn fuer sinnvoll erachten?
Bei Factories ist es ja nicht so, dass ich den Ownership Transfer implizit machen muss. Um ehrlich zu sein, bin ich ein Fan von Rohen Zeigern hier - aber ich kann verstehen dass viele Leute hier lieber Smart Pointer sehen.

In dem Fall haette ich ein Objekt aus dem sich ein auto_ptr generieren laesst. Also die Factory liefert keinen auto_ptr sondern eben einen auto_ptr_helper den ich in einen auto_ptr kopieren kann. So habe ich die schoene Semantik fuer die Factory (der user bekommt nichts mit, denn der schreibt ja eh nur auto_ptr<T> p = create(...); ) und dennoch keinen implizite ownership transfer.

Denn um ehrlich zu sein: impliziter Ownership transfer schmeckt mir garnicht... Expliziter ist dagegen aber wieder OK - wenn dir das lieber ist.

Nexus

Shade Of Mine schrieb:

Denn um ehrlich zu sein: impliziter Ownership transfer schmeckt mir garnicht... Expliziter ist dagegen aber wieder OK - wenn dir das lieber ist.

Ja, finde ich auch besser. Aber in C++98 gehts halt nicht so wirklich schön. Sowas kann man zwar schon machen:

NonCopyablePtr a, b;
a = Move(b);

Aber für Funktionsparameter und -rückgabewerte muss man wieder zu einem anderen, implizit movable Typen greifen (der gleiche wie der, der als Zwischenstation für die Konvertierung im oberen Code genommen wird).

Shade Of Mine schrieb:

In dem Fall haette ich ein Objekt aus dem sich ein auto_ptr generieren laesst. Also die Factory liefert keinen auto_ptr sondern eben einen auto_ptr_helper den ich in einen auto_ptr kopieren kann.

Aber auto_ptr_helper transferiert dann im Prinzip auch den Besitz, oder wie kann ich mir das vorstellen?

volkard

Shade Of Mine schrieb:

...

Endlich sagt es mal einer.

Bis eben war das in mir ein Kopfchaos, getrieben von
- Extrembeisbielen, wo man es wohl braucht,
- und der Erfahrung, daß ich es doch nie brauche, in der Tat nie, und
- der häufigen Empfehlung in Foren.

Gerade war ich aufnahmefähig, weil ich mich vor Tagen dazu durchgerungen habe, boost::any generell abzulehnen, denn heterogene Container sind nur mit Vererbung sinnvoll, das angegebene Beispiel von Interpretern zieht nicht, weil die die Vererbung doch erst recht lieben...

hustbaer

Nexus schrieb:

Was würdest du in C++98 für Ownership-Transfer wie bei einer Factory verwenden? shared_ptr hat manchmal unnötigen Overhead, rohe Zeiger sind eine Fehlerquelle und sagen nichts über Ownership aus.

In C++ 98 (03) würde ICH dafür std::auto_ptr verwenden. Ausgenommen Fälle wo es kein Schaden ist gleich boost::shared_ptr zurückzugeben - oft kommt man damit gut aus.
Oder gucken ob boost mittlerweile was unique_ptr-ähnliches anzubieten hat, was auch mit C++ 98 (03) funktioniert.

Nexus

Okay.

Hast du schon mal was von Boost.Move gehört? Unter anderem soll Move-Semantik für C++98 emuliert werden, das Ganze ist aber (noch?) keine offizielle Boost-Bibliothek. Ich habe gerade gesehen, dass in dem Zusammenhang ebenfalls gewisse Smart-Pointer erwähnt werden, sieht recht interessant aus

P.S. Boost.Interprocess scheint unique_ptr und move() zu enthalten, aber ich bin mir nicht sicher, ob sie eine Implementierung für C++98 haben.