Hi Jason, On Fri, Aug 28, 2020 at 3:50 AM Jason Biggs <jasondbi...@gmail.com> wrote:
> > In my application, I have a wrapper class that I expose to top level > users, which holds a unique pointer to an ROMol. I know then that when my > wrapper class member goes away so does the ROMol. What I don't have is a > similar wrapper class for an Atom, precisely because of these ownership > questions - any atom properties or modifications go through the ROMol > wrapper class. > > I'm not very familiar with how the python interface works, is there a > similar issue with the python wrappers? Does the wrapper class for the > Atom clean up after itself differently if the atom is marked as having an > owner? Hope that question isn't too vague > Lifetime management of pointers, particularly pointers that are connected to each other (like molecules and the atoms that come from them) is, indeed, one of those tricky things. For the RDKit Python wrappers it actually ends up being pretty straightforward because boost::python, the library we use to create the wrappers, provides tooling for this case. Within boost::python when you return a pointer to an object you have to specify who owns the memory (i.e. is it an internal reference or a pointer to new memory that Python should clean up when it's done with it). Accompanying this is another mechanism that allows you to specify whether or not the lifetimes of objects should be linked. For example, when we expose the method Mol::GetAtomWithIdx() ( https://github.com/rdkit/rdkit/blob/master/Code/GraphMol/Wrap/Mol.cpp#L350) we tell boost::python that something else owns the pointer to the atom (in this case it's the molecule) and that the molecule should not be deleted as long as the atom still exists. -greg
_______________________________________________ Rdkit-discuss mailing list Rdkit-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rdkit-discuss
