Boost logo

Boost :

Subject: Re: [boost] is_convertible problems associated with move-only types
From: David Abrahams (dave_at_[hidden])
Date: 2009-01-06 12:37:03

on Tue Jan 06 2009, Howard Hinnant <> wrote:

> On Jan 6, 2009, at 10:45 AM, David Abrahams wrote:
>> on Mon Jan 05 2009, Howard Hinnant <> wrote:
>>> I'm continuing to refine a boost::unique_ptr emulation and testsuite.
>> Howard, can you put this in the sandbox? I know there are a number of
>> us who would like very much to collaborate on it.
> I will make it available as soon as I can at
> There will be plenty of room for collaboration. Indeed I feel like that is already
> happening with the discussion in this thread.

For optimal collaboration you need source control. That's why I suggest
the sandbox. That's probably the only way I'd be able to afford to work
on it.

>>> One thing I've just uncovered is that I'm hitting a brick wall with
>>> is_convertible and move-only deleters used within the unique_ptr move
>>> constructor. The problem is that boost::is_convertible<From, To>
>>> assumes From is an lvalue.
>> Sorry to be nitpicky, but that's not making sense to me. IIUC the terms
>> lvalue and rvalue can only apply to expressions, not types. Are you
>> saying that From has to be a reference type? Surely not.
> I'm saying that if you construct a To from a From, you /may/ get
> different answers (on whether the construction works or not) depending
> upon if you consider From an lvalue or rvalue:
> From f;
> To t1 = f; // one answer
> To t2 = From(); // potentially a different answer


> More specifically, if To and From are the same move-only type (say unique_ptr<int>),
> then you /do/ get a different answer.
> That being said, the vast majority of the is_convertible use cases simply don't care
> if the source is considered an lvalue or rvalue. E.g.:
> is_convertible<T*, U*>::value
> (same answer either way with pointers)
>>> is_convertible<Deleter, Deleter> gets instantiated and it is all over.
>> Specifically, how?
> The boost::is_convertible implementation requires access to a Deleter copy
> constructor. My modifications to the boost::is_convertible implementation treat the
> From as an rvalue and will attempt the "auto_ptr solution" for making a copy from an
> rvalue when From is an emulated move-only type (avoiding the Deleter copy
> constructor, and using the conversion to the rv<Deleter> instead).
>>> I've modified my copy of is_convertible (without really knowing what I'm doing)
>>> like
>>> so:
>>> Index: is_convertible.hpp
>>> ===================================================================
>>> --- is_convertible.hpp (revision 50433)
>>> +++ is_convertible.hpp (working copy)
>>> @@ -119,6 +119,8 @@
>>> struct any_conversion
>>> {
>>> template <typename T> any_conversion(const volatile T&);
>>> + template <typename T> any_conversion(volatile T&);
>>> + template <typename T> any_conversion(const T&);
>>> template <typename T> any_conversion(T&);
>>> };
>>> @@ -131,8 +133,8 @@
>>> 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 bool const value = sizeof( detail::checker<To>::_m_check(_m_from(), 0)
>>> )
>>> == sizeof(::boost::type_traits::yes_type);
>>> };
>> Note the From above is not the same as the one below at least in the
>> current code.
> I ran svn update on the boost-trunk before creating this diff.

You miss my point. I'm just pointing out that in the current code, the
>From above is always a reference type and the From below is not
necessarily a reference type.

>>> @@ -291,7 +293,8 @@
>>> template <typename From, typename To>
>>> struct is_convertible_impl
>>> {
>>> - typedef typename add_reference<From>::type ref_type;
>>> +// typedef typename add_reference<From>::type ref_type;
>>> + typedef From ref_type;
>>> BOOST_STATIC_CONSTANT(bool, value =
>>> (::boost::type_traits::ice_and<
>>> ::boost::type_traits::ice_or<
>> So it used to pass an lvalue of type _m_from, and after your change it
>> passes an rvalue. Of course, your change now assumes that From can be
>> returned from a function. I think you'll have a problem if you try this
>> with From being a noncopyable non-movable type.

Did you overlook this remark completely?

>>> This hits just the part targeting gcc.
>> (and old Borland compilers).
>>> The intent is that in boost::is_convertible<From, To> From is now
>>> considered an rvalue (unless From is a (lvalue) reference type). This
>>> makes my test case happy. I can now move construct a unique_ptr with
>>> a move-only deleter.
>>> Fwiw, this definition of is_convertible is consistent with std::is_convertible in
>>> N2800:
>> I was just going to ask that.
> To emulate the N2800 definition in C++03 one must treat void, array
> and function types specially in the implementation (arrays and
> functions can't be returned from functions and void can't be a
> function parameter). Even so, a C++03 library emulation will get
> noncopyable non-movable types wrong (as will the current
> boost::is_convertible).

I'm claiming that your emulation gives a compile-time error in that

Dave Abrahams
BoostPro Computing

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