Re: registering "class converters"

Daniel Wallin <[email protected]> writes:

> David Abrahams wrote:
>> [Daniel Wallin and I are working on the framework]
> [snip]
>> Advantages:
>>   1. Easier to work with.  No need to mark classes as noncopyable.
>>   2. Potentially generates less code in a given extension module,
>>      since conversions that aren't needed aren't generated.
>> Disadvantages:
>>   1. Potentially generates more code across a group of interacting
>>      extension modules, since all modules returning Foo will have to
>>      generate the holder
>>   2. Slightly less flexible; you can't register a converter that
>>      says, "auto_ptr<Foo> will be converted this other way instead."
>>      Or if you do, it will be ignored.
>> I am in favor of this approach despite the disadvantages.
>> Incidentally, I think BPL is inconsistent about choosing, which is
>> why noncopyable is needed when classes are wrapped.
>> Thoughts?
>
> Yes, this is very cool. But I think maybe the front end should look in
> the registry anyway, 

Yeah, I was thinking the same.

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

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

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

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

> Looking up the converter using the pointee type instead means we can
> return any smart pointer to a registered class, without ever needing to
> register the pointer explicitly. However, now we can't register a
> converter for "std::auto_ptr<Foo>".
>
> Hope I'm making sense, can hardly keep my eyes open. ;)

I think I understand, but am not sure I agree.

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