Envoyé par
JolyLoic
Ah, enfin un truc un peu louche dans ton code
Je ne suis pas certain que ce soit lié, mais pourquoi ne pas avoir simplement un namespace global créé dynamiquement comme les autres, et dans ta classe program, une seul variable membre, de type std::shared_ptr<namespace_> ?
Parc'queeeee ! C'est pas optimisé comme ça ! Et ça n'a rien d'une optimisation prématurée. On est pas en java .
Bien, plus sérieusement, je teste ça immédiatement.
(…)
Hélas cela ne change rien. De plus, que le namespace global soit créé dynamiquement ou statiquement, si j'utilise le système que j'ai mis en place le temps de régler ce problème, tout fonctionne bien :
Le propriétaire de chaque namespace passe au namespace une copie d'un shared_ptr vers lui-même (le namespace), voir namespace_::shared_this() et m_shared_this.
Ainsi, lors de l'exécution de namespace_::add(), où le namespace doit passer un pointeur vers lui-même à son enfant (le namespace_item, ou dans mon code le namespace_ tout court, car je vais surcharger add() pour chaque type d'item), le namespace n'a plus qu'à passer m_shared_this à son enfant (le fameux shared_ptr persistant dont j'ai parlé dans mon premier post) en lieu et place où j'aimerais plutôt écrire shared_from_this().
Ça renforce l'hypothèse que le problème vient de shared_from_this(). Si je laisse shared_from_this(), j'ai immanquablement droit à une exception de type bad_weak_ptr.
Envoyé par
JolyLoic
Autre point, sans rapport avec ton problème, pourquoi ne pas faire retourner à namespace_item::parent() un shared_ptr, tout en gardant un weak_ptr comme donnée membre ? Ca simplifierait probablement l'utilisation de cette fonction.
Il me semblait qu'un shared_ptr généré à partir d'un weak_ptr devait rester le plus temporaire possible. D'autant plus que la fonction pour obtenir ce shared_ptr s'appelle weak_ptr::lock(). Ça sonne un peu mutex, ça me donne pas envie de créer un shared_ptr persistant à partir de ça !
Partager