[C++-sig] constructor wrappers?

[David Abrahams]

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

OK. You said earlier that using std::vector with Boost.Python was a
major "PITB" (which I assume is bad), so I just want to re-emphasize
that I really hope that won't be the case with v2.

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

Your function is the "constructor argument preprocessor".

> Why would I want to
> return a tuple<any>? -- Oh, just so I have a tuple<>? 

Yes.

> Eventually the copy constructor is used?

The elements of the tuple would be distributed to the constructor of
the underlying class, so the constructor which accepts an any argument
would be used.

> Is boost::tuple available on all your target platforms?  

Yes.

> Same question for boost::lambda.

No (but so what?)

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

Good.

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

Cop out <0.01 wink>

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

No; think about it a bit and you'll see that it can't work that
way. tuple<> takes default arguments.

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

I don't think I'm ready to figure out the entire implementation in
this email ;-)