Sicherer Zeiger Dereferenzierung in C++

Question

In unserem Code-Basis haben wir viele Konstruktionen wie folgt aus:

auto* pObj = getObjectThatMayVeryRarelyBeNull(); 
if (!pObj) throw std::runtime_error("Ooops!"); 
// Use pObj->(...) 

In 99,99% der Fälle diese Prüfung ausgelöst wird, nicht. Ich denke an die folgende Lösung:

auto& obj = deref_or_throw(getObjectThatMayVeryRarelyBeNull()); 
// Use obj.(...) 

Wo deref_or_throw wie folgt erklärt:

template<class T> T& deref_or_throw(T* p) { 
    if (p == nullptr) { throw std::invalid_argument("Argument is null!"); } 
    return *p; 
} 

Dieser Code viel klarer ist und funktioniert wie ich brauche.

Die Frage ist: erfinde ich das Rad neu? Gibt es eine verwandte Lösung in Standard oder Boost? Oder haben Sie Kommentare zur Lösung?

PS. Verwandte Fragen (ohne zufriedenstellende Antwort): Is there a C++ equivalent of a NullPointerException

Answer 1

Es gibt zwei Möglichkeiten, mit dem Problem "seltener Nullzeiger" umzugehen. Erstens ist es die vorgeschlagene Ausnahmelösung. Dafür ist die Methode deref_or_throw eine gute Sache, obwohl ich lieber eine runtime_error, als eine invalid_argument Ausnahme werfen würde. Sie können auch erwägen, es NullPointerException zu nennen, wenn Sie das bevorzugen.

Wenn jedoch der ptr != nullptr Fall tatsächlich eine Vorbedingung für den Algorithmus ist, sollten Sie Ihr Bestes versuchen, um 100% Sicherheit zu erreichen, wenn Sie diesen Nicht-Null-Fall haben. Eine assert ist in diesem Fall das Richtige.

Vorteile von assert:

• Keine Kosten zur Laufzeit im Release-Modus
• macht es glasklar in den Entwickler, dass er dies geschieht nie verantwortlich ist.

Nachteile assert:

• Potential nicht definiertes Verhalten im Release-Modus

Sie sollten auch prüfen, ein Verfahren zu schreiben getObjectThatMayNeverBeNullButDoingTheSameAsGetObjectThatMayVeryRarelyBeNull(): Ein Verfahren, das einen Nicht-Null-Zeiger zurück ist garantiert ein Objekt, das ansonsten völlig Ihrer ursprünglichen Methode entspricht. Wenn Sie jedoch die Extrameile gehen können, würde ich dringend empfehlen, einen rohen Zeiger sowieso nicht zurückzugeben. Embrace C++ 11 und Rückgabe von Objekten nach Wert :-)

Answer 2

Sie können und sollten wahrscheinlich mit null Fällen im Hinterkopf entwerfen. Zum Beispiel, in Ihrer Problemdomäne, wann ist es sinnvoll, dass Klassenmethoden null zurückgeben? Wann macht es Sinn, Funktionen mit null Argumenten aufzurufen?

Grob gesagt, kann es vorteilhaft sein, null Referenzen aus Code wann immer möglich zu entfernen. Mit anderen Worten, Sie können die Invariante so programmieren, dass "dies hier nicht Null ist ... oder dort". Dies hat viele Vorteile. Sie müssen Code nicht durch Umhüllungsmethoden in deref_or_throw verschleiern. Sie können mehr semantische Bedeutung durch Code erreichen, weil, wie oft sind die Dinge in der realen Welt null? Ihr Code ist möglicherweise besser lesbar, wenn Sie Ausnahmen anstelle von null Werten verwenden, um Fehler anzuzeigen. Und schließlich reduzieren Sie die Notwendigkeit zur Fehlerprüfung und reduzieren auch das Risiko von Laufzeitfehlern (die gefürchtete Nullzeiger-Dereferenzierung).

Wenn Ihr System nicht mit null Fällen konzipiert wurde, würde ich sagen, dass es am besten ist, es allein zu lassen und nicht verrückt, alles mit deref_or_throw wickeln. Vielleicht agiles Vorgehen. Untersuchen Sie beim Codieren die Verträge, die Ihre Klassenobjekte als Dienste anbieten. Wie oft können diese Verträge vernünftigerweise erwartet werden, dass sie null zurückgeben? Was ist der semantische Wert von null in diesen Fällen?

Sie könnten wahrscheinlich die Klassen in Ihrem System identifizieren, von denen erwartet werden kann, dass sie null zurückgeben. Für diese Klassen kann null eine gültige Geschäftslogik sein und keine Randfälle, die auf Implementierungsfehler schließen lassen. Für die Klassen, die voraussichtlich null zurückgeben, kann die zusätzliche Überprüfung die Sicherheit wert sein. In diesem Sinne fühlt sich das Überprüfen nach null mehr wie Geschäftslogik eher als Implementierungsdetails auf niedriger Ebene an. Auf der anderen Seite könnte die systematische Umhüllung aller Zeiger-Referenzen in deref_or_throw eine Heilung sein, die ihr eigenes Gift ist.