Sur la partie __del__, j'ai bien conscience qu'il existe des cas limites. Comme tu le soulignes, rien n'empêche d'exploiter par le développeur en appelant malib.liberer_valeurretour( obj_ptr ) "au bon moment" (celui qui serait attendu).
Sur le deuxième point c'est effectivement un corollaire à ton commentaire initial : ne connaissant pas tous les pointeurs vers un objet en mémoire, on ne connaît pas l'usage de tous ces pointeurs potentiels.
Par contre je m'interroge sur le caractère automatique de la désallocation de la stratégie d'emprunt et de suppression de Rust. Peut-être auras-tu une réponse ?
... c'est le cas de mon exemple. La mémoire est libéré par Rust, car il a la possession. Si un pointeur existe vers cette valeur en mémoire, c'est embêtant mais pas pour l'objet source : pour celui-ci, pas de problème.
Si par contre j'avais eu un partage mutable ou non :
structMonObjet{champ: &UnAutreObjet// multiples emprunts non-mutables possibles }structMonObjet{champ: &mutUnAutreObjet// un seul emprunt mutables possible }
... Rust n'aurait pas libéré la mémoire, car il n'a pas de possession mais d'emprunt. La désallocation dans de tel cas, invaliderait gravement le fonctionnement des durées de vie.
Ça marche parce que tu copies les valeurs du tableau rust dans un tableau python.
Dans l'exemple, ma compréhension du phénomène est la suivante : le passage dans liberer_valeurretour supprime le tableau car j'ai déclaré côté Rust, la pleine possession de celui-ci.
"la gérer correctement dans une couche glue entre deux langages qui n'ont pas les mêmes logiques de gestion mémoire n'est pas une mince affaire."
Ce journal à au moins cet avantage de (bien) mettre en lumière qu'on peut se prendre facilement les pieds dans le tapis, oui. Mais sinon on ne progresse pas :)
PS : hâte de lire ça si tu fais un journal sur le sujet.
[^] # Re: memforget et fuite mémoire
Posté par JulienG . En réponse au journal cTypes + Rust = approfondir une relation d'amour et d'eau (fraîche). Évalué à 2.
Merci de ton retour et de tes alertes !
Sur la partie
__del__, j'ai bien conscience qu'il existe des cas limites. Comme tu le soulignes, rien n'empêche d'exploiter par le développeur en appelantmalib.liberer_valeurretour( obj_ptr )"au bon moment" (celui qui serait attendu).Sur le deuxième point c'est effectivement un corollaire à ton commentaire initial : ne connaissant pas tous les pointeurs vers un objet en mémoire, on ne connaît pas l'usage de tous ces pointeurs potentiels.
Par contre je m'interroge sur le caractère automatique de la désallocation de la stratégie d'emprunt et de suppression de Rust. Peut-être auras-tu une réponse ?
Premier cas :
... c'est le cas de mon exemple. La mémoire est libéré par Rust, car il a la possession. Si un pointeur existe vers cette valeur en mémoire, c'est embêtant mais pas pour l'objet source : pour celui-ci, pas de problème.
Si par contre j'avais eu un partage mutable ou non :
... Rust n'aurait pas libéré la mémoire, car il n'a pas de possession mais d'emprunt. La désallocation dans de tel cas, invaliderait gravement le fonctionnement des durées de vie.
Dans l'exemple, ma compréhension du phénomène est la suivante : le passage dans
liberer_valeurretoursupprime le tableau car j'ai déclaré côté Rust, la pleine possession de celui-ci.Ce journal à au moins cet avantage de (bien) mettre en lumière qu'on peut se prendre facilement les pieds dans le tapis, oui. Mais sinon on ne progresse pas :)
PS : hâte de lire ça si tu fais un journal sur le sujet.