Re: Userdata Lifetime Management

[Carsten Fuchs <carsten.fuchs@...>]

Hi Vinnie,

Am 2012-07-05 00:32, schrieb Vinnie Falco:
> > From: Carsten Fuchs <carsten.fuchs@cafu.de>
> >       a.temporaryLuaOnlyNum = 1.0;
> >       a.temporaryLuaOnlyStr = "hello";
> >       a.LuaEventCallback = function(x, y) ... end
>
> Unfortunately, that's not going to work, since LuaBridge's userdata
> metatables provide both __index and __newindex.

Oh. Oh.
Any plans to change that?

For example, in the Game Programming Gems 6 book they present two ways to associate a 
table with a userdata item, so that the Lua code can attach custom attributes:
either code the userdata's __index and __newindex metamethods so that they use an 
attached table, or represent the Lua object not as a userdata, but as a table (that has 
the userdata item in a "private" field).

In my current code, I use this feature quite extensively e.g. for a window hierarchies 
in a window system whose event handlers are defined in Lua.

> Yes, it will. LuaBridge userdata comes in three "flavors":
> [...]

Thanks for the valuable extra info!

> > Wouldn't the problem be solved if the userdata kept a *smart* pointer instance instead?
>
> LuaBridge stores the smart pointer object inside the userdata, for the
> Shared lifetime model. However, this does not solve the problem. The
> reason that std::shared_ptr<> doesn't work is because of aliasing. Two
> different instances of shared_ptr can point to the same object, and
> their reference counts will not be shared. This is explained in the
> documentation.

Yes, I got this:

    A* a = CreateA();
    std::shared_ptr<A> p1 = a;
    std::shared_ptr<A> p2 = a;    // trouble!

> When Lua passes a shared_ptr wrapped object using
> LuaBridge to a C++ function that takes only a pointer to the object,

Ah! So this is the real problem?

> it has no way of knowing that the object is really wrapped by a smart
> pointer.

Ok, I see...

Some speculation:
Would the problem ("cannot use shared_ptr") be gone if objects were only ever passed via 
shared_ptr, never via raw pointer or reference? That is, if the C++ functions that are 
called by LuaBridge were only allowed to have std::shared_ptr<A> parameters for object 
passing, but not any variant of A, A*, or A& ?
This way, the "chain" of shared_ptr's would never be broken.

More speculation:
If this worked, it might be possible to allow the user to use *any* smart pointer type 
that he/she wishes to use. Only requirement would be that it had to be consistently used 
everywhere. (Probably an inherently acceptable price with smart pointers.)


Best regards,
Carsten



--
   Cafu - the open-source Game and Graphics Engine
for multiplayer, cross-platform, real-time 3D Action
          Learn more at http://www.cafu.de