[C++-sig] Protected destructor compile error

Allen Bierbaum abierbaum at gmail.com
Thu Jun 22 15:28:41 CEST 2006

On 6/22/06, David Abrahams <dave at boost-consulting.com> wrote:
> "Allen Bierbaum" <abierbaum at gmail.com> writes:
> > It looks like there is a problem with the "const Viewport& port"
> > argument being passed.  For some reason the generated code seems to
> > want to be able to destroy instances of the Viewport class.  This
> > class has protected constructor and destructor as it is reference
> > counted and the user can only create them using a helper function
> > (Camera::create()).
> >
> > Can anyone describe what is happening here
> Boost.Python assumes that a const reference argument means that the
> function can accept "rvalues", e.g. objects implicitly converted from
> other python types.  The generated converter thus has storage for a
> temporary Viewport object which potentially needs to be destroyed
> after the wrapped function is called.

Ok.  This makes sense although I still don't fully understand what is
happening behind the scenes but from this description I should be able
to look at the code to find out.

> > and what prerequisites
> > exist for this call to work?  Is there some call policy that I should
> > be using to make this work?
> Nope, but a thin wrapper that exposes Viewport& instead of Viewport
> const& will help you.

This makes sense as well.  Unfortunately there could be hundreds of
places in the code where I would need to do this so it will be
difficult but I will do it.

One additional question:  Is there any metafunction (something like
pointee<>) that could be specialized to tell boost.python that when it
sees a const& of this type it should not assume that it can make a
temporary?  In effect some way to tell it to choose to use the path
that the thin wrapper would use instead.

If there isn't a metafunction like this, would it be difficult to
implement something like this?  (if not, I am willing to work on it if
you give me some direction on where to look and what to look for)  To
help with cases like mine, it would be nice to make the default
version use type traits to detect if the type has a public destructor
(and anything else it needs to make the temporary).

Thanks again for the quick response.


> --
> Dave Abrahams
> Boost Consulting
> www.boost-consulting.com
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig

More information about the Cplusplus-sig mailing list