Bonjour,

J'avais une simple question par rapport aux pointeurs intelligents et nullptr

class Foo
{
public:
	Foo()
	{
		ptr = std::make_unique<int>(0);
	}

private:
	std::unique_ptr<int> ptr;
};

int main()
{
	std::unique_ptr<Foo> foo = std::make_unique<Foo>();

	foo = nullptr;
}

Qu'adviendra-t-il de ptr contenu dans foo ?

J'imagine que ptr ne sera pas désalloué et qu'on aura une fuite de mémoire, mais j'aimerais être sûr de moi.

-
Edité par Raynobrak 2 février 2019 à 12:08:03

Lu'!

Si, c'est le principe de unique_ptr. S'il ne faisait pas ça, il n'aurait pas grand chose d'intelligent. Ici, unique_ptr va appeller le destructeur de Foo sur l'objet alloué en interne puis mettre nullptr à la place. Comme l'objet interne "ptr" est aussi un unique_ptr, son destructeur est appelé à son tour, libérant l'entier.

Ksass`Peuk a écrit:

Lu'!

Si, c'est le principe de unique_ptr. S'il ne faisait pas ça, il n'aurait pas grand chose d'intelligent. Ici, unique_ptr va appeller le destructeur de Foo sur l'objet alloué en interne puis mettre nullptr à la place. Comme l'objet interne "ptr" est aussi un unique_ptr, son destructeur est appelé à son tour, libérant l'entier.

Et moi qui croyait avoir trouvé une faille dans les unique_ptr. C'est vrai que si il n'était pas capable de gérer un cas si banal, ils ne mériterait pas l’adjectif intélligent.

En tout cas, merci !

Ça n'a rien à voir avec unique_ptr. C'est tout simplement RAII et le destructeur de l'objet. Toutes les variables membres sont détruites par le destructeur de l'objet dans le sens inverse de leur déclaration (et donc de manière récursive).

{
    Foo f;
}
// f est détruit et appelle le destructeur de f.ptr

Et

auto f = make_unique<Foo>();
f = nullptr;
// identique

D'ailleurs, unique_ptr peut être configuré pour prendre un deleter en paramètre. Ce qui est particulièrement pratique pour wrapper des lib C.

std::unique_ptr<SDL_Window, void (*)(SDL_Window*)> win(
    SDL_CreateWindow(...),
    SDL_DestroyWindow
);

-
Edité par markand 4 février 2019 à 18:13:08