Jason Biggs
On Fri, Aug 28, 2020 at 8:16 PM dmaziuk via Rdkit-discuss <
rdkit-discuss@lists.sourceforge.net> wrote:
> On 8/27/2020 8:48 PM, Jason Biggs wrote:
> >
> > I'm not very familiar with how the python interface works, is there a
> > similar issue with the python wrappers? Does the
Hi Jason,
On Fri, Aug 28, 2020 at 3:50 AM Jason Biggs 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
On 8/27/2020 8:48 PM, Jason Biggs wrote:
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?
There Be Dragons.
Python VM
On 8/28/2020 12:30 AM, Paul Emsley wrote:
Isn't this the soft of undefined behaviour that one would expect when
accessing deleted memory? Try adding some code between the deletion of
mol and the access of atom that allocates and deallocs some memory for a
second or so.
Anyway, I wouldn't
Hi Jason.
to pinpoint potential memory issues you may run your code through valgrind.
For example, it would flag access to previously freed memory in your
program:
1 #include
2 #include
3 #include
4
5 int main() {
6 auto mol =
On 27/08/2020 20:15, Jason Biggs wrote:
Everything I know about C++ I learned just so that I can write a link
between an interpreted language and the rdkit, so there are definitely
some gaps in my knowledge.
What I'm trying to understand right now is the expected lifetime of an
Atom pointer
On Thu, Aug 27, 2020 at 4:33 PM David Cosgrove
wrote:
> Hi Jason,
> The answer is that when you delete the molecule, the memory it uses is
> flagged as available for re-use, but nothing else happens to it. If you
> then de-reference pointers to it, such as the atoms that are buried in the
>
In RDKit, atoms are owned by the molecule. When you ask for:
auto atom = mol->getAtomWithIdx(0);
You are asking for a pointer to memory internally owned by the
RDKit::ROMol. However:
auto mol = RDKit::SmilesToMol("");
creates a new molecule in memory, so it's your job to delete it. This
Hi Jason,
The answer is that when you delete the molecule, the memory it uses is
flagged as available for re-use, but nothing else happens to it. If you
then de-reference pointers to it, such as the atoms that are buried in the
block of memory allocated to the molecule, you may get away with it
On 8/27/2020 3:06 PM, Nils Weskamp wrote:
To add to this: you are looking at the wonderful concept of an
"undefined behavior" in C/C++. There is no guarantee that your example
program will always show the same behaviour.
In more recent versions of C++, you have access to "smart pointers" like
To add to this: you are looking at the wonderful concept of an
"undefined behavior" in C/C++. There is no guarantee that your example
program will always show the same behaviour.
In more recent versions of C++, you have access to "smart pointers" like
std::shared_ptr, which basically implement
On 8/27/2020 2:15 PM, Jason Biggs wrote:
What I'm trying to understand right now is the expected lifetime of an Atom
pointer returned by a molecule, for instance by the getAtomWithIdx method.
Based on the documentation, since this method doesn't say the user is
responsible for deleting the
Everything I know about C++ I learned just so that I can write a link
between an interpreted language and the rdkit, so there are definitely some
gaps in my knowledge.
What I'm trying to understand right now is the expected lifetime of an Atom
pointer returned by a molecule, for instance by the
13 matches
Mail list logo
