Re: passing pointers using LuaBridge

[Jeremy Ong <jeremycong@...>]

With respect to the plethora of libraries in the wiki, unfortunately,
this stems more from the general lack of discoverability with C/C++
projects as a whole. The Lua ecosystem can be more or less
self-contained but C/C++ has a lack of modules and lack of central
authority to contend with (although modules are an imminent C++17
hopeful). I'll admit it took me a while to sort through the bindings
on the page until I knew nothing was what I wanted exactly and wrote
my own.

The trouble you have to deal with (or a good thing, idk), is that
because Lua is by nature an embedded language, the community itself
will be fractured into many divisions based on the
language/vm/environment they intend on embedding Lua *in*.
Centralizing the effort for each individual faction is a little
premature considering there may be only a handful of pioneers in each
one.

That said, I do think we should try and pool together efforts where it
makes sense. I'd be interested in talking to others who have written
C++ bindings for example. Perhaps it's possible that a more inclusive
and compatible library can be converged upon with some effort. Then
perhaps the wiki can make much clearer recommendations given the
user's circumstances (for example, if you need feature x and y, use
this, if you need z, use this, if you have C++03 only, use this, if
you have C++11/14 use this, etc).


On Mon, Apr 7, 2014 at 10:15 PM, Daurnimator <quae@daurnimator.com> wrote:
>
> On 7 April 2014 09:36, Moose <moose@posteo.de> wrote:
>>
>> All this messing around with lightuserdata. The name itself... I don't
>> know. Isn't that a standard use case for an embedded language to use things
>> outside? Wouldn't it be better to offer one function that exposes the
>> pointer inside the script and call it push_pointer() or some such
>> understandable way? The three lines that do the trick in my example above
>> say to me "I'm using that mechanism called lightuserdata although this is
>> meant for something else."
>
>
> Light-userdata IS for pushing pointers :)
> They are a special case of userdata, which is pushing memory.
>
> The difference being that identical pointers (lightuserdata) compare equal;
> while userdata (memory) holding the same data, does not.
> (at least not without a metamethod, and even then they won't hash the same).
>
>>
>> Also, please let me add a tad criticism. When I look at the wiki page for
>> language bindings ( http://lua-users.org/wiki/BindingCodeToLua ) I see no
>> less than 22 projects and mechanisms that bind C++ for use inside Lua.
>
> A usually good side effect of having no 'blessed' implementation.
> This should suggest to you that binding C++ is not an easy task, and there
> is no 'one size fits all' solution.
>
> Selene has shown a small amount of promise lately (it's a new project); but
> it makes use of new C++11 features, which your compiler is lacking.
>
>>
>> After filtering out the projects that are dead, unmaintained
>
> Sadly our wiki is not as maintained as it used to be :(
>
>>
>> or require an own library and therefore link dependency
>
> I'm not sure why that is a problem for you...
>
>>
>> Does the Lua community pursue any efforts in centralizing those projects
>
> Yes, every now and again we give it a try, but it's like herding cats :)
>
>>
>> and perhaps boil them down for direct inclusion into the distribution? Or
>> maybe recommend one?
>
> Lua itself has been very purposefully kept as minimal as possible: you may
> see fighting over in another thread right now about if including hyperbolic
> math functions in the standard library is too much..
>
> On the other hand, there has been much work done on distribution of lua
> libraries:
> luarocks has been good lately, while on windows luadist is slowing filling
> that void.
>