[C++-sig] constructor wrappers?

[Ralf W. Grosse-Kunstleve]

--- David Abrahams <david.abrahams at rcn.com> wrote:
> From: "Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com>
> 
> > This is going in the wrong direction. Now let me be on the other side of
> the
> > fence (striving for ideal solutions): The combination of std::vector and
> > Boost.Python is a major PITB. It was so painful that I wrote a fully
> fledged
> > reference counted array type. This clearly is the right solution.
> 
> Why is that clearly the right solution? Why should other users have to go
> to all that effort? Personally, I don't think that it should be neccessary.

What I mean is that people should be using a reference counted array type, not
write one. In other words, I believe that a reference counted array type is a
critical missing part in the standard library. But this is for a different
thread.
 
> To move this in a "constructive" (pun intended) direction, here's one
> possibility. Suppose def_init() would accept any function returning a
> boost::tuple of constructor arguments. The possible python argument
> conversions would be determined by the function's signature, and the
> elements of the resulting tuple would be used to construct the class.

This sounds interesting. (Classical approach: introduce an extra level of
indirection.)

> That
> way, if you have a lightweight class like any you can freely return
> tuple<any> from your function.

You lost me here. "My function" is the wrapper? Why would I want to return a
tuple<any>? -- Oh, just so I have a tuple<>? Eventually the copy constructor is
used?

Is boost::tuple available on all your target platforms?
Same question for boost::lambda.

> We could extend this so that if the function didn't return a tuple, the
> return value would be used as a constructor argument directly, which would
> get you exactly the interface you're asking for. I'm not sure if that's
> worth it, but it might be.

I don't think this shortcut is necessary.

> Another question raised by this idea is whether (and how) it should be
> applied to regular function wrapping. Carrying it a bit further could give
> us a way to make thin wrappers unneccessary by using Boost.Lamda.

I'd prefer a step-by-step approach.

I am wondering about the new member functions for class_. Do we need

  template <typename A1>
  def_init(boost::tuple<A1>);
  template <typename A1, typename A2>
  def_init(boost::tuple<A1, A2>);
  template <typename A1, typename A2, typename A3>
  def_init(boost::tuple<A1, A2, A3>);

etc. Is this a job for the preprocessor library?

Then what next? Do we have to build a bridge from boost::tuple<A1,...>
to boost::python::args<A1,...>, or copy-and-paste the processing
of args<> and then customize the code for dealing with boost::tuple<>?

Ralf


__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com