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

[Daniel Wallin]

At 00:34 2003-06-29, you wrote:
>"Daniel Wallin" <dalwan01 at student.umu.se> writes:
>
> >> Yeah, but I doubt it's saving much, and it leads to much
> >> complication (c.f. instance_new and instance_dealloc in
> >> libs/python/src/object/class.cpp).  If objects are
> >> getting created and destroyed a *lot* it could reduce
> >> fragmentation and increase locality... but as I said I
> >> have big doubts.
> >
> > Yeah, fragmentation issues can always be solved with pool
> > allocation.
>
>But locality can't, for what that's worth.  Frankly I think
>it's not worth much.

Me neither.

> > Is the complexity only due to value-holders, or just
> > different kind of holders? Seems to me (without having
> > looked at instance_new/instance_dealloc yet..) like you
> > would need the same allocation routines for
> > pointer-holders as well.
>
>I'm trying to tell you it has nothing to do with the how the
>holders contain their data [though see below]; it's about
>how/where the holders themselves are constructed.
>
>The object model is something like this: every wrapped class
>instance contains an endogenous linked list of holders (to
>handle multiple inheritance from wrapped classes) and some
>raw storage to use for holder allocation.  A class wrapper
>knows the size and alignment of its default holder, so
>usually the holder will be allocated right in the raw
>storage.  If the holder turns out to be too big for that
>storage, e.g. the default holder contains an auto_ptr<T> but
>for some reason a value_holder<T> is used, or a
>value_holder<U> is used where U is derived from T, then the
>holder will be dynamically allocated instead.  Additional
>holders in MI situations can also end up being dynamically
>allocated.  Arranging for the extra storage in the Python
>object means we have to fool Python into thinking the
>objects are variable-length (like a tuple), and incurs a few
>other complications.

Ok, I have very little knowledge in how Python memory management
works. In luabind we always allocate dynamically. We also don't
support multiple inheritance from wrapped classes.

>Well, OK, actually I suppose the argument forwarding problem
>(http://tinyurl.com/fist) causes a lot of additional
>complexity because references need to be passed through
>reference_wrapper<T> arguments, and that would go away if
>there were no value_holders.  I barely even notice that
>anymore, since it was part of BPLv1... but now that you
>mention it, value_holder is probably causing more
>complication in the code than in-place holder allocation.
>Eliminating both might be a huge simplification.
>Additionally, it might become possible to convert nearly any
>object to nearly any kind of smart pointer.  value_holders
>impose some real limitations on usability.

The actual allocation of the holders could be in a language dependent
layer though, in which case it would be an implementation detail if it's
in-place or heap allocated. We don't have any issues with allocating
the holder memory together with the instance object in lua.

> >> >> That rule makes me nervous, because the terms are
> >> >> backwards when calling lua/python from C++.  Do people
> >> >> get confused?
> >> >
> >> > I don't think they do, I don't think anyone has reported any
> >> > problems with it yet. It's backwards for a reason though,
> >> > and it's pretty clear when to use which placeholder. (except
> >> > in some special cases, where documentation helps).
> >>
> >> OK.  Maybe we could allow a default argument which would
> >> "just work" for these cases.  Another option is "_", which
> >> is used in MPL for something similar.
> >
> > Sure, that would be nice. You can also introduce additional
> > placeholder aliases for the cases where '_N' and 'result'
> > doesn't fit very well.
>
>My point is that I'm trying to get away from a scenario
>where users have to think about which choice is right, when
>the context dictates that there can only be one right
>choice.  Adding different names for the choices doesn't
>help with that problem.  This is a minor nit.

Yeah, for those cases (object_cast, object::assign for instance)
we could use default argument or a 'magic' placeholder.

>It sounds like we're converging quite rapidly.  What other
>issues do we need to deal with?

I don't know. I'm sure more issues will pop up later on though. :)
How do we proceed from here?


Daniel Wallin, dalwan01 at student.umu.se