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

[Daniel Wallin]

At 01:39 2003-07-04, you wrote:
>Daniel Wallin <dalwan01 at student.umu.se> writes:
>
> > At 00:34 2003-06-29, you wrote:
> >>"Daniel Wallin" <dalwan01 at student.umu.se> writes:
> >>
> > 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.
>
>Oh, but that's cheap.  At least in Boost.Python it is.  I assume it
>would be the same in luabind if you were using holders.

Yeah it would. The thing is that lua doesn't have classes, all
it has is the ability to 'hook' on certain events on objects, so
the class system is something luabind introduces. Multiple
inheritance would mean we would need to make some
decisions on how to handle method-dispatching, and how
to handle diamond shapes.

This is isolated behavior of the luabind class-system though, so it
has nothing to do with the shared code. Although, we might introduce
MI if there is sufficient need for it.

> >>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.
>
>But without value_holders it seems silly, and value_holders
>themselves seem to lead to a great deal of complication, soo...
>
>Looking at the big picture I'm rather inclined to go with something
>much simpler.  I guess that using placement new in value holders
>might be a way to gain a whole lot of simplicity, though.
>
>OK, here's my conclusion (hope you agree): there's no need for
>value_holders or in-dynamic-object allocation of C++ data in any
>initial merged version of the library.  We can always optimize later
>if it doesn't incur too much code complexity.

I agree that value_holders isn't needed in the initial version, but having
functions that allocate the storage for holders in language dependent
code doesn't really add any complexity.


Daniel Wallin, dalwan01 at student.umu.se