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

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