Re: Member variables dependency policy

On Tue, Mar 23, 2010 at 01:42:15PM -0700, Max McGuire wrote:
> I'm running into a problem with luabind automatically creating a dependency
> between a member variable and the parent object. This functionality is
> described in the documentation:
> 
> struct A { int m; };
> struct B { A a; };
> 
> When binding B to lua, the following expression code should work:
> 
> b = B()
> b.a.m = 1
> assert(b.a.m == 1)
> 
> This requires the first lookup (on a) to return a reference to A, and not a
> copy. In that case, luabind will automatically use the dependency policy to
> make the return value dependent on the object in which it is stored. So, if
> the returned reference lives longer than all references to the object (b in
> this case) it will keep the object alive, to avoid being a dangling pointer.
> 
> In my case, B actually contains a pointer to A, and B does not own this
> pointer. The object being pointed to is expected to outlive the instance B,
> which causes a problem.  When I access "a" from Lua, luabind creates a
> dependency between a and b so that b won't be collected until a is
> collected. Since a outlives b, this creates a condition where I accumulate
> dependencies and Lua is never able to garbage collect them.
> 
> I was able to work around this by creating getter/setter methods for the "a"
> member variable (without the dependency policy), but I'm wondering what the
> correct way to solve this problem is.

Interesting. I can see two solutions:

1. Change the default behaviour so that pointer members doesn't
   imply a dependency.

2. Add a dummy policy, similar to "yield", that can be used to suppress
   the dependency:

     def_readwrite(&B::a, no_dependency)

I'm leaning toward (2) because it's generally more safe to assume
ownership. Doing (1) might mean we end up with a lot of code that SHOULD
use dependency() but doesn't because the user overlooked the detail.
Also, (1) breaks backward compatibility, but I'm willing to do that if
it's a better design.

What do you think?

-- 
Daniel Wallin
BoostPro Computing
http://www.boostpro.com

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev