Kann ich warf shared_ptr<T> & zu shared_ptr<T const> & ohne änderung use_count?

Ich habe ein Programm, das mit boost::shared_ptrs und insbesondere, verlässt sich auf die Genauigkeit der use_count um Optimierungen durchzuführen.

Beispielsweise vorstellen, eine addition mit zwei argument-Zeiger genannt lhs und rhs. Sagen, Sie haben beide den Typ shared_ptr<Node>. Wenn es Zeit, um die Ergänzung, ich werde prüfen, die use_count, und wenn ich finde, dass eines der Argumente hat einen reference count von genau einer, dann werde ich es wiederverwenden, um den Vorgang auszuführen, statt. Wenn weder argument kann wiederverwendet werden, muss ich reservieren einer neuen Daten-Puffer und führen Sie die operation out-of-Platz. Ich bin den Umgang mit den enormen Daten-Strukturen, so dass die in-place-Optimierung ist sehr vorteilhaft.

Da kann ich nie kopieren Sie die shared_ptrs ohne Grund, D. H., jede Funktion nimmt die shared_ptrs durch Referenz oder const-Referenz zu vermeiden, verzerren use_count.

Meine Frage ist: ich habe manchmal das shared_ptr<T> & ich will zu werfen, um shared_ptr<T const> &, aber wie kann ich es tun, ohne zu verzerren die Anzahl der? static_pointer_cast gibt ein neues Objekt eher als eine Referenz. Ich würde geneigt sein, zu denken, dass es funktionieren würde, nur werfen die ganze shared_ptr wie in:

void f(shared_ptr<T> & x)
{
  shared_ptr<T const> & x_ = *reinterpret_cast<shared_ptr<T const> *>(&x);
}

Bezweifle ich stark, dies entspricht dem standard, aber, wie ich schon sagte, es wird wahrscheinlich funktionieren. Gibt es eine Möglichkeit, das zu tun, garantiert sicher und richtig?

Aktualisierung zu Konzentrieren, die Frage

Kritisieren das design nicht helfen, die Antwort in diesem post. Es gibt zwei interessante Fragen zu berücksichtigen:

  1. Gibt es keine Garantie (der Verfasser der boost::shared_ptr oder von der Norm, im Fall der std::tr1::shared_ptr), die shared_ptr<T> und shared_ptr<T const> haben die gleichen layouts und Verhalten?

  2. Wenn (1) wahr ist, dann ist die oben eine Legale Verwendung von reinterpret_cast? Ich denke, Sie würden sein hart gedrückt, um finden ein compiler erzeugt fehlerhaften code für das obige Beispiel, aber das bedeutet nicht, dass es legal ist. Was auch immer Ihre Antwort, können Sie Unterstützung finden, für die es in der C++ standard?

  • Mit dem Verweis für die Zählung in einer Weise sieht aus wie eine sehr eigenartige design der route. Warum nicht setzen einige Kontrolle darüber, ob ein Vorgang geschieht, oder durch kopieren auf den Benutzer? Oder separate gemeinsame und eindeutige Hinweise?
InformationsquelleAutor AndyJost | 2012-03-31
  1. 11

    Manchmal habe ich eine shared_ptr<T> & ich will zu werfen, um shared_ptr<T const> &, aber wie kann ich es tun, ohne zu verzerren die Anzahl der?

    Nicht. Das Konzept ist falsch. Überlegen Sie, was passiert mit einer nackten Zeiger T* und const T*. Wenn Sie werfen Sie Ihre T* in eine const T* haben Sie jetzt zwei Zeiger. Sie müssen nicht zwei Verweise auf die gleichen Zeiger; Sie haben zwei Zeiger.

    Warum sollte das anders sein, für smart-Pointer? Sie haben zwei Zeiger: der eine, um ein T, und zu einem const T. Sie beide teilen sich das Eigentum an der gleichen Objekt, so dass Sie mit zwei von Ihnen. Ihre use_count daher sollten 2, nicht 1.

    Dein problem ist dein Versuch, um eine überlastung der Bedeutung von use_count, co-opting seine Funktionalität für andere Zwecke. Kurz gesagt: du machst es falsch.

    Ihre Beschreibung, was Sie tun, mit shared_ptrs, wer ' s use_count ist, ist... erschreckend. Sie sind im Grunde sagen, dass bestimmte Funktionen kooptieren eines Ihrer Argumente, die der Aufrufer ist klar Verwendung (da der Anrufer offenbar ist es immer noch mit). Und der Anrufer nicht weiß, welche man in Anspruch genommen wurde (wenn überhaupt), so der Anrufer hat keine Ahnung, was der Staat von den Argumenten, die nach der Funktion. Ändern Sie die Argumente für Operationen wie das ist in der Regel nicht eine gute Idee.

    Plus das, was du machst kann nur funktionieren, wenn Sie pass shared_ptr<T> durch die Referenz, die selbst keine gute Idee ist (wie normale Zeiger, smart-Pointer, sollten fast immer berücksichtigt werden by-value).

    Kurz gesagt, Sie sind eine sehr Häufig verwendete Objekt mit wohldefinierten Redewendungen und Semantik, dann die Forderung, dass es in einer Weise verwendet werden, dass Sie fast nie verwendet, mit spezieller Semantik, die Arbeit gegen die Art und Weise eigentlich jeder nutzt Sie. Ist das nicht eine gute Sache.

    Haben Sie effektiv erstellt das Konzept der co-optable Zeiger, der auf einen shared pointer kann in 3 Zustände: leer, von der person, die Sie dir gegeben hat und somit kann man es stehlen, und in der Verwendung von mehr als einer person, so dass Sie können es nicht haben. Es ist nicht die Semantik, dass shared_ptr vorhanden ist, zu unterstützen. So sollten Sie schreiben Sie Ihre eigenen smart-pointer, bietet diese Semantik auf eine viel natürlichere Weise.

    Etwas erkennt, daß der Unterschied zwischen, wie viele Instanzen von einem Zeiger, die Sie haben, um, und, wie viele tatsächliche Nutzer Sie haben. So kann es passieren, um durch den Wert richtig funktioniert, Sie aber die Möglichkeit haben, zu sagen, dass Sie derzeit verwenden und nicht möchten, dass eine dieser anderen Funktionen zu machen. Es könnte shared_ptr intern, aber es sollte seine eigene Semantik.

    • Ich Stimme zu; ermöglichen die Wiederverwendung der Provisorien, der richtige Weg ist, verwenden Sie move-Semantik in C++11 zu ermitteln, ob ein bestimmter Wert (nicht shared_ptr auf einen Wert) ist temporär und somit, ob es sicher ist, zu überschreiben.
    • Es sei denn, ich bin Missverständnis, etwas, das ich denke, Sie haben das problem Umgekehrt. Wobei die Zeiger per Referenz ist das, was brechen würde diese Verwendung der use_count, in der Erwägung, dass es funktionieren sollte, wenn die Einnahme von Zeiger durch Wert. Auch unter shared_ptrs Verweis ist üblich und empfohlen, für bestimmte Umstände. Siehe mein Antwort.
    • Diese Antwort ist verwirrend das Problem. Die Analogie zu T * vs. const T * ist nicht richtig; die richtige Analogie zu T * & und const T * &.
    • Das ist irgendwie der Punkt. Wann war das Letzte mal, wenn Sie verwendet reference zu einem Zeiger? Zeiger, ob schlau oder dumm, werden üblicherweise von Wert, nicht die Referenz. All diese shared_ptr<T>&s überall, sind keine gute Idee. Entweder eine Funktion zustehenden Forderungen Eigentum von die Erinnerung (und damit sollte eine shared_ptr - by-value), oder es nicht, und somit sollte eine nackt-Zeiger.
    • Ich glaube nicht, dass seine neben-arbeiten auf der Grundlage, ob Sie verschieben die Letzte shared_ptr in das Objekt (oder gerade frisch zugeordnet eine vorübergehende). Er behauptet nicht-C++11 Gebrauch, und er ist mit boost::shared_ptr. Es ist also sehr wahrscheinlich, dass er die übergabe von Referenzen um, in der Erwartung, dass use_count==1 zu verstehen, dass nur die Anrufer zu verwenden, und es ist gut zu kooptieren es. Ich kann nicht sicher sein, aber das ist meine interpretation von seiner Beschreibung..
    • Ich würde nicht denken, dass der Fall, wo nur der Anrufer nutzt es bedeutet, es ist gut zu kooptieren es. Ich würde erwarten, dass es nur in Ordnung zu kooptieren, das Objekt nur, wenn niemand anderes es. Aber ich nehme an, ein Programm konnte wählen, verschiedene Semantik, würde ich nur erstaunlich finde.
    • Ich Stimme zu finden es verwunderlich, die ist, warum ich davon abgeraten es. Es ist nur so, dass ohne move-Semantik, der einzige Weg, um pass ein shared_ptr per Wert an eine Funktion und habe es immer noch nur im Besitz von einem Benutzer der ist, für es zu eine vorübergehende. Also ich nehme an, er hat es mit Hilfe von Referenz.

    InformationsquelleAutor Nicol Bolas
  2. 4

    static_pointer_cast ist das richtige Werkzeug für den job — Sie haben bereits festgestellt, dass.

    Das problem dabei ist nicht, dass es gibt ein neues Objekt, sondern vielmehr, dass es verlässt das alte Objekt unverändert. Sie wollen, um loszuwerden, die non-const-Zeiger und bewegen sich mit der const-Zeiger. Was Sie wirklich wollen, ist static_pointer_cast< T const >( std::move( old_ptr ) ). Aber gibt es nicht eine überlastung für rvalue-Referenzen.

    Die Abhilfe ist einfach: manuell erlischt die alten Zeiger nur als std::move würde.

    auto my_const_pointer = static_pointer_cast< T const >( modifiable_pointer );
modifiable_pointer = nullptr;

    Es könnte etwas langsamer sein, als reinterpret_cast, aber es ist viel mehr wahrscheinlich, um zu arbeiten. Unterschätzen Sie nicht, wie Komplex die Bibliothek-implementation ist, und wie er kann fehlschlagen, wenn Sie missbraucht werden.

    Nebenbei: verwenden Sie pointer.unique() statt use_count() == 1. Einige Implementierungen verwenden eine verknüpfte Liste mit no-Cache verwenden Sie count, so dass use_count() O(N) in der Erwägung, dass die unique test bleibt O(1). Der Standard empfiehlt unique für copy-on-write-Optimierung.

    EDIT: Jetzt sehe ich Sie erwähnen

    Kann ich nie kopieren Sie die shared_ptrs ohne Grund, D. H., jede Funktion nimmt die shared_ptrs durch Referenz oder const-Referenz zu vermeiden, verzerren use_count.

    Dies ist etwas Falsch. Sie haben Hinzugefügt eine weitere Schicht von Besitz-Semantik auf, was shared_ptr bereits tut. Sie sollte durch Wert übergeben werden, mit std::move eingesetzt werden, wo der Anrufer nicht mehr von Eigentum. Wenn der profiler sagt, Sie verbringen Zeit mit der Anpassung von Referenz zählt, dann könnten Sie fügen Sie einige Referenzen auf Zeiger in den inneren Schleifen. Aber als Allgemeine Regel gilt, wenn Sie nicht festlegen können, ein Zeiger auf nullptr weil Sie nicht mehr mit, aber könnte jemand anderes sein, dann haben Sie wirklich den überblick verloren, Eigentum.

    InformationsquelleAutor Potatoswatter
  3. 1

    Wenn Sie die Umwandlung eine shared_ptr auf eine andere Art, ohne dabei die Referenz-Zählung bedeutet dies, dass Sie haben nun zwei Zeiger auf die gleichen Daten. Daher, es sei denn, Sie löschen die alten Zeiger, können Sie es nicht mit shared_ptrs ohne "Verzerrung der reference count".

    Ich würde vorschlagen, dass Sie verwenden Sie roh-Zeiger hier statt, anstatt von Ihr Weg, um nicht die Verwendung der Funktionen von shared_ptrs. Wenn Sie brauchen, um manchmal neue Referenzen, verwenden enable_shared_from_this um daraus einen neuen shared_ptr zu einer vorhandenen raw-pointer.

    • Dies ist nicht das gleiche wie zu sagen, es gibt zwei Zeiger. Dies ist, zwei Verweise auf einen Zeiger, wo Sie einen der Verweise der Typ ist gefälscht. Ein Zweifel, es ist eine sichere Art und Weise (daher die Frage), aber es ist frustrierend zu schließen, da der const-qualifier wohl nicht ändern das layout oder Verhalten von shared_ptr, und außer acht gelassen wird beim löschen des zugrunde liegenden Objekts.
    • es gibt keine Garantie, dass das hinzufügen des const wird sich nicht ändern das layout oder Verhalten von shared_ptr. Wenn Sie die Verwaltung von Eigentums-manuell (ist das wirklich, was Sie tun), nur mit rohen Zeigern für die übergabe an Funktionen.
    • Übrigens, die Empfehlung zur Verwendung von raw-Pointer (eigentlich hätte ich Referenzen verwenden) ist die richtige Sache zu tun ist, fehlt eine sichere Art und Weise zu werfen die Zeiger.
    • die Garantie der Kern der Frage. A priori, es gibt keine solche Garantie, die in der C++ - standard. Aber die Autoren von shared_ptr könnte machen, wie eine Garantie. Wenn Sie es Taten, es wäre eine tolle Sache, in diesem Fall.
    • die Macher von shared_ptr kann nicht machen, eine solche Garantie. Du bist casting zwischen zwei verschiedenen raw-Typen, und der compiler übernimmt keine Gewähr dafür, dass shared_ptr<const int> hat die gleiche Darstellung wie shared_ptr<int>, unabhängig davon, was die shared_ptr Autoren tun.
    • Das ist einfach nur albern. Die layout-Regeln geschrieben sind, mit großer Präzision (für C-Kompatibilität und viele andere Gründe). Natürlich ist es möglich, um sicherzustellen, dass shared_ptr<T> und shared_ptr<const T> haben das gleiche layout im Speicher!

    InformationsquelleAutor bdonlan
  4. 0

    Wenn es kommt Zeit, um die Ergänzung, ich werde prüfen, die use_count, und wenn ich finde, dass eines der Argumente hat einen reference count von genau einer, dann werde ich es wiederverwenden, um den Vorgang auszuführen, statt.

    Dies ist nicht unbedingt gültig, es sei denn, Sie anwenden, einige andere Regeln über das gesamte Programm, die es so machen. Bedenken Sie:

    shared_ptr<Node> add(shared_ptr<Node> const &lhs,shared_ptr<Node> const &rhs) {
    if(lhs.use_count()==1) {
        //do whatever, reusing lhs
        return lhs;
    }
    if(rhs.use_count()==1) {
        //do whatever, reusing rhs
        return rhs;
    }
    shared_ptr<Node> new_node = ... //do whatever without reusing lhs or rhs
    return new_node;
}

void foo() {
    shared_ptr<Node> a,b;
    shared_ptr<Node> c = add(a,b);

    //error, we still have a and b, and expect that they're unchanged! they could have been modified!
}

    Statt, wenn man die intelligente Zeiger durch Wert:

    shared_ptr<Node> add(shared_ptr<Node> lhs,shared_ptr<Node> rhs) {

    Und die use_count()==1, dann wissen Sie, dass Ihre Kopie ist der einzige, und es sollte sicher sein, um es der wiederverwertung zuzuführen.

    Allerdings gibt es ein problem in der Verwendung dieser als eine Optimierung, da beim kopieren eines shared_ptr erfordert die Synchronisation. Es könnte gut sein, dass Sie all diese Synchronisierung alle über dem Platz kostet weit mehr, als Sie sparen durch Wiederverwendung vorhandener shared_ptrs. Alle diese Synchronisierung ist der Grund, es wird empfohlen, den code, der nicht in Besitz nehmen einen shared_ptr, der sollte shared_ptr per reference anstatt per value.

    • Kopieren shared_ptrs benötigt nur atomar inkrementiert und dekrementiert. Und, wie Sie, wenn Sie Sie bewegen, dann ist es nicht einmal erforderlich, dass. So nehmen Sie von Wert ist immer noch in Ordnung. Und wenn Sie nicht Vorhaben, zu behaupten, die Eigentümer von Ihnen, dann Sie sollte nicht unter shared_ptrs überhaupt.
    • Diese Analyse gilt für jedes Programm... so what?
    • Einige code-Eigentum bedingt ist, so wäre es notwendig, ein shared_ptr. Sogar atomar inkrementiert und dekrementiert sind nicht frei. Hier ein Ausschnitt von dem, was Herb Sutter und Scott Meyers zu sagen hatte.
    • Ich bin einfach nur aufzeigen, warum sollten Sie wahrscheinlich nicht verwenden use_count() für diese.
    • Ich habe gesehen, dass und ich Stimme nicht mit ihm. Ja, einige Funktionen bedingt in Besitz nehmen, aber wie oft kommt das wirklich passieren? Die meisten Funktionen, die behaupten, die Eigentümer meinen es ernst; Sie diejenigen, die das nicht können nehmen Sie es von const& wie Sie sehen, passen. Plus, es richtet mit der "immer unique_ptr Wert" beraten. Es ist einfacher zu merken zwei Regeln als eine.
    • Wenn ein Objekttyp ist in der Regel im Besitz von einem smart-Pointer, würde ich wahrscheinlich wählen, um den pass der smart pointer als parameter, selbst wenn eine Funktion nicht in Besitz nehmen. Beispielsweise kann es einfacher sein, setzen Sie ein Häkchen in die Funktion einmal als bei jedem Aufruf die Seite. So oder so, meiner Erfahrung entspricht, Herb Sutter, dass die überwiegende Mehrheit der Zeit, die Sie wollen, um zu vermeiden, die shared_ptr zu kopieren, und das mache ich oft, es durch die Einnahme von share_ptr durch const & anstatt durch dereferenzieren der shared_ptr-ersten.
    • So wie du unterscheiden zwischen einer Funktion/Objekt, die Anspruch auf Eigentum vs. nicht? Einer der Gründe, warum einige Menschen geben, wenn Sie sagen, dass keine Gegenstände durch die non-const-Referenz ist, so dass Sie wissen, wenn ein Objekt geändert wird, um dem Ruf Website, die zimmerreserviereung, ohne das Lesen der Funktion, um zu sehen, wenn es ist, es zu tun. Ich würde sagen, dass dies fällt unter eine ähnliche situation: wenn etwas dauert shared_ptr, dann sollte der Benutzer davon aus, dass es Besitzrechte. Wenn jeder nimmt shared_ptrs zu diesen Objekten, dann ist es schwieriger, die Spur zu dem Besitz der graph.
    • Im Gegensatz zu dem Fall gegen die Einnahme von Parametern durch nicht-const-Referenz, sollte es irrelevant sein, um den Anrufer, wenn der angerufene wird eine gemeinsame Besitzer. Der smart pointer soll zum verwalten von Eigentum, und sonst könnte es sehr problematisch ist mit den Fällen, in denen Eigentum genommen wird, bedingt.
    • Herb Sutter und Stephan Lavavej diskutieren shared_ptr-by-ref-oder value-Problem auch hier: channel9.msdn.com/Events/GoingNative/GoingNative-2012/... und nicht jeder ist damit einverstanden, dass die übergabe shared_ptr by-ref sollte üblich sein. Ich persönlich Stimme ich mit Nicol. Wenn der code nicht mehr shared_ptr Funktionalität, es sollte nur einen Node& oder Node const&, und der Anrufer einfach geht *ptr. Warum beschränken Sie Ihre Optionen durch das erzwingen der Verwendung eines shared_ptr?
    • Es kann sein irrelevant für die Anrufer, aber es ist nicht irrelevant für die person, die sieht an der Codebasis und fragt, "OK, wem gehört das Objekt?" Einer der Punkte, Kraut und Scott machten, war, dass sollten Sie nicht verwenden shared_ptr überall; es bezeichnet die übertragung des Eigentums, nicht "hier, verwenden Sie diese für ein bisschen." shared_ptr ist manchmal gesehen, wie eine Lizenz zu vergessen über Besitz-und Speicher-management. Und dieser Weg führt zu Speicherlecks durch zirkulären Verweis, oder einfach, um Sachen, um länger, als es sein muss.
    • Btw, die Diskussion über das video, das ich verlinkte, ist bei ~23 Minuten.
    • Gut eine shared_ptr wird keine Lizenz zur nicht verstehen, ein Programm, das Eigentumsrecht Grafik, aber die Art und Weise zu verstehen, das Eigentum nicht zu gehen, obwohl Sie alle den code und sehen, wer ' s Tod, was, wo. shared_ptr ist ein RAII geben und zu sehen, es ging sollte sagen, der Leser genau das, was man eine RAII-Typ übergeben würde, nämlich, dass der lokale code wird verlassen Sie das management dieser Ressourcen bis zu dem RAII-Objekt. Immer das größere Bild, wer was besitzt und sicherzustellen, dass die gesamten Besitz-graph ist ein DAG ist Links zu anderen Geräten.
    • Ja, ich habe gesehen, dass so gut und ich Stimme mit Ihren Kommentaren gibt es auch. — Code, der nicht mit der shared_ptr-Funktionalität überschreiben einer Funktion, die einen shared_ptr (vielleicht eine andere Implementierung verwenden, die shared_ptr-Funktionalität). Ich bin auch weitgehend das reden über Arten, wo das Programm in der Regel immer hält das Objekt in ein smart-pointer, damit es nicht stellen eine Einschränkung.

    InformationsquelleAutor bames53
Schreibe einen Kommentar