应该std :: common_type使用std :: decay？ [英] should std::common_type use std::decay?

问题描述

给定类型 A，B ，我关心 std :: common_type< A，B& c>，忽略任意类型 A ... std :: common_type< A ...> >。所以让

 使用T = decltype（true？std :: declval< A>（）：std :: declval< B& （））; 
 using C = std :: common_type< A，B> ;; 
  

现在，根据多个来源，我发现了以下关系c> typename ）：

• cppreference.com ： C :: type = std :: decay< T> :: type




• cplusplus.com ： C :: type = T




• GCC 4.8.1 < type_traits& / code> implementation： C :: type = std :: decay< T> :: type 如果 T 有效，否则 C 不包含 :: type 成员（SFINAE-friendly）




• Clang 3.3 < type_traits> 实现： C :: type = std :: remove_reference< T> :: type

我找到SFINAE友好的GCC一个小细节，而 std :: remove_reference 和 std :: decay 实际上只不同的内置数组和职能，加上cv-qualification，对于这一点我也不关心太多。所以我的问题是

应该是衰减< T> :: type $ c> T ？使用 decay< T> :: type 的理由是什么？它只是关于表示结果 A（）+ B（）例如。对于算术表达式

例如，试验一下，我发现在just code>定义，我们有

  common_type< int&，int& = int& 
 common_type< int&，long&> = long 
  

即，如果类型相等则保持一个左值引用 。这反映了

  int a，b; 
（true？a：b）= 0; 
  

有效，而

  int a; 
 long b; 
（true？a：b）= 0; 
  

不是。这个语义的允许赋值，如果类型是平等的正是我需要在一个应用程序，我倾向于相信 common_type 和 decay 应该是两个独立的步骤。我应该使用我自己的定义吗？

解决方案

应该std :: common_type使用std :: decay ？

是，请参阅图书馆工作组缺陷＃2141 。

短版（长版，请参阅上文链接） p>

• declav< A>（）返回 A&&&&&&&&&&& amp;&&< / code>




• common_type c> declval ，n3337：

    template< class T，class U& 
   struct common_type< T，U> {
   typedef decltype（true？declval< T>（）：declval< U>（））type; 
  }; 
    




• common_type< int，int> :: type 因此产生 int&&&& ，这是意料之外的。




• decay

   模板< class T，class U& 
   struct common_type< T，U> {
   typedef decay_t< decltype（true？declval< T>（）：declval< U>（））>类型; 
  }; 
    




• common_type< int，int> :: type 现在产生 int

Given types A,B, I am concerned with the exact definition of std::common_type<A,B>, disregarding the variadic case std::common_type<A...> for arbitrary types A.... So let

using T = decltype(true ? std::declval<A>() : std::declval<B>());
using C = std::common_type<A,B>;

Now, according to a number of sources, I have found the following relations (skipping typename for brevity):

• cppreference.com: C::type = std::decay<T>::type

• cplusplus.com: C::type = T

• GCC 4.8.1 <type_traits> implementation: C::type = std::decay<T>::type if T is valid, otherwise C does not contain a ::type member ("SFINAE-friendly")

• Clang 3.3 <type_traits> implementation: C::type = std::remove_reference<T>::type

I find the "SFINAE-friendly" version of GCC a minor detail, while std::remove_reference and std::decay practically only differ in built-in arrays and functions, plus cv-qualification, for which again I am not concerned much. So my question is

Should it be decay<T>::type or just T? What is the rationale of using decay<T>::type? Is it only about representing result A() + B() e.g. for arithmetic expressions?

For instance, experimenting a bit, I have found that in the case of the "just T" definition, we have

common_type<int&,int&> = int&
common_type<int&,long&> = long

that is, an lvalue reference is maintained if types are equal. This reflects the fact that

int a, b;
(true ? a : b) = 0;

is valid, while

int a;
long b;
(true ? a : b) = 0;

is not. This semantics of "allowing assignment if types are equal" is exactly what I need in one application, and I tend to believe that common_type and decay should be two independent steps. Should I just use my own definitions?

解决方案

should std::common_type use std::decay?

Yes, see Library Working Group Defect #2141.

Short version (long version, see link above):

• declval<A>() returns a A&&

• common_type is specified via declval, n3337:

  template <class T, class U>
  struct common_type<T, U> {
      typedef decltype(true ? declval<T>() : declval<U>()) type;
  };
  

• common_type<int, int>::type therefore yields int&&, which is unexpected

• proposed resolution is to add decay

  template <class T, class U>
  struct common_type<T, U> {
      typedef decay_t < decltype(true ? declval<T>() : declval<U>()) > type;
  };
  

• common_type<int, int>::type now yields int

这篇关于应该std :: common_type使用std :: decay？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！