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

[Daniel Wallin]

> "Daniel Wallin" <dalwan01 at student.umu.se> writes:
> >> Users could just specialize or overload
> >> boost::luapython::type_id, which, in the no-RTTI case,
> >> has no no default definition.
> >
> > Note that we need to store the type_info object, and
> > that's why we have macros for this. So that the user can
> > change the type of that object. This wouldn't really
> work
> > with specialization.
>
>     template <class T> struct type_info
>     #ifndef NO_RTTI
>     {
>        typedef std::type_info type;
>        static type get();
>     }
>     #endif
>     ;
>
>     template <int n>
>     struct int_type_info
>     {
>         typedef int type;
>         static int get() { return n; }
>     };
>
>     template <>
>     struct type_info<Foo>
>       : int_type_info<42>
>     {};
>
> Of course I have no objection to using macros to generate
> specializations.

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?

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

> >> > 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?
:)

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

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

>
> >> > Wouldn't both the examples you provided require A to
> be held
> >> > by auto_ptr<A> in python?
> >>
> >> Only the A created by call_function for this callback.
> >> You can have As held any number of ways in the same
> >> program.
> >
> > Ah, right. You just instantiate different
> instance_holder's.
> > Does this mean there's special handling of auto_ptr's?
>
> What do you mean by "special handling"?  I think the
> answer
> is no, though I also think there should be special
> handling
> for convenience and efficiency.

I meant like an overload to extract the type held by the
auto_ptr. But you already answered that.

>
> > Otherwise, how can you tell which type is being held by
> > the pointer? (In the call_function example).
>
> 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.

>
> >> >> I can begin to see the syntactic convenience of your
> way,
> >> >> but I worry about the parameterizability.  In the
> first
> >> >> case "result" is the only possible appropriate arg
> and in
> >> >> the 2nd case it's "_1".
> >> >
> >> > What exactly do you worry about? That someone would
> use
> >> > the wrong placeholder? I think the intended use is
> quite
> >> > clear.
> >>
> >> I guess I'm just a worrywart.  Do the other policies
> have
> >> similar broad applicability?  If so, I'm inclined to
> >> accept
> >> that you have the right idea.
> >
> > Most conversion policies have double direction
>
> Cool, I accept your scheme.

Great.

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

>
> >> > void f(B*, B*, B*, python::list)
> >> > void f(D*, D*, D*, std::vector<int>)
> >> >
> >> > f(D(), D(), D(), [1, 2, 3])
> >>
> >> Yeah, I guess that looks right, but I don't know.  At
> some
> >> point things are just ambiguous.
> >
> > Exactly. Perhaps introducing weights on conversions
> might
> > increase the ambiguity for the user, since it's hard to
> tell
> > at which point the overload system will turn around and
> > choose another overload. Does this make any sense?
>
> Yes.  But as I meant to say to Andrei, none of the
> "classic"
> multimethod systems account for coercion, so if there's
> some
> reason they can't use your simple rule it has to be
> something you can understand in terms of simple
> inheritance
> hierarchies.

Right. I'll try to read up on this a bit more, I missed
those Andrei mails you cc:ed yesterday, gonna read them
today.

--
Daniel Wallin