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

[David Abrahams]

Daniel Wallin <dalwan01 at student.umu.se> writes:

> 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.

I understand.  Sounds like you made a good trade-off.

> 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.

Doesn't sound like it would be worthwhile.

>> > 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.

Agreed.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com