2017-01-19 4 views
-1

Ich frage mich, ob intelligente Zeiger auf statische Objekte sinnvoll sind. Nehmen wir zum Beispiel an, dass ich eine statische Ressource habe und einen Verweis auf diese statische Ressource an einige andere Objekte weitergeben möchte, mit denen diese Ressource arbeiten soll.Sind shared_ptr auf statische Objekte gut?

Eine Möglichkeit wäre, die RAW-Pointer zu verwenden, die auf diese Ressource zeigen. Aber jetzt frage ich mich, ob intelligente Zeiger (shared_ptr) der bessere Weg sind und wenn ja, wie man es richtig macht. (Sollte der Smart Pointer auch statisch sein?).

Hintergrund der Frage: Wenn keine Objekte mehr einen Smart Pointer enthalten, würde das statische Objekt, auf das der Smart Pointer zeigt, freigegeben werden (was nicht die beste Idee ist ...).

Ein Beispiel (die am Ende der Laufzeit in einem Crash-Enden):

struct SomeType { 
    SomeType() { cout << "ctor..." << endl; } 
    ~SomeType() { cout << "dtor..." << endl; } 

    void sayHello() { cout << "Hello!" << endl; } 
}; 


void someFunction(shared_ptr<SomeType> smartPointer) { 
    smartPointer->sayHello(); 
} 

static SomeType st; 
static shared_ptr<SomeType> pt{ &st }; 

void anotherFunction() { 

    someFunction(pt); 
} 

int main() { 
    anotherFunction(); 

    cin.get(); 

} 
+4

Es gibt hier überhaupt keine Notwendigkeit für shared_ptr. – SergeyA

+8

Smart Pointer dienen zur besseren Verwaltung von * dynamischen * Lebensdauern. Statische Variablen haben bereits eine * statische * Lebensdauer. – jaggedSpire

+4

"Eine Möglichkeit wäre, die RAW-Pointer zu verwenden, die auf diese Ressource zeigen" Es ist naheliegend, einen Verweis auf die Ressource zu verwenden. Warum willst du das nicht tun? –

Antwort

4

Die folgenden zwei Zeilen sind nicht gültig.

static SomeType st; 
static shared_ptr<SomeType> pt{ &st }; 

Wenn pt am Ende des Prozesses Lebenszeit zerstört wird, wird es delete st. st wurde nie mit einem übereinstimmenden new zugewiesen. Dies ist ein nicht definiertes Verhalten.

shared_ptr ist nützlich für die Verwaltung der komplexen Lebensdauer von gemeinsamen Objekten, während static Objekte sehr einfache Lebensdauern haben. Es ist falsch, shared_ptr zu verwenden, um static Objekte zu verwalten, und es gäbe nichts zu gewinnen.

+2

Es ist nicht falsch, 'shared_ptr' zu verwenden, es ist falsch,' shared_ptr' mit dem Standardlöscher zu verwenden. –

+0

"_static Objekte haben sehr einfache Lebensdauern_" Namespace Scope statisch von Funktion Scope statisch? – curiousguy

-1

nehmen wir an, dass ich (wie die Klasse Autor) weiß nicht, ob das Objekt statisch oder dynamisch ist

Code, der absolut Agnostiker sein muss sollte shared_ptr<T> verwenden.

Dieser Code ist ungültig, weil er das Löschen eines Objekts mit statischer Lebensdauer verursacht.

static SomeType st; 
static shared_ptr<SomeType> pt{ &st }; 

Das ist ganz gut:

static SomeType st; 
static shared_ptr<SomeType> pt{ std::shared_ptr<SomeType>{}, &st }; 

und dass pt mit "normalen" Shared_ptr Instanzen untereinander ausgetauscht werden. std::shared_ptr ist besonders praktisch in dieser Hinsicht, weil die Anwesenheit oder Abwesenheit eines deleter nicht den Zeigertyp wirkt sich (im Gegensatz dazu ist std::unique_ptr<T, custom_deleter<T>> eine andere Art von `std :: unique_ptr>)

Diese und andere Möglichkeiten zu spezifizieren ein deleter, der nichts tun bei beschrieben: