registering "class converters"

[Daniel Wallin and I are working on the framework]

I've been thinking about how classes get converted to xxx.  There are
two approaches:

  1. The converter(s) get generated when the class itself is wrapped
  2. They get generated on demand by the front-end.

Consider code that passes an auto_ptr<T> or a shared_ptr<T> to xxx,
say:

     std::auto_ptr<Foo> create();

Rather than looking up a result converter in the registry, the
front-end code that wraps this function could simply create the
holder and call some function in the registry that installs it in a
new xxx instance.

Similarly,

     Foo create();

could generate the holder on-demand.

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?

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