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

[David Abrahams]

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

>> "Daniel Wallin" <dalwan01 at student.umu.se> writes:
>
> The type of the type-identifier needs to be known to the
> library though, so my point is that it can't be a template
> which the user just specializes. You also need to set the
> type for the compiled part of the library. Or am I missing
> something here?

Probably not; I think you have a good point, at least, if we
need runtime polymorphism among type id objects or if they
need to be manipulated in the compiled part of the library.

typedefs still work, though.

>> >> >> > This of course causes some problems if we want to
>> >> >> > downcast
>> >> >>
>> >> >> And if you want to support CBD (component based
>> >> >> development, i.e. cross-module conversions), unless
>> >> >> you can somehow get all authors to agree on how to
>> >> >> identify types.  Well, I guess they could use
>> >> >> strings and manually supply what
>> >> >> std::type_info::name() does.
>> >> >
>> >> > It doesn't seem wrong that the authors need to use the
>> >> > same typeid. If you aren't developing a closed system,
>> >> > don't change typeid system.
>> >>
>> >> I was thinking more of id collisions among extensions
>> >> which don't intend to share types.  It becomes less of an
>> >> issue if people use string ids.
>> >
>> > But like I said, if you intend to use your module with other
>> > modules; don't change the typeid system.
>>
>> I'm not talking about changing systems, just the need to
>> ensure unique type IDs for different types across modules.
>
> Yeah I know, what I'm saying is that you will only get
> problems like that if you change your type_info
> represantation to something like 'int'. In which case you
> have changed type id system. This isn't a problem as long
> as you stick to typeid() and type_info?

Assuming a single compiler and the use of distinct
namespaces, no.

>> >> > LUABIND_DONT_COPY_STRINGS
>> >>
>> >> What kind of string copying gets disabled?
>> >
>> > It causes names to be held by const char* instead of
>> > std::string. (class names, function names etc).
>>
>> Why not always do that?
>
> Hold const char*? Because you can't control their
> lifetime?  :)

You mean that some people want to compute these things
dynamically instead of using string literals?  Nobody has
ever asked me for that.  I bet this is one area of
configurability that could be dropped.

>> >> > . and the typeid macros.
>> >> >
>> >> > Most are results of user requests. Massive configuration
>> >> > is quite important to our users, since lua is used alot on
>> >> > embedded systems.
>> >>
>> >> Have your users come back after getting these features and
>> >> given you any feedback about how much performance they've
>> >> gained or space they've saved?
>> >
>> > No. But some of them is a must-have for alot of
>> > developers.  In particular the ability to turn off
>> > exception handling.
>>
>> Oh sure, I believe that one, especially because some
>> shops (advisedly or no) have a policy against EH and
>> RTTI.  You don't want to just leave them out.  I am just
>> leery of configurability in general and would tend to
>> resist making any new macros part of the official release
>> until users had told me it made a big difference to them
>> in alpha/beta stages.  In particular, "massive"
>> configurability is not neccessarily desirable.  It
>> creates "massive" maintenance and testing headaches.
>
> I agree. I can ask around on our mailing list later about
> what kind of configuration people think is interesting,
> and how much of what we have now they are using.

Cool.

>> >> >> [I assume this means that all of your C++ objects are held
>> >> >> within their lua wrappers by pointer.  I went to
>> >> >> considerable lengths to allow them to be held by-value,
>> >> >> though I'm not sure the efficiency gain is worth the cost
>> >> >> in flexibility.]
>> >> >
>> >> > Correct. We hold all C++ objects by pointer. I can see why
>> >> > it could be interesting to be able to hold objects by value
>> >> > though, especially with small objects. I'm not sure it would
>> >> > be worth it though, since the user can just provide a custom
>> >> > pool allocator if allocation is an issue.
>> >>
>> >> Still costs an extra 4 bytes (gasp!) for the pointer.
>> >> Yeah, it was in one of my contract specs, so I had to
>> >> implement it.  Besides, it seemed like fun, but I bet
>> >> nobody notices and I'd be very happy to rip it out and
>> >> follow your lead on this.
>> >
>> > Need to think about this some more. It's no special
>> > case in BPL though, it's just another type of
>> > instance_holder, correct?
>>
>> Not only that.  It's an issue of where the instance holder
>> gets constructed.  In this case it is constructed directly
>> in the storage for the Python object.
>
> Right, that's pretty cool.

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.

>> The to-python converter that gets registered for
>> auto_ptr<T> by using it in a class<T, std::auto_ptr<T>,
>> ... > or by using
>> register_pointer_to_python<std::auto_ptr<T> > knows what
>> to do.
>
> Ah, right. It's pretty nice to be able to hold the instances
> in different kind of holders.

Yeah.  

Note also that shared_ptr is "magic", in that any wrapped T
can be converted to shared_ptr<T> regardless of holder, and
the resulting shared_ptr<T> can be converted back to the
original Python object (not just a new one sharing the same
C++ object).

>> > and even the
>> > ones that doesn't can still be used in different contexts.
>> > ('result' when doing C++ -> lua, and '_N' when doing lua ->
>> > C++).
>>
>> How is that *not* a case of bidirectionality?
>
> :) It is, my fault. I meant it could be used in different
> contexts with the same direction, it should read something
> like: 'result' when calling a C++ function, '_N' when
> calling a lua function.
>
>> 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.

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