[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 the goal, but I'm not sure what you've got there is
> > the best solution, for two reasons:
> > 
> > 1. It incurs the cost of copying "any"
> > 2. It requires the ability to copy "any", and not all class types
> > are copyable.
> 
> In the vast majority of cases (and there were many) where I was
> craving for a light-weight method of defining additional
> Python-specific constructors both 1.  and 2. are not a
> problem. (Almost all my types are tiny. For large arrays I use a
> reference counted look-alike of std::vector.)

I understand that your solution works for your problems.

> > Currently, the way to do this is with a class derived from any:
> > 
> >     boost::python::class_<any,any_wrapper>("any")
> >         .def_init(args<PyObject*>()) // could use args<tuple> soon
> > 
> > 
> > Where
> > 
> >     any_wrapper::any_wrapper(PyObject* ignored, PyObject* seq)
> > 
> > is defined.
> 
> This seems to resemble what I did in V1. I would call this the
> heavy-weight alternative. In practice I have often shied away from
> this in favor of simpler but more klunky approaches. IMO the average
> user would be much better served with the light-weight alternative
> because it requires less code and, almost more importantly, is
> easier to understand.

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.

> > However, I'm open to other interface suggestions. I suggest you
> > take a look at the documentation for make_constructor and the
> > Holder concept to get started.
> 
> I will have a look.
> 
> > Also, part of the formula may involve some extensions to the
> > CallPolicies concept. For example, we might want to make it
> > possible to specify the from_python converter that gets used for
> > each argument.
> 
> For a start I would be happy with the famous "70% solution." Add
> more sophistication depending on user demand.

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

-Dave