Re: registering "class converters"

Daniel Wallin <[email protected]>
Newsgroups gmane.comp.lib.boost.langbinding
Message-ID <[email protected]>
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, 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.

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_);
       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. 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.

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

-- 
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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.