lua-users home
lua-l archive

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

Thanks for the reply,


   SLB::Class<osg::Vec3>("osg::Vec3")
       .constructor<float,float,float>()
       .set("length", &osg::Vec3::length)
       .set("normalize", &osg::Vec3::normalize)
   ;



   SLB::Class<osg::Group, SLB::Instance::SmartPtr<osg::ref_ptr> >("osg::Group")
       .constructor()
       .inherits<osg::Node>()
       .set("addChild", &osg::Group::addChild)
   ;


Yikes! osg code! :)


I'm about to release "yet another library" to do simple bindings,
some like lunar, some others like luabind, similar to boost-python,
and so on. I know there are lots of libraries that target the same
problem, and probably, in similar ways... but If been working on this
for long time, I use it a lot, and maybe it could be useful for other
people. It is called "SLB" ( Simple Lua Binder ) and looks like this:



Yeah, LuaBind might actually do what I'm talking about, but I haven't
figured out enough about Luabind to actually know. But I was hoping to
find something kind of simple because I hoped to actually try to
understand some of it. Luabind is too complicated for me at this
point. Also, if something breaks (maybe due to another Lua major/minor
release), I would actually like to be able to fix it. You're pending
implementation might be what I'm hoping for. Though at this point, I
would be happy to just see a non-generalized example just to see how
things are setup. (It might make a good Wiki addition too.)


If the class is also wrapped using
SLB, the class  could be accessible inside lua (of course)


Right, the Lua implementation for the C++ class should be pretty much
hidden from the public interface, so I would imagine that any binding
libraries that go the other direction should be able to bind to this
class since it should appear like any other regular C++ class.


The main issue is to create a lua_State for each instance to protect
possible simultaneous access from several threads, if this is not a
problem it is safe to use only one lua_state for all instances.


So I don't think a separate Lua state per-instance is a problem and
seems to make sense to me. I was actually thinking along these lines
just so I could do quick and easy things like use the lua state's
global variables as substitutes for the C++ class's member variables.
Maybe C++ static variables/methods could get a little tricky with
per-instances? But this isn't normally something I worry about.


Anyway, I will probably need something like this to make some
"callbacks" in my code... so  it will be implemented somehow in SLB in
the very near future.



Cheers,
   Jose L.


So if you have any quick and simple prototypes/experiements (doesn't
need to be generalized), I would certainly like to see them. It will
probably help get me comfortable with SLB too once you do figure out
the generalized solution. Anyway, I eagerly await seeing what you come
up with. Please keep me posted.

Thanks,
Eric