C++里也有菱形运算符?
  yZdUbUDB8h5t 18天前 30 0
C++

最近在翻《c++函数式编程》的时候看到有一小节在说c++14新增了“菱形运算符”。我寻思c++里好像没什么运算符叫这名字啊,而且c++14新增的功能很少,我也不记得有添加这种语法特性。一瞬间我有些怀疑我的记忆了,所以为了查漏补缺,我写了这篇文章。

什么是菱形运算符

这个概念在Java里比较多见:

List<String> myList = new ArrayList<>();

这东西在Java里的学名是diamond operator,表示使用泛型类并且类型参数在左侧的表达式已给出因此在右侧可以省略。

简单的说就是让你少写几次重复的类型参数。因为看起来像个菱形所以得名菱形运算符。

然后我们偶尔会在c++里看到形状上很相似的东西:

std::sort(vec.begin(), vec.end(), std::greater<>());

<>出现在模板的特化中是我们所熟悉的,但这个std::greater<>()是什么呢?

c++没有菱形运算符

先说结论,从语言标准来说,c++里没有什么菱形运算符。

c++20里虽然新增了一个运算符operator<=>,但这个和所谓的菱形运算符没有任何关系。

那问题来了,std::greater<>()是什么以及为什么书里说是c++14新增的特性呢?难道书里瞎说的吗?但事实是这样的示例代码在c++14以及之后的标准下可以正常编译运行,而且这本书的质量尚可,虽然会在措辞上犯些小错(比如c++没有菱形运算符)但不至于花大篇幅去胡说八道。

当然,要想回答这个问题我们得先复习点基础知识。

<>在c++里的作用

先说结论,在c++里看到<>,绝大多数都是在为模板提供类型参数,当然这种东西我们不讨论:(a<1, 2>b),这里<>是在两个不同的表达式里。

那既然用来提供类型参数,那为什么可以啥都不提供呢?答案是有两类情况确实可以。

第一类是在函数模板上,类型参数可以自动推导时:

template <typename T>
void f(const T&)
{
    std::cout << "f<T>\n";
}
template <>
void f(const int&)
{
    std::cout << "f<int>\n";
}

void f(const int&)
{
    std::cout << "f\n";
}

int main()
{
    f(1);    // f
    f<>(1);  // f<int>
    f(1.2);  // f<T>
}

非模板函数在重载决议中的优先级总是高于模板的,因此f(1)这样的表达式总是会用到最下面定义的那个非模板函数f。这时候我们可以用f<int>(1)来直接调用函数模板f,而函数模板的类型参数如果能从参数推导出来的话,可以不明确给出(也就是后面的f(1.2)那样的),而在我们现在这句表达式里,我们既要明确使用函数模板,又想让类型参数被自动推导,就得使用f<>(1)

另一种情况不分类模板还是函数模板,当模板的类型参数有默认值时,可以靠<>来使用这些默认值:

template <typename T = void>
struct Wrapper
{
    using wrappered = T;
};

// Wrapper<> 等于 Wrapper<void>
static_assert(std::is_same_v<Wrapper<>::wrappered, Wrapper<void>::wrappered>);

在第二种情况下,因为没显示给出类型参数,且这里没法使用类型推导,因此编译器使用了类型参数的默认值,这里是void。

观察比较仔细的话其实会发现上面两种情况其实是一件事,<>相当于没有显示给出任何类型参数,于是对这些没有显示指定的类型参数,编译器会先尝试类型推导,如果没法推导则会检查这些类型参数是否有默认值,有就利用默认值。如果上面这两步都没法得到能正常使用的类型参数,模板会被SFINAE淘汰或者报出编译错误。

这并不是什么新语法,是从有模板开始就一直存在的规则。

现在我们可以看看std::greater<>()是什么了,首先std::greater是个类模板,然后它接受一个类型参数,这个参数在c++14之后有了默认值void,因此std::greater<>()std::greater<void>()

c++14中究竟添加了什么

既然c++14并没有添加“菱形运算符”,那究竟新增了什么呢?

在已经知道了std::greater<>()的真身后,找起来就很容易了,所以我很快找到了对应的新特性:n3421

这个特性是这样的:原先我们要用标准库提供的谓词模板,需要自己指明参数类型,这样写起来很麻烦而且对于那种嵌套的或者元素类型复杂的容器来说写明参数类型不仅费时而且费力,更要命的是对于map,一不小心是会有性能问题的:

for_each(map.begin(), map.end(), std::pred<std::pair<std::string, int64_t>>());

上述代码的问题在于正确的参数类型应该是std::pair<const std::string, int64_t>,我们漏掉了const,这会导致pair整个被复制一遍,性能是无比底下的。要彻底避免这种错误,就得利用自动类型推导。

然而前面说了,标准库提供的谓词基本全是类模板,类模板的模板参数要么依赖默认值要么得显示指定,怎么才能依赖自动推导呢。

于是这个新特性最精彩的地方来了:原先的模板的调用运算符不是模板参数也是定死的,但我们可以新加一个默认参数,然后针对这个默认参数的类型进行完全特化,在特化里提供一个泛型的operator(),这样就能利用函数模板来自动推导参数类型了,而且以前的代码不受影响。

默认参数的设置也是有讲究的,需要用一个谓词用不到的且不会影响老代码的类型,运气不错,void正好符合条件(void上几乎没法做什么操作,因此也不会被指定给这些谓词做类型参数),因此现在的greater的代码是下面这样的:

// 注意默认值是void
template <typename T = void> struct greater {
    constexpr bool operator()(const T& lhs, const T& rhs) const 
    {
        return lhs > rhs;
    }
};

// 针对greater<void>的完全特化
template <> struct greater<void> {
    template <class T, class U> auto operator()(T&& t, U&& u) const
    -> decltype(std::forward<T>(t) > std::forward<U>(u))
    { return std::forward<T>(t) > std::forward<U>(u); }
};

当使用std::greater<T>()的时候,代码的逻辑和原来一样,当使用std::greater<void>()的时候,返回的Functor的函数调用运算符是个模板,可以自己推导参数类型和返回值类型。至于为啥greater<void>的内部构造可以和其他情况实例化的greater区别这么大,这个是c++的特性:模板的不同实例之间是可以异构的。

而且因为类型参数的默认值就是void,因此可以简写成std::greater<>()

所以c++14只是给标准库里可以代替运算符的模板们增加了默认类型参数和一个泛型的调用运算符,利用这些可以简化代码并确保类型安全。

真相是其实没啥菱形运算符,只是利用了以前就存在的模板的特性简化了标准库的使用,让人少写点字。达成的效果倒是和Java的菱形运算符差不多。

总结

显然书里有夸大成分,老话说尽信书不如无书,还得小心检验才是。

顺便我们复习了现代c++的重要原则:能依赖自动类型推导的地方,没必要自己手写。

因此应该多写这样的代码:std::sort(vec.begin(), vec.end(), std::greater<>());

不过还有最后一个问题,为啥不直接用lambda呢?那是因为能指定类型参数的泛型lambda要在c++20才出现,在这之前想要让lambda完全做到类型安全得费点功夫,而且lambda整体上也不如直接用标准库提供的std::greater<>()std::less<>()之类的简洁易懂。

【版权声明】本文内容来自摩杜云社区用户原创、第三方投稿、转载,内容版权归原作者所有。本网站的目的在于传递更多信息,不拥有版权,亦不承担相应法律责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@moduyun.com

  1. 分享:
最后一次编辑于 18天前 0

暂无评论

推荐阅读
  8Tw5Riv1mGFK   16天前   26   0   0 C++
  BYaHC1OPAeY4   9天前   28   0   0 C++
  3dygdw7fVgD7   21天前   22   0   0 C++
  oBaV3jusLkh1   19天前   26   0   0 C++
  nmX9dIiR6BtA   19天前   27   0   0 C++
  yZdUbUDB8h5t   12天前   19   0   0 C++
yZdUbUDB8h5t