Ist es richtig, null zurückgeben shared_ptr?

Gibt es zum Beispiel eine Funktion, die feststellt, ein Objekt und gibt shared_ptr, wenn ein Objekt gefunden wird, und muss irgendwie zeigen, dass kein Objekt gefunden wurde.

std::vector<std::shared_ptr> Storage::objects;

std::shared_ptr<Object> Storage::findObject()
{
  if (objects.find)
  {
    return objects[x];
  }
  else
  {
    return nullptr;
  }
}

std::shared_ptr<Object> obj = Storage::findObject();
if (obj)
{
  print("found");
}
else
{
  print("not found");
}

  1. Ist es richtig, zurück shared_ptr implizit initialisiert mit nullptr wie im oberen Beispiel? Es wird funktionieren, aber kann es auf diese Weise getan? Oder sollte ich zurück shared_ptr-Standard konstruiert statt?

  2. Was im Fall wäre es weak_ptr? Was ist der richtige Weg, um zu überprüfen, dass die leeren weak_ptr zurückgegeben wurde? von weak_ptr::abgelaufen-Funktion oder gibt es andere Möglichkeiten? Wenn die überprüfung von weak_ptr::abgelaufen, ist der einzige Weg, dann, wie kann ich unterscheiden, dass die Funktion zurückgegeben leeren Zeiger oder Objekt wurde gerade gelöscht(multi-thread-Umgebung)?

  • eine alternative wäre eine exception werfen
  • Situation, wenn ein Objekt nicht gefunden wird, ist als Allgemeine situation, als wenn das Objekt gefunden ist.
  • ok, dann exception ist keine gute Wahl.
  • Ich denke, Sie haben Ihre eigene Frage beantwortet dann, John.
  • Wenn Sie verwenden können, zu steigern, optional<T> scheint zu sein, genau das, was Sie möchten (dies kommt in der standard C++17). Wenn Sie nicht möchten, dass der Aufwand, dann Sie haben im Grunde nur um zu dokumentieren, dass eine nullptr ist in der Tat ein fehlen von Wert und nicht ein Fehler.
  • Ich verstehe nicht, wo ich meine Frage selbst beantwortet? Ich wurde gefragt, ob es richtig ist zurückzukehren shared_ptr konstruiert mit nullptr(zeigt auf nichts) oder sollte ich leer zurück(Standard gebaut) Zeiger in der situation, Objekt nicht gefunden wurde.
  • Tritt ein Fehler in einer Funktion gerecht zu werden, berichtete der Anrufer, die breiten Möglichkeiten der Ansatz kann entweder einen Wert zurück, der angibt, einen Fehler oder eine exception werfen. In Ihren Kommentaren, Sie haben festgestellt, dass das werfen einer exception ist keine gute Wahl. Ein shared_ptr halten kann nullptr so ist dies eine gültige Wahl.
  • Aber sollte es nicht leer sein shared_ptr(Standard gebaut) anstelle von shared_ptr konstruiert mit nullptr? Ich denke, es ist der Unterschied zwischen den beiden.
  • Nein, es gibt keinen Unterschied.
  • Aus (cplusplus.com/reference/memory/shared_ptr ) - "Ein shared_ptr, der nicht besitzt, der Zeiger wird genannt eine leere shared_ptr. Ein shared_ptr, verweist auf kein Objekt genannt ist ein null shared_ptr und darf nicht aufgelöst werden. Beachten Sie aber, dass eine leere shared_ptr ist nicht notwendigerweise ein null-shared_ptr, und eine null shared_ptr ist nicht unbedingt eine leere shared_ptr."
  • Das ist falsch.
  • können Sie erklären, warum es falsch ist?
  • Für shared_ptr<>::shared_ptr() (die default-ctor), die standard-post-Bedingungen zeigen, dass use_count() == 0 && get() == nullptr. Also, wenn manche Umsetzung nicht haben, es ist falsch, denn es ist nicht standard-konform. (20.10.2.2.1)
  • Ich nehme es zurück. Dieser Absatz ist nicht falsch. Aber Ihre Schlussfolgerung daraus ist falsch. Ein shared_ptr konstruiert aus nullptr ist das gleiche wie ein Standard gebaut shared_ptr. Dies kann jedoch anders sein als ein shared_ptr konstruiert mit ein typisierter null-Zeiger (d.h. (Objekt*)0).
  • JohnLock, @BenjaminLindley . stackoverflow.com/q/25920681/5447906

InformationsquelleAutor John Lock | 2016-05-15
  1. 12

    Ist es richtig, zurück shared_ptr implizit initialisiert mit nullptr wie im oberen Beispiel?

    Ja, es ist richtig zu initialisieren shared_ptr mit nullptr. Es ist auch richtig zuordnen nullptr zu shared_ptr.

    Oder sollte ich zurück shared_ptr-Standard konstruiert statt?

    Können Sie dies in beide Richtungen:

    1. Rückkehr shared_ptr initialisiert mit nullptr

      return shared_ptr<Object>(nullptr);

    2. Rückkehr shared_ptr Standard gebaut.

      return nullptr;

    Beide Wege sind richtig und beide haben die gleiche Wirkung. Sie können verwenden, was auch immer, wie Sie wollen.

    Was im Fall wäre es weak_ptr? Was ist der richtige Weg, um zu überprüfen, dass die leeren weak_ptr zurückgegeben wurde? von weak_ptr::abgelaufen-Funktion oder gibt es andere Möglichkeiten?

    weak_ptr wird nullptr (erlischt), wenn der Letzte shared_ptr im Zusammenhang mit Objekt zerstört wird.

    Den richtigen Weg, um die Arbeit mit weak_ptr ist, es zu konvertieren, um shared_ptr mit lock Methode, und dann die Arbeit mit erstellt shared_ptr. In diesem Fall Ihre weak_ptr wird nicht erlöschen, bis Sie, dass haben neue shared_ptr. Wenn Sie sich nicht bekehren weak_ptr in shared_ptr Ihre weak_ptr ablaufen, in jedem moment.

    Und ja, bevor Sie arbeiten mit neu erstellten shared_ptr müssen Sie prüfen, ob es nicht null ist, weil weak_ptr kann worden ist abgelaufen, bevor Sie erstellt shared_ptr mit lock Methode.

    std::weak_ptr<Object> Storage::findObject();

...

std::weak_ptr  <Object> weak   = Storage::findObject();
std::shared_ptr<Object> shared = weak.lock();
if (shared) //check that weak was not expired when we did "shared = weak.lock()"
{
    //do something with shared, it will not expire.
}
    InformationsquelleAutor anton_rh
Schreibe einen Kommentar