[C++-sig] Implicit constructors?

[David Abrahams]

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


> --- David Abrahams <dave at boost-consulting.com> wrote:
> > I think if you def() the copy constructor it should work automatically
> > (though it could be more efficient). Does that help?
>
> def()'ing the copy constructor works. However, registering the
> python_sequence_to_container converter for a type that is also exposed
with
> class_<> leads to confusing behavior. I have not spent enough time to
come to a
> conlusion. To explain what I've found out so far:
>
> "shared" is a reference-counted array type.
>
> a = shared.double((1,2,3)) # works using the copy-constructor trick
> a.as_tuple() # confusing behavior
>
>     PyObject* // BPL_FUTURE return tuple
>     as_tuple(const shared<ElementType>& v)
>     {
>       return bpl_utils::container_to_tuple<shared<ElementType>
>::convert(v);
>     }
>
> Apparently overload resolution calls the sequence_to_container converter
when
> matching "a" (Python) to the as_tuple() (C++) argument. My current
> implementation of the seq-container converter is so general that it
decides "a"
> can be converted to an iterator and then goes ahead and constructs a new
> shared<ElementType> . Could this interpretation be right so far?

Yep. This is part of the reason we need a more-sophisticated overload
resolution mechanism.
However, remember that a const& argument matches rvalue converters. If you
only want to match converters which succeed when an actual shared<Element>
is contained within the Python object (lvalue converters), have your
function take a shared<Element> const* or a shared<Element>& parameter.

HTH,
Dave


-----------------------------------------------------------
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com