 |
lua-l archive |
|
|
||
|
|
On 7/4/2012 5:22 PM, Carsten Fuchs wrote: > 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? You might want to look into Dub. It handles exactly the case you're talking about. The way I'm using Dub, I take it a step farther, in that even after "a" is garbage collected on the Lua side, if it still exists on the C++ side, any Lua-only temporaries are kept around and rebound once "a" is passed back into Lua. I also guarantee that the shared pointer on the Lua side is reused if Lua still has a reference to it. I'll look into open-sourcing that code. The downside of Dub is that it requires a preprocessing step; I find that trivial to automate, however. The upside is that you don't get terrible template errors when something is subtly wrong, and the code is all really easy to understand because it's right there in front of you. And the other upside is that it's trivial to swap in specific Lua code or a C++ handler for any particular function -- including using your own modified templates to handle the C++/Lua boundary however you like. >> 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. If two instances of shared_ptr point to the same object without sharing a reference count, that's a BUG. It will result in a double-deletion of the object (unless you leak one of the shared_ptr objects, of course). However, the way I handle shared_ptr in MY code (I can't say how Gaspard handles it in the current HEAD version because I haven't looked for a while), all pointers that will be managed by shared_ptr are passed in as shared_ptr objects. In my opinion you should NEVER (OK, hardly ever) pass a raw pointer to an object that you plan to manage with shared_ptr, for exactly the reason outlined above. > 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? Exactly. If you're using shared_ptr, all functions should take shared_ptr-wrapped objects. Tim |