Re: Creating C++ objects from PyRoot/GaudiPython vs. from C++

<wlavrijsen_at_lbl.gov> writes:

> which version of ROOT are you using? I'm guessing it's "too old." Actually,
> _creates is even older than having it work with constructors, which was its
> own can of worms.

I am using 5.26/00e. I do find that the __init__ of classes (but not namespaces) have ._mempolicy (which returns -1).

> Assuming that the version you use is new enough, each method has a _mempolicy
> member which can be set similarly to the global one. The other option is the
> use of SetOwnership(). See here:
>
> http://wlav.web.cern.ch/wlav/pyroot/memory.html

Thanks, this contains useful descriptions. The "ROOT.SetOwnership(obj,False)" acts as expected for me.

In the mean time I had empirically found out that I can add a little static method to the data class:  

 static UserDataHeader* create() { return new UserDataHeader; }

This is callable from Python and the result is not memory managed by Python. It's a bit dangerous as it will lead to a leak unless it can find its way into an event store (or something that does Gaudi ref-counting).

> Maybe ... With "heuristics" memory policy, if an object is passed through
> a non-const pointer function argument, it is considered owned by C++ after
> that. ROOT is very consistent in its interfaces, which is why that works.
> Not so in Gaudi, so there the policy is "strict."
>
> What I'm thinking of, is if the object is passed to C++ for adding it to
> the event store, that it passes through a function that takes a non-const
> pointer to it. Then, if the _mempolicy of that function is set to
> ROOT.kMemoryHeuristics, ownership would always be given up.

Yes, I'll try this. Worse case, I can arrange to have SetOwnership() called explicitly.

As always, thanks for the help,
-Brett.