[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Userdata Lifetime Management
- From: Carsten Fuchs <carsten.fuchs@...>
- Date: Thu, 05 Jul 2012 01:22:02 +0200
Am 2012-07-05 00:32, schrieb Vinnie Falco:
From: Carsten Fuchs <email@example.com>
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.
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...
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.
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.)
Cafu - the open-source Game and Graphics Engine
for multiplayer, cross-platform, real-time 3D Action
Learn more at http://www.cafu.de