Ich glaube nicht, dass Ihre Frage spezifisch für unique_ptr ist, sondern generell nach intelligenten Zeigern fragt.
Herb Sutter schrieb darüber a vor langer Zeit . Anscheinend würde es Ihnen erlauben, logisch fehlerhaften Code wie:
zu schreiben %Vor%und anderer Code wie dieser.
Es gibt einige ärgerliche Fehler, die passieren können, wie andere gezeigt haben, wie
%Vor%und
%Vor%Und so weiter. Es ist nur sicherer, wenn man bedenkt, dass diese Sprache für Menschen gedacht ist, um diesen Fallstricken auszuweichen, indem man in solchen Fällen alles explizit macht.
Ich habe keine formelle Antwort, aber ich habe eine Idee, warum das nicht viel Sinn machen würde. Die ganze Idee von unique_ptr ist eine stark typisierte (d. H. Durch den Compiler erzwungene) Möglichkeit, ein eindeutiges Eigentum an einem Objekt zu tragen. Daher die Umzugs-Semantik.
In diesem Kontext macht es Sinn, dass unique_ptr Sie explizit dazu auffordert, seinen rohen Zeiger anzufordern, denn sobald Sie den rohen Wert haben, können Sie alles leicht brechen: Sie könnten delete it, Sie könnten übergeben Sie es an einen anderen intelligenten Zeiger (der es an einem bestimmten Punkt löschen würde), oder führen Sie Zeigerarithmetik aus und arbeiten Sie versehentlich mit dem Ergebnis (das möglicherweise nicht auf zugewiesenen Speicher verweist) oder ähnlichem. Ein Teil davon kann sofort zu Compiler-Fehlern führen, andere können zu undefiniertem Verhalten führen. Für eine High-Level-Klasse wie unique_ptr ist dies nicht wünschenswert, zumindest nicht implizit. Natürlich können Sie das auch mit .get() tun, aber in diesem Fall wissen Sie , dass Sie den rohen Zeigerwert verwenden und ihn nicht freigeben müssen.
Der Link von Ami ist auch sehr relevant, aber ich denke, ein anderes Beispiel ist besser zitiert:
%Vor%Die C ++ - Philosophie besagt, dass öffentliche Funktionen , die für einen bestimmten Typ arbeiten können, zu der Schnittstelle dieses Typs gehören. Das Steuern und Beschränken der Schnittstelle eines Typs, der implizit in einen Zeiger umgewandelt wird, ist praktisch unmöglich. Die absichtlich restriktive Art von intelligenten Zeigern würde vollständig dekonstruiert werden, was zu fehleranfälligem Code führen würde.