>  "Daniel Wallin" <dalwan01@[...].se> writes:
> 
>  >> "Daniel Wallin" <dalwan01@[...].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

_______________________________________________
C++-sig mailing list
C++-sig@[...].org
http://mail.python.org/mailman/listinfo/c++-sig