Discussion :

[GrosLapin]

Bonjour à tous,

Débutant avec les pointeurs intelligents (vieux motard que jamais ) j'ai rencontrer un problème qui a soulevé plusieurs questions.

Je vous pose le contexte de maniérè très simplifié : Je suis en train de créer un petit "tower défense" (dans un but pédagogique) qui contient des Cases qui contiennent des "éléments de jeu" (dans une collection quelconque de weak_ptr puisque la Case ne souhaite pas gérer la mémoire mais uniquement pouvoir regarder s'il y a des gens dedans). Une case est dite "occupé" si il y a au moins un élément de jeu dedans. J'ai ensuite créé une Tour qui est un élément de jeu et qui prend en paramètre du constructeur une case.
Et voila, le drame arrive :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
Tour(Case& maCase)
{
    [...]
    maCase.addElementJeu(shared_from_this());
}

Et c'est le Bad_Weak_Ptr \o/

Un coup de google, on me dit que mon objet est pas completement construit et que je peux pas faire ça... Ok. Bon pas dramatique je vais faire une fonction statique [type de retour à réfléchir] CreerTour(Case&), un constructeur en protected et j'aurais ce que je veux.

Cependant j'ai deux questions que j'arrive pas résoudre :

1. Comment la fonction shared_from_this sait que j'ai pas fini le constructeur, je veux dire, elle vient d'une classe mère qui devrait être initialisé avant de rentrer dans le constructeur, comment elle sait que l'objet est pas fini d’être construit ?
2. Qu'est ce que ça veux dire ne pas être complétement construit ? Qu'est ce que mon objet a concrètement de plus entre la dernière ligne de mon constructeur et le moment ou il est construit ?
3. Ce que je faisais avant (quand j'utilisais pas les qqch_ptr) aurait était de faire maCase.addElementJeu(this) je suppose qu'il doit aussi y avoir un problème d'objet mal construit mais je vois pas lequel...

Et oui ça fait trois questions \o/

Si vous pouvez m'éclairer, je suis preneur

GrosLapin

[Trademark]

Est-ce que ton objet Tour est instancié dans un shared_ptr<Tour> ?

[GrosLapin]

J'ai pas mon code sous les yeux mais ça je crois pas.
En version minimaliste :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
 
using namespace std;
 
struct Tour;
struct Case
{
    vector<weak_ptr<Tour>> vecTour;
    void addTour(weak_ptr<Tour> wpT) { vecTour.push_back(wpT);}
};
 
struct Tour : public enable_shared_from_this<Tour>
{
    Tour (Case& uneCase)
    {
        uneCase.addTour(shared_from_this());
    }
};
 
int main ()
{
    Case uneCase;
    Tour uneTour(uneCase);  // call un std::bad_weak_ptr
    shared_ptr<Tour> test = make_shared<Tour>(uneCase); // call un std::bad_weak_ptr
}

J'ai testé aussi en le mettant dans un shared_ptr comme tu le suggères mais ça change rien

Ps : Ceci étant à part si j'ai loupé quelque chose d’énorme (ce qui peut tout à fait être le cas) je cherche plus des réponses aux questions qu'une solution pour mon code ^^

[Iradrille]

Hello,

Si je dis pas de conneries, shared_from_this ne doit pas être appelé depuis le constructeur.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
using namespace std;
 
struct Tour;
struct Case {
	vector<weak_ptr<Tour>> vecTour;
	void addTour(weak_ptr<Tour> wpT) { vecTour.push_back(wpT);}
};
 
struct Tour : public enable_shared_from_this<Tour> {
	static shared_ptr<Tour> create(Case& c) {
		auto t = make_shared<Tour>();
		c.addTour(weak_ptr<Tour>(t));
		return t;
	}
 
private:
	Tour ()	{ }
};
 
int main () {
    Case uneCase;
    auto tour = Tour::create(uneCase);
}

(Le nom "Case" est à éviter : risque de confusion avec le mot-clef)

[foetus]

un petit lien peut-être utile : Checked delete

[TropMDR]

Si je dis pas de conneries, shared_from_this ne doit pas être appelé depuis le constructeur.

La partie importante est que shared_from_this ne peut etre appele que sur un objet qui est deja géré par un shared_ptr (c'est la creation de ce shared_ptr qui va initialiser le weak_ptr a l'interieur du enable_shared_from_this).

Or dans le constructeur, l'objet n'est pas encore géré par un shared_ptr, donc son weak_ptr n'est pas initialisé, d'où l'erreur que tu reçois.

Mais de façon générale, tu devrais eviter les shared_ptr autant que faire ce peux. La majorité du temps, tu devrais pouvoir trouver qui "possède" un certain objet. Dans ton cas, il me semble qu'il serait naturelle que la case possède la Tour, et donc aie un unique_ptr.

[GrosLapin]

Merci pour vos réponses et désolé pour mon temps de réponse, j'avais pas le net

@Iradrille

Si je dis pas de conneries, shared_from_this ne doit pas être appelé depuis le constructeur.

Yep, effectivement, mais ce que je comprends pas c'est comment il sait que je suis encore dans le constructeur ?

@foetus
Je suis pas sur d'avoir bien compris :'( l'astuce du checked delete c'est pour quand on ne connais pas encore le type (déclaration incomplète) si j'ai bien compris ton lien. Ca voudrais dire qu'on ne connait pas la taille d'un type dans son constructeur ?

@TropMDR

Mais de façon générale, tu devrais eviter les shared_ptr autant que faire ce peux.

Le problème que j'ai avec les unique_ptr c'est : Comment permettre à une autre classe d'avoir le droit de regarder la ressource sans utiliser un pointeur nu (On m'a dit que le but des pointeurs intelligents était de pouvoir se passer des pointeurs nus)

GrosLapin

[Trademark]

Merci pour vos réponses et désolé pour mon temps de réponse, j'avais pas le net

@Iradrille
Yep, effectivement, mais ce que je comprends pas c'est comment il sait que je suis encore dans le constructeur ?

Comme l'a dit TropMDR, tu ne peux appeler shared_from_this que si l'objet en question est déjà géré par un shared_ptr, or vu que tu es dans le constructeur, l'objet n'est pas encore créé est donc pas encore géré par un shared_ptr.

Le problème que j'ai avec les unique_ptr c'est : Comment permettre à une autre classe d'avoir le droit de regarder la ressource sans utiliser un pointeur nu (On m'a dit que le but des pointeurs intelligents était de pouvoir se passer des pointeurs nus)
GrosLapin

Tu peux utiliser une référence pour utiliser ce unique_ptr, quel serait le problème ?

[JolyLoic]

Pour l'utilisation des pointeurs nus, la bonne pratique actuelle est de ne pas utiliser de pointeurs nus qui auraient un rôle dans la durée de vie des objets pointés. Là, tu ne fais qu'observer les données, donc pas de soucis. Il y a une proposition en cours pour ajouter un pointeur dont le rôle serait d'être plus explicite sur le fait qu'il ne fait qu'observer, mais ce n'est pas encore fait.

Pour le shared_from_this depuis un constructeur, moi aussi j'avais du mal à comprendre au début. Mais en fait, il faut bien voir que la construction se fait en deux étapes : On crée l'objet, qui peut très bien ne jamais être géré ni par pointeur shared_ptr, ni même par pointeur nu (mais simplement comme une variable locale, par exemple), on réserve juste dans cet objet un peu de place pour plus tard. Par la suite, quand on construit un shared_ptr en lui passant en argument l'adresse de l'objet, à ce moment là uniquement on sait que l'objet va être géré par le shared_ptr, et c'est donc ce dernier qui va utiliser cet espace mémoire réservé afin de permettre à shared_from_this de marcher.

Donc, la règle n'est pas : "pas de shared_from_this dans le constructeur" mais "pas de shared_from_this avant d'avoir créé un shared_pointeur pointant sur cet objet."

Tu vas me dire : Très bien, mais dans mon cas, les objets seront toujours gérés par shared_ptr, je m'en moque qu'il puisse prendre en compte des variables locales, j'aimerais qu'il fasse le travail quoi qu'il arrive. Ce à quoi je répondrais : Très bien, l'idiome pour t'assurer que c'est effectivement le cas consiste justement à créer une fonction factory retournant un shared_ptr, et rendre le constructeur non accessible.

[JolyLoic]

Tu peux utiliser une référence pour utiliser ce unique_ptr, quel serait le problème ?

Le fait qu'une référence soit non-réaffectable est souvent problématique, et le pointeur nu reste justifié dans ce genre de cas.

[foetus]

@foetus
Je suis pas sur d'avoir bien compris :'( l'astuce du checked delete c'est pour quand on ne connais pas encore le type (déclaration incomplète) si j'ai bien compris ton lien. Ca voudrais dire qu'on ne connait pas la taille d'un type dans son constructeur ?

Tu te demandais ce qu'est un type incomplet. Ne pas avoir de destructeur propre (dû essentiellement a une déclaration incomplète) est une réponse.
Et rien qu'avec un sizeof on le détecte

Et comme l'a dit Iradrille (mettre un shared_from_this dans un constructeur c'est [sûrement] un problème connu) et comme l'a expliqué JolyLoic (une construction en plusieurs étapes) tout ceci explique le pourquoi du comment

[TropMDR]

Le problème que j'ai avec les unique_ptr c'est : Comment permettre à une autre classe d'avoir le droit de regarder la ressource sans utiliser un pointeur nu (On m'a dit que le but des pointeurs intelligents était de pouvoir se passer des pointeurs nus)

Il n'y a aucun problème à utiliser les pointeurs nus. L'idée avec un unique_ptr, c'est d'exprimer qui a la possession du pointeur, et que cette possession est unique. Mais ca ne veux pas dire que personne d'autre ne peux accéder au pointeur, juste que la durée de vie de l'objet pointé est définie par la durée de vie du unique_ptr. Par exemple, le code suivant est parfaitement acceptable

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
#include <iostream>
#include <map>
#include <memory>
#include <string>
 
// Je suis contre l'ouverture de namespace, mais ici, ca ira.
using namespace std;
 
template <typename K, typename V>
class MyMap {
 public:
  MyMap() {}
  // Prends possession du pointeur.
  void Insert(const K& k, unique_ptr<V> v) {
    map_[k] = move(v);
  }
 
  // L'appelant n'a pas possession du pointeur.
  V* Get(const K& k) {
    auto iter = map_.find(k);
    if (iter == map_.end()) {
      return nullptr;
    } else {
      return iter->second.get();
    }
  }
 
  // L'appelant prend possession du pointeur.
  unique_ptr<V> Release(const K& k) {
    auto iter = map_.find(k);
    if (iter == map_.end()) {
      return nullptr;
    } else {
      unique_ptr<V> result;
      result.swap(iter->second);
      map_.erase(iter);
      return result;
    }
  }  
 
 private:
  map<K, unique_ptr<V>> map_;
};
 
 
int main() {
  MyMap<int, string> my_map;
  my_map.Insert(1, unique_ptr<string>(new string("number one")));
  cout << *(my_map.Get(1)) << endl;
  unique_ptr<string> content = my_map.Release(1);
  if (my_map.Get(1) == nullptr) {
    cout << "C'est bien null!" << endl;
  }
}

où l'usage de pointeur nu vs unique_ptr exprime le passage de possession (ownership)

[Ehonn]

Dans ton exemple, la méthode Get pourrait renvoyer une référence. Je pense que cela a plus de sens sémantiquement.

Comme l'a dit JolyLoic :

Le fait qu'une référence soit non-réaffectable est souvent problématique, et le pointeur nu reste justifié dans ce genre de cas.

Dans ce cas, il faudrait un autre pointeur intelligent qui dit que l'objet existe forcément (et qu'on n'a pas la responsabilité de la mémoire) (un truc qui pourrait s'appeler ref_ptr par exemple :E).

[ternel]

Ce n'est pas plus ou moins le role du weak_ptr?

[Ehonn]

weak_ptr est à utiliser avec shared_ptr.
La sémantique de weak_ptr n'est pas : «l'objet existe forcément» (contrairement au "ref_ptr" que je propose).

[jo_link_noir]

std::reference_wrapper ?

[Ehonn]

Oui j'avais zappé que l'opérateur de copie faisait ce que l'on voulait ici :s
(j'aurais, peut être, préféré que non)

[GrosLapin]

Encore merci pour ces réponses,

Je pense avoir mieux compris donc je tag en résolu.

@JolyLoic

Pour le shared_from_this depuis un constructeur, moi aussi j'avais du mal à comprendre au début. Mais en fait, il faut bien voir que la construction se fait en deux étapes : On crée l'objet, qui peut très bien ne jamais être géré ni par pointeur shared_ptr, ni même par pointeur nu (mais simplement comme une variable locale, par exemple), on réserve juste dans cet objet un peu de place pour plus tard. Par la suite, quand on construit un shared_ptr en lui passant en argument l'adresse de l'objet, à ce moment là uniquement on sait que l'objet va être géré par le shared_ptr, et c'est donc ce dernier qui va utiliser cet espace mémoire réservé afin de permettre à shared_from_this de marcher

C'est ce qui me manquait
Edit : Est ce que par hasard tu aurais un lien qui rentre plus dans le détail de la construction des objets (je dois pas avoir les bons mots clés je suis pollué par les articles pour les grands débutants)

@JolyLoic + @TropMDR

Pour l'utilisation des pointeurs nus, la bonne pratique actuelle est de ne pas utiliser de pointeurs nus qui auraient un rôle dans la durée de vie des objets pointés. Là, tu ne fais qu'observer les données, donc pas de soucis.

Ok j’intègre ça dans mes bonnes pratiques

@jo_link_noir

std::reference_wrapper ?

Le problème du reference_wrapper c'est que j'ai besoin d'avoir un tableau (std::array) dans l'une de mes classe et que je peux pas faire un std::array de reference_wrapper... enfin plus exactement je peux pas faire un tableau qui ne soit pas complétement rempli, or dans mon cas ça a un sens d'avoir un tableau qui fasse "NULL, NULL, qqch, qqch, NULL , qqch" il faudrait peut être que je cherche vers le std::optional mais ça me semblait compliquer beaucoup mon code pour juste éviter un pointeur.

Encore merci pour vos réponses.

GrosLapin