Boost logo

Boost :

Subject: Re: [boost] is_convertible problems associated with move-only types
From: Howard Hinnant (hinnant_at_[hidden])
Date: 2009-01-07 11:20:06

On Jan 7, 2009, at 5:09 AM, John Maddock wrote:

> Howard,
> I believe there are a number of issues with the approach you're using:
> The trivial case is that if From is not default constructible then
> you're code won't compile.

I just reapplied my modifications to boost::is_convertible and
successfully compiled this:

#include <boost/type_traits.hpp>

class non_default_constructible
     int data_;

     non_default_constructible() : data_(0) {}

     non_default_constructible(const non_default_constructible&) {}
     non_default_constructible& operator=(const
         {return *this;}


int main()
     bool b = boost::is_convertible<non_default_constructible,

> More seriously there are some types which is_convertible currently
> works with that *can never be rvalues*, examples include function
> types and abstract classes: the latter in particular was the subject
> of several bug reports until we "fixed" it with the current
> implementation. Basically I think we're kind of painted into a
> corner here implementation wise :-(

I knew about functions but had neglected abstract classes. functions
(and arrays and void) can be handled by special cases detected with
is_function, is_array, is_void.

E.g. when From is an array type the only thing it is convertible to is
a compatible decayed pointer type. When From is a function type the
only thing that it is convertible to is a decayed pointer to itself
(not reference).

is_abstract can also be used to special case abstract classes, but
what to do with it is indeed problematic. I suspect that for a C++03
emulation the only thing one could do is consider the source an lvalue
(for is_abstract<From>::value true remap it to answer for
is_convertible<From&, To>). When rvalue reference is available, one
can do better than this with:

@@ -131,12 +133,12 @@
template <typename From, typename To>
struct is_convertible_basic_impl
- static From _m_from;
- static bool const value =
sizeof( detail::checker<To>::_m_check(_m_from, 0) )
+ static From&& _m_from();
+ static From _m_from();
+ static bool const value =
sizeof( detail::checker<To>::_m_check(_m_from(), 0) )
         == sizeof(::boost::type_traits::yes_type);

I.e. in C++0X one can create rvalue expressions having abstract type.

But I agree with you: For a C++03 emulation of std::is_convertible, I
don't see a way to consider From an rvalue for abstract types (but I
do see ways for the emulation to handle rvalue From function and array

> Also the example you give is is_convertible<Movable, Movable>, is
> this the real use case? I ask because any is_convertible<T, T>
> expression is basically useless in C++03: it wil either compile and
> return true, or not compile at all, so you may just as well replace
> the expression with "true" and let the code fail later if the type
> is not copyable/movable :-(

It is a degenerate case caused by the overloading of the unique_ptr
move constructor and converting constructor:

    unique_ptr(uniquePtr&& u);
    template <class U, class E> unique_ptr(unique_ptr<U, E>&& u);

In the C++03 emulation of the second signature, one needs to enable_if
on is_convertible<E, D>. This signature gets instantiated whenever
there is a move construction, whether source and target have identical
deleters or not (indeed the spec could probably just drop the first
signature and let the second handle that case).

Even if you were to special case the is_convertible<D,D> case, you
only push the problem out a little. You still need to handle
is_convertible<E, D> where E and D are different move-only types and
an rvalue (but not lvalue) E is convertible to D.

> So yes, I would *love* to fix this, I just don't see how at
> present... John.

If the boost::is_convertible is not fixable I can just emulate
std::is_convertible directly in the unique_ptr emulation code. I've
already resorted to that solution for boost::compressed_pair:

I called it detail::unique_ptr_storage (probably not the best name,
but not part of the interface anyway). I needed a "compressed_pair"
that would handle move-only types. unique_ptr_storage does the move-
only dance, and just enough of the compressed_pair dance to satisfy
unique_ptr's needs.

For unique_ptr, is_convertible will never have to deal with abstract
types (or void, array or function types for that matter), so the
emulation could be specialized/simplified just for the unique_ptr use

Thanks for looking into this.


Boost list run by bdawes at, gregod at, cpdaniel at, john at