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

[dalwan01]

> Rene Rivera <grafik666 at redshift-software.com> writes:
>
> > [2003-06-18] David Abrahams wrote:
> >
> >>>>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.
> >>
> >>Python can handle multiple interpreter instances too,
> but hardly
> >>anyone does that.  In any case, it still seems to me to
> be a handle
> >>to global state.
> >
> > Perhaps because Python has a higher interpreter cost?
>
> I'm not really sure why.  What's an "interpreter cost?"
>
> > The thing is it's the recomended way to do things in
> Lua.
> >
> >>> So having a single global var for that is not an
> option.
> >>
> >>Why not?  I don't get it.  Normally any module's
> initialization code
> >>will be operating on a single interpreter, right?
> >
> > No. The LuaState is the complete interpreter state. So
> to do bindings, or
> > anything else, you create the state for each context you
> are calling
> > in.
>
> "Context", possibly meaning "module?"
>
> If so, I still don't see a problem with using
> namespace-scope
> variables in an anonymous namespace (for example).

If the choice is between:

namespace_(..)
[
  def(..),
  def(..)
];

and

{
  namespace_ local_ns(..);

  def(state, ..);
  def(state, ..);
}

I would prefer the first as it is both more readable and
less verbose.

> >>I am not trying to be difficult here.  If there are
> significant
> >>technical advantages to purely-static converter lookups,
> I will be the
> >>first to support the idea.  In all, however, I believe
> it's not an
> >>accident that Boost.Python evolved from purely-static to
> a model which
> >>supports dynamic conversions, not just because of
> usability concerns,
> >>but also because of correctness and real efficiency.
> So, let's keep
> >>the conversation open, and try to hammer on it until we
> reach
> >>consensus.
> >
> > Being difficult is the point ;-) If there's no
> difficulty there's no
> > discussion.
> >
> > OK, I'm bassically convinced with that argument. If the
> majority of the
> > lookups are O(1) then the extra cycles at runtime is
> worth the
> > convenience.
>
> They are.  Furthermore, to-python conversions for specific
> known
> types can be fixed at compile-time.

How can they be fixed at compile-time? Doesn't this mean
bypassing the conversion system and not allowing multiple
converters / type?

>
> > I just worry about O(n) lookups at a junction point in a
> program. It tends
> > to poroduce O(n2) algos ;-)
>
> When n != 1 it's usually 0 or 2.  As long as you're not
> nervous about
> everything that calls through a function pointer I think
> we're OK.
> Let's see what the luabind guys think.

Some people would indeed get nervous by that. :) It isn't so
much about the complexity as the additional cache misses and
branch mispreditions introduced by lists of converters and
calls through functions pointers.

I realise this sounds silly, but when developing on a
console these are important issues.

I don't really have any numbers on this, and we would really
need those.

--
Daniel Wallin