通用转换运算符模板和移动语义:任何通用解决方案? [英] Generic conversion operator templates and move semantics: any universal solution?
问题描述
这是操作中的显式引用限定转化操作符模板的后续操作。我已经尝试了许多不同的选项,我在这里给出一些结果,试图看看是否有任何解决方案最终。
This is a follow-up of Explicit ref-qualified conversion operator templates in action. I have experimented with many different options and I am giving some results here in an attempt to see if there is any solution eventually.
说一个类(例如 any )需要提供转换到任何可能的类型在一个方便,安全(没有惊喜)的方式,保留移动语义。我可以想出四种不同的方式。
Say a class (e.g. any) needs to provide conversion to any possible type in a convenient, safe (no surprises) way that preserves move semantics. I can think of four different ways.
struct A
{
// explicit conversion operators (nice, safe?)
template<typename T> explicit operator T&& () &&;
template<typename T> explicit operator T& () &;
template<typename T> explicit operator const T& () const&;
// explicit member function (ugly, safe)
template<typename T> T&& cast() &&;
template<typename T> T& cast() &;
template<typename T> const T& cast() const&;
};
// explicit non-member function (ugly, safe)
template<typename T> T&& cast(A&&);
template<typename T> T& cast(A&);
template<typename T> const T& cast(const A&);
struct B
{
// implicit conversion operators (nice, dangerous)
template<typename T> operator T&& () &&;
template<typename T> operator T& () &;
template<typename T> operator const T& () const&;
};
最有问题的情况是初始化对象或对对象的右值引用,右值引用。函数调用工作在所有情况下(我想),但我发现他们太详细:
The most problematic cases are to initialize an object or an rvalue reference to an object, given a temporary or an rvalue reference. Function calls work in all cases (I think) but I find them too verbose:
A a;
B b;
struct C {};
C member_move = std::move(a).cast<C>(); // U1. (ugly) OK
C member_temp = A{}.cast<C>(); // (same)
C non_member_move(cast<C>(std::move(a))); // U2. (ugly) OK
C non_member_temp(cast<C>(A{})); // (same)
因此,我接下来尝试使用转换运算符:
So, I next experiment with conversion operators:
C direct_move_expl(std::move(a)); // 1. call to constructor of C ambiguous
C direct_temp_expl(A{}); // (same)
C direct_move_impl(std::move(b)); // 2. call to constructor of C ambiguous
C direct_temp_impl(B{}); // (same)
C copy_move_expl = std::move(a); // 3. no viable conversion from A to C
C copy_temp_expl = A{}; // (same)
C copy_move_impl = std::move(b); // 4. OK
C copy_temp_impl = B{}; // (same)
看来, const&
overload可以在一个右值上调用,这会产生歧义,使得隐式转换的副本初始化作为唯一选项。
It appears that the const&
overload is callable on an rvalue, which gives ambiguities, leaving copy-initialization with an implicit conversion as the only option.
但是, :
template<typename T>
struct flexi
{
static constexpr bool all() { return true; }
template<typename A, typename... B>
static constexpr bool all(A a, B... b) { return a && all(b...); }
template<typename... A>
using convert_only = typename std::enable_if<
all(std::is_convertible<A, T>{}...),
int>::type;
template<typename... A>
using explicit_only = typename std::enable_if<
!all(std::is_convertible<A, T>{}...) &&
all(std::is_constructible<T, A>{}...),
int>::type;
template<typename... A, convert_only<A...> = 0>
flexi(A&&...);
template<typename... A, explicit_only<A...> = 0>
explicit flexi(A&&...);
};
using D = flexi<int>;
它提供了一般的隐式或显式构造函数,这取决于输入参数是隐式还是显式转换为某种类型。这种逻辑不是那么奇怪,例如。一些实现 std :: tuple
可以这样。现在,初始化 D
会产生
which provides generic implicit or explicit constructors depending on whether the input arguments can be implicitly or explicitly converted to a certain type. Such logic is not that exotic, e.g. some implementation of std::tuple
can be like that. Now, initializing a D
gives
D direct_move_expl_flexi(std::move(a)); // F1. call to constructor of D ambiguous
D direct_temp_expl_flexi(A{}); // (same)
D direct_move_impl_flexi(std::move(b)); // F2. OK
D direct_temp_impl_flexi(B{}); // (same)
D copy_move_expl_flexi = std::move(a); // F3. no viable conversion from A to D
D copy_temp_expl_flexi = A{}; // (same)
D copy_move_impl_flexi = std::move(b); // F4. conversion from B to D ambiguous
D copy_temp_impl_flexi = B{}; // (same)
出于不同的原因,唯一可用的选项direct-initialization带有隐式转换。但是,这正是隐式转换危险的地方。 b
可能实际上包含 D
,这可能是一种容器,但工作组合调用 D
的构造函数作为完全匹配,其中 b
表现为容器的一个假的元素导致运行时错误或灾难。
For different reasons, the only available option direct-initialization with an implicit conversion. However, this is exactly where implicit conversion is dangerous. b
might actually contain a D
, which may be a kind of container, yet the working combination is invoking D
's constructor as an exact match, where b
behaves like a fake element of the container, causing a runtime error or disaster.
最后,让我们尝试初始化一个右值引用:
Finally, let's try to initialize an rvalue reference:
D&& ref_direct_move_expl_flexi(std::move(a)); // R1. OK
D&& ref_direct_temp_expl_flexi(A{}); // (same)
D&& ref_direct_move_impl_flexi(std::move(b)); // R2. initialization of D&& from B ambiguous
D&& ref_direct_temp_impl_flexi(B{}); // (same)
D&& ref_copy_move_expl_flexi(std::move(a)); // R3. OK
D&& ref_copy_temp_expl_flexi(A{}); // (same)
D&& ref_copy_move_impl_flexi = std::move(b); // R4. initialization of D&& from B ambiguous
D&& ref_copy_temp_impl_flexi = B{}; // (same)
看起来每个用例都有自己的要求,可能会在所有情况下工作。
It appears that every use case has its own requirements and there is no combination that might work in all cases.
更糟糕的是,以上所有结果都是clang 3.3;其他编译器和版本给出略有不同的结果,再没有通用解决方案。例如:实例。
What's worse, all above results are with clang 3.3; other compilers and versions give slightly different results, again with no universal solution. For instance: live example.
因此: strong>有什么可能的东西可能按照需要工作,或者我应该放弃转换操作符和坚持显式函数调用?
So: is there any chance something might work as desired or should I give up conversion operators and stick with explicit function calls?
推荐答案
不幸的是,C ++标准没有任何特殊的规则来解决这个特定的歧义。问题来自于你试图重载两个不同的事情:编译器试图转换的类型;
The C++ standard unfortunately does not have any special rule to resolve this particular ambiguity. The problem come from the fact that you are trying to overload on 2 different things: the type that the compiler is trying to convert to; and the kind of reference from which you are trying to convert from.
通过引入代理类,您可以在两个步骤中拆分分辨率。步骤1:确定它是r值引用,l值引用还是const l值引用。步骤2:转换为任何类型,保持步骤1中关于参考种类的决定。这样,你可以使用带有cast()函数的解决方案,但是不必指定类型:
By introducing proxy classes, you can split the resolution in 2 steps. Step 1: decide if it's an r-value reference, an l-value reference, or a const l-value reference. Step 2: convert to any type, keeping the decision made in step 1 about the kind of reference. That way, you can use your solution with a cast() function but save you from having to specify the type:
struct A
{
class A_r_ref
{
A* a_;
public:
A_r_ref(A* a) : a_(a) {}
template <typename T> operator T&&() const&&;
};
struct A_ref
{
A* a_;
public:
A_ref(A* a) : a_(a) {}
template <typename T> operator T&() const&&;
};
struct A_const_ref
{
const A* a_;
public:
A_const_ref(const A* a) : a_(a) {}
template <typename T> operator const T&() const&&;
};
A_r_ref cast() && { return A_r_ref(this); }
A_ref cast() & { return A_ref(this); }
A_const_ref cast() const& { return A_const_ref(this); }
};
这篇关于通用转换运算符模板和移动语义:任何通用解决方案?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!