[C++-sig] Re: Interest in luabind

Rene Rivera grafik.list at redshift-software.com
Wed Jun 18 17:03:53 CEST 2003


[2003-06-18] David Abrahams wrote:

>
>Moving this to the C++-sig as it's a more appropriate forum...
>
>"dalwan01" <dalwan01 at student.umu.se> writes:
>
>>> Daniel Wallin <dalwan01 at student.umu.se> writes:
>>>
>>> > namespace_("foo")
>>> > [
>>> >    def(..),
>>> >    def(..)
>>> > ];
>>>
>>> I considered this syntax but I am not convinced it is an advantage.
>>> It seems to have quite a few downsides and no upsides.  Am I
>>> missing something?
>>
>> For us it has several upsides:
>>
>>   * We can easily nest namespaces
>
>IMO, it optimizes for the wrong case, since namespaces are typically flat
>rather than deeply nested (see the Zen of Python), nor are they
>represented explicitly in Python code, but inferred from file
>boundaries.

I must be atipical. I make heavy, nested, use of namespaces in my C++ code.
So having an easy way to represent that would be nice. 

>>   * We like the syntax :)
>
>It is nice for C++ programmers, but Python programmers at least are
>very much more comfortable without the brackets.
>
>>   * We can remove the lua_State* parameter from
>>     all calls to def()/class_()
>
>I'm not sure what that is.  We handle global state in Boost.Python by
>simply keeping track of the current module ("state") in a global
>variable.  Works a treat.

It's not global state. Unlike Python Lua can handle multiple "instances" of
an interpreter by keeping all the interpreter state in one object. So having
a single global var for that is not an option. It needs to get passed around
explicitly or implicitly. I imagine Lua is not the only interpreter that
does this. So it's something to consider carefully as we'll run into it
again (I fact if I remember correctly Java JNI does the same thing).

>> For us it doesn't seem like an option to dispatch the converters at
>> runtime, since performance is a really high priority for our users.
>
>What we're doing in Boost.Python turns out to be very efficient, well
>below the threshold that anyone would notice IIUC.  Eric Jones did a
>test comparing its speed to SWIG and to my great surprise,
>Boost.Python won.

It's a somewhat different audience that uses Lua. The kind of audience that
looks at the assembly generated to make sure it's efficient. People like
game developers, embeded developers, etc. so having a choice between compile
time and runtime they, and I, would choose compile time.

But perhaps the important thing about this is to consider how to support
both models.


-- grafik - Don't Assume Anything
-- rrivera (at) acm.org - grafik (at) redshift-software.com
-- 102708583 (at) icq




More information about the Cplusplus-sig mailing list