Wozu ist der Smartpointer boost::scoped_ptr da? Er kann nichts, was std::auto_ptr nicht auch kann. Oder habe ich etwas übersehen?

MfG, EOutOfResources

auto_ptr soll ja angeblich abgeschafft werden

Wo steht das?

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

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

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 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?

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

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

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?

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

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)?

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.

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?

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.

Mit scoped_ptr wäre dir das nicht passiert.

Achso...

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?

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.

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

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.

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?

...

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...

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.

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.

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?

Die Idee ist folgende. Das ist nicht nur auf Smartpointer hier reduziert sondern ein Idiom dass immer mal wieder vorkommt. Leider kenne ich keinen Namen dafür.

Ein smartpointer ist nicht kopierbar und kann den ownership nicht transferieren. Jetzt erstellen wir ein Objekt, dass sich selbst zerstört - wie wir eben aus mojo oder (vermutlich ist boost.Move nichts viel anderes als ein modernes mojo) kennen: wir können mit diesem Hilfsobjekt einen echten smartpointer erstellen. Sobald wir das machen stirbt das Objekt. Wir moven es also quasi in den smartpointer.

Der Vorteil ist der: in der Factory selber brauchen wir die Smartpointer fähigkeit ja nicht. Wir wollen nur den smartpointer nach aussen geben. Wir wollen aber nicht kopieren, sondern moven. Dieses helper-Objekt erlaubt uns das. Ich habe mich nicht viel mit c++0x befasst, uU ist das ganze mit einem
return std::move(autoPtr);
in der Factory Methode schon getan.

Jedenfalls ist das Hauptproblem wie man den ownership transfer eliminieren kann und dennoch vernünftige Interfaces anbieten kann.

Aber erzähl mal was dein smartpointer so genau macht. Prinzipiell bin ich immer für speziellösungen zu begeistern und du hast oft super Ideen. Also erzähl mal was du so hast

Hast du schon mal was von Boost.Move gehört? Unter anderem soll Move-Semantik für C++98 emuliert werden

Lol, jetzt werden sie aber kindisch.