lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

Hi Vinnie,

Am 2012-07-05 00:32, schrieb Vinnie Falco:
From: Carsten Fuchs <>
      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

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

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,

   Cafu - the open-source Game and Graphics Engine
for multiplayer, cross-platform, real-time 3D Action
          Learn more at