[C++-sig] Protected destructor compile error

David Abrahams dave at boost-consulting.com
Fri Jun 23 05:36:33 CEST 2006


"Allen Bierbaum" <abierbaum at gmail.com> writes:

> 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
> nimplement something like this?

I think the answer to both questions is no.  It sounds like a
reasonable thing to do, though.

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

It's not possible to detect that, unfortunately.  And _making_ the
temporary is a completely separate issue from destroying it.  The part
of the converter that makes the temporary is looked up dynamically
based on the source Python type and in this case of course, nothing is
ever found.  The fact that the destruction code is instantiated
unconditionally by the static part of the is really a sort of
optimization.

The simplest way to make this work for everyone would be to make the
dynamic part of the converter responsible for destroying the
temporary.  That would make your case work without the need for any
traits.  However, there's a tradeoff; there would be an extra function
pointer indirection, at least.  In the case of converting to a C++
type with a trivial destructor, that no-op call through a function
pointer would replace an "inline no-op" (i.e., nothing at all).  Other
minor costs include storage for that function pointer.

Also there's the issue that this would cause a hard incompatibility
with extension modules built against an earlier Boost.Python (their
dynamic converters don't supply that destruction code).

Did I mention I'm not making any heavy decisions while I'm on
vacation?  Why don't y'all discuss the tradeoffs here and decide
whether it's worth it.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com




More information about the Cplusplus-sig mailing list