[C++-sig] constructor wrappers?

[David Abrahams]

From: "Ralf W. Grosse-Kunstleve" <rwgk at yahoo.com>


> --- David Abrahams <david.abrahams at rcn.com> wrote:
> > I understand that your solution works for your problems.
>
> How about giving me some credit for being a heavy user of Boost.Python?
> Don't you think that many of my experiences are representative?

Yes I do.

> > I think of the derived class wrapper approach as a kludgy workaround,
> > not a solution. I'm in favor of a lighter-weight alternative, but I
> > also want it to be efficient and flexible. In library design you often
> > have to be careful to get the interface right the first time, because
> > you're stuck with the results essentially forevermore.
>
> Yes. But if you had taken that philosophy too far would there be
Boost.Python
> V1?

I was doing the best I knew how with efficiency and flexibility at the
time.

> (with the returned reference problem, the friend function hack, and the
> incomplete cross-module support.) It still is a great, ground-breaking
library.

Well, thanks, I think ;-)

> > Of course you would, but then you won't have to explain to other users
> > why lightweight constructor wrappers cause them to make a copy of the
> > std::vector<> they are wrapping ;-)
>
> 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.

> Under the assumption that the proposed 70% solution can be achieved in
20% of
> the time required for the 100% solution, I am happy to explain that the
> instances get copied.

Why assume? Have you invested anything in thinking about what an efficient
and flexible solution would look like? I haven't.

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. That
way, if you have a lightweight class like any you can freely return
tuple<any> from your function.

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.

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.

-Dave