3. ptr-typen

ptr-typen

  • ?

    was gibts alles für ptr-typen?
    Ich kenne nur auto_ptr

    0
  • E

    STD::
    auto_ptr

    STD:: (C++0x)
    unique_ptr

    STD::TR1::
    shared_ptr
    weak_ptr

    boost::
    shared_ptr
    scoped_ptr
    intrusive_ptr
    weak_ptr

    Ich habe mal was von implicit_ptr gehört, aber ich weiss nicht mehr wo...

    MfG, EOutOfResources

    EDIT 1 & 2: Liste gefixt

    0
  • ?

    und was tun die?

    0
  • K

    EOutOfResources schrieb:

    STD::TR1::
    unique_ptr

    Das stimmt nicht. Du meintest wohl shared_ptr und weak_ptr. unique_ptr wird es es erst in der "StandardLib 2.0" geben (C++ 2011).

    lolrofllolxD schrieb:

    und was tun die?

    Einfach nachlesen. GIYF.

    0
  • E

    krümelkacker schrieb:

    Das stimmt nicht.

    Dann habe ich mich verlesen, als ich mich über die neue STD informiert habe. Danke.

    0
  • N

    std::tr2::unique_ptr ist übrigens auch nicht richtig. Dieser Smart-Pointer ist Teil von C++0x, also std::unique_ptr .

    0
  • K

    Die wichtigsten schlauen Zeiger im Überblick

    C++98/03   Boost  TR1   C++0x
------------------------------------------------------
auto_ptr          X                     X (deprecated)
scoped_ptr                 X
intrusive_ptr              X
shared_ptr                 X     X      X
weak_ptr                   X     X      X
unique_ptr                              X

    Statt auto_ptr und scoped_ptr haben wir in C++0x unique_ptr. Für intrusive_ptr gibt es kein direktes Pendent in C++0x. In vielen Fällen sollte sich aber stattdessen auch shared_ptr ggf mit make_shared nutzen lassen.

    unique_ptr: "unique ownership". Ein unique_ptr fühlt sich verantwortlich für das, worauf er zeigt. Er kann nicht kopiert, aber dafür "bewegt" werden (umziehen, move). Mit Verantwortung bzw Besitz ist gemeint, dass das referenzierte Objekt als Teil des schlauen Zeigers betrachtet wird und mit ihm stirbt (oder auch vorher per reset oder Neuzuweisung).

    shared_ptr/weak_ptr: "shared ownership". Ein shared_ptr fühlt sich mitverantworlich für das, worauf er zeigt. Er teilt sich den Besitz mit anderen shared_ptr-Objekten. Kopiert man ein shared_ptr-Objekt, teilen sich Quell- und Ziel-Objekt einen gemeinsamen Referenzzähler. Im Referenzzähler wird gespeichert, wieviele shared_ptr-Objekte auf das zu verwaltende Objekt zeigen (sofern man keinen Blödsinn gemacht hat). Wenn der letzte shared_ptr zerstört wird, wird auch das referenzierte Objekt gelöscht. Die Referenzzähler-Methode verkraftet allerdings keine "Verweis-Kreise". Objekte können im Speicher hängen und auf sich gegenseitig zeigen, ohne, dass sie noch von außen erreichbar wären. Mit weak_ptr kann man diese Kreise verhindern.

    auto_ptr, scoped_ptr versus unique_ptr

    auto_ptr ist recht unflexibel und die Benutzung ist fehleranfällig aufgrund des "destruktiven Kopierkonstruktors". scoped_ptr ist im Prinzip wie auto_ptr mit drei Unterschieden: scoped_ptr unterstützt unvollständige Pointee-Typen, scoped_ptr bietet keinen destruktiven Kopierkonstruktor an und scoped_ptr bietet auch keine release()-Funktion an. unique_ptr kann alles, was die anderen beiden können und noch mehr, kommt aber ohne destruktive Kopie aus (ist also sicherer in der Benutzung). Stattdessen hat unique_ptr einen Move-Konstruktor. unique_ptr unterstützt auch explizit unvollständige Typen und sogar benutzerdefinierte "Deleter", welche kontrollieren, wie das, worauf der Zeiger zeigt, freigegeben werden soll.

    shared_ptr versus intrusive_ptr

    Beide Ansätze arbeiten mit Referenzzählern. Für intrusive_ptr muss der Referenzzähler schon im Objekt eingebaut sein. shared_ptr erzeugt dagegen seinen eigenen Referenzzähler separat. Mit der Hilfsfunktion make_shared ist der Unterschied bzgl des Speicherlayouts aber nicht mehr so groß:

    shared_ptr<double> sp = make_shared<double>(3.1415);

    Hier wird im Enfeffekt ein einziger Speicherblock reserviert, in dem sowohl das double-Objekt als auch der Referenzzähler (und co) abgelegt werden. Wenn das Objekt von sich aus einen schlauen Zeiger auf sich weitergeben will, dann ist das erstmal bei intrusive_ptr einfacher. Der shared_ptr-Ansatz bietet dazu aber auch etwas an:

    class X : public std::shared_from_this<X>
{
};

int main()
{
  auto p = make_shared<X>();
  auto q = p->shared_from_this();
  assert(p == q);
}

    Da bleibt also nicht mehr viel übrig von dem, was man mit intrusive_ptr anstellen kann und was mit shared_ptr nicht geht oder ineffizienter ist. Mir fällt auch grad nix dazu ein.

    kk

    0
Anmelden zum Antworten