Re: registering "class converters"

Daniel Wallin <[email protected]> writes:

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

Good point.

Well we could change this so that "back reference" instance_holders
are initialized with their backed::class_instance in a separate
phase.  It's easy enough to do.

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

You lost me.  What memory allocation are you referring to?

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

> Why not get_pointer() instead? 

That's OK too, probably... but why?

> That's what I'm doing now:
>
>    if has_get_pointer<T>
>        use smart_pointer holder generator

I dont' understand what "use" means here.

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

Probably, just by dereferencing and executing the code inside a
function template where the pointee has been deduced.

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

I don't see the problem; can't you register it at the point that f is
wrapped?

> My scheme above avoids this by looking up converters using
> the pointee type as well.

I guess I don't see it yet.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com



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