[C++-sig] Re: Interest in luabind
dalwan01 at student.umu.se
Sat Jun 28 22:41:56 CEST 2003
> "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
> > which the user just specializes. You also need to set
> > type for the compiled part of the library. Or am I
> > something here?
> Probably not; I think you have a good point, at least, if
> need runtime polymorphism among type id objects or if they
> need to be manipulated in the compiled part of the
> 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
> >> >> >> > downcast
> >> >> >>
> >> >> >> And if you want to support CBD (component based
> >> >> >> development, i.e. cross-module conversions),
> >> >> >> you can somehow get all authors to agree on how
> >> >> >> 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
> >> >> > same typeid. If you aren't developing a closed
> >> >> > don't change typeid system.
> >> >>
> >> >> I was thinking more of id collisions among
> >> >> 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
> >> ensure unique type IDs for different types across
> > 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
> > have changed type id system. This isn't a problem as
> > 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.
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
> >> gets constructed. In this case it is constructed
> >> 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
> 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
> >> 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
> >> to do.
> > Ah, right. It's pretty nice to be able to hold the
> > in different kind of holders.
> Note also that shared_ptr is "magic", in that any wrapped
> can be converted to shared_ptr<T> regardless of holder,
> the resulting shared_ptr<T> can be converted back to the
> original Python object (not just a new one sharing the
> 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
> >> > ('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
> > contexts with the same direction, it should read
> > 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
> > problems with it yet. It's backwards for a reason
> > and it's pretty clear when to use which placeholder.
> > 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.
More information about the Cplusplus-sig