Re: registering "class converters"

David Abrahams wrote:
> Daniel Wallin <[email protected]> writes:
[snip]
> 
>>and the conversion function should get the
>>"installer" passed to it. 
>>IIUC, this would make disadvantage (2) go
>>away. However, it probably also means the converter function needs to be
>>passed the backend specific class object for the type.
> 
> 
> More precisely, it needs something like
> function<void(std::auto_ptr<instance_link>)>& that can insert the
> holder into a new instance of some backend-specific class.

I don't know. The code looks like this now:

     instance_holder(
         backend::class_instance const& instance
       , Pointer ptr
       , instance_link* siblings
     );

So the backend instance has to be created before the holder.. I just
don't see how it would work right now.

>>Thus, the converter used for classes registered with class_ could be
>>something like:
>>
>>   void* converter(
>>       void* src
>>     , backend::class_ const* class_
>>     , holder_installer const& installer)
>>   {
>>       std::pair<void*, void*> x = make_lua_instance(class_);
> 
>                                      ^^^^^^^^^^^^^^^^^
> This is the part I don't understand.  Why not pass that from the
> backend as part of the aforementioned function<...>?

What I said above and: optimization perhaps? IMO not allocating memory
if we don't have to is a Good Thing, if it doesn't complicate things.
Maybe I'm wrong and it does complicate things, but I don't see it yet.

>>       class_instance instance(class_, x.first);
>>       installer(src, x.second);
>>       return 0;
>>   }
>>
>>This is the scheme I have been prototyping tonight.
>>
>>Thinking about this, there seems to be a tradeoff here: If we want (2)
>>to go away, the converter lookup must occur using the typeid of the
>>actual return type. 
> 
> 
> I guess you're assuming the call is from XXX -> C++.  This came up for
> me going the other way.  

I did yes, but this should apply to that as well.

> But, whatever.  So you mean we have to look
> up the entry from std::auto_ptr<Foo> if that's what's being returned,
> right?

Right.

>>However, this means the user has to explicitly say that something is
>>going to be used as a smart ptr, to get the converter into the
>>registry.
> 
> 
> We could detect dereferenceable types automatically at the point of
> wrapping the function doing the return.  Why not?  Then optional<T>
> could be returned!

I don't think I like that. Dereferencable is too weak. Why not
get_pointer() instead? That's what I'm doing now:

   if has_get_pointer<T>
       use smart_pointer holder generator
       if there is a converter for T in registry
          use that
       else
          use converter for pointee<T>::type instead
   else
       use value holder generator
       use converter for T in registry

IIUC this takes care of optional too, since it has a get_pointer
overload. It's probably missing the pointee<> specialization though, and
it's kind of unfortunate that it's needed.. Maybe it could go away..?

However, my point was that if we have a function:

   std::auto_ptr<X> f();

And want to look for a converter in the registry, and use
type_id<std::auto_ptr<X> > to do the lookup, someone has to register
this type. My scheme above avoids this by looking up converters using
the pointee type as well.

-- 
Daniel Wallin



-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php