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

[Daniel Wallin]

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

Yeah, a typedef would have been a much better solution. I
think the reason we use macro's is because we used const
type_info* directly, instead of wrapping it in a class. So
we couldn't simply use < and == when comparing the types.

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

Right.

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

We actually have one user that uses this feature, I don't
know if he actually needs to though. So yeah, it could
probably be dropped.

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

Yeah, fragmentation issues can always be solved with pool
allocation. 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.

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

Ok. I noticed that while browsing the code. The custom
deleter is a powerful tool. :)

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

Sure, that would be nice. You can also introduce additional
placeholder aliases for the cases where '_N' and 'result'
doesn't fit very well.

--
Daniel Wallin