与[[maybe_unused]]的结构化绑定 [英] structured binding with [[maybe_unused]]

查看:168
本文介绍了与[[maybe_unused]]的结构化绑定的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

具有模式匹配功能的语言(有时?)可能会忽略某些绑定值,但是对于C ++ 17结构化绑定,似乎无法做到这一点( std ::忽略结构化绑定?)。建议使用虚拟名称,但随后我们会收到有关未使用变量的警告。



使用clang和gcc的最新版本,可以完成预期的事情,既不错又有用,

  [[maybe_unused]] auto x = 4; //很好,没有警告
[[maybe_unused]] auto [a,dummyb,dummyc] = std :: tuple< int,int,float>(1,1,1.0f);

但我也希望这能起作用:

  auto [g,[[[maybe_unused]] dummyh,[[maybe_unused]] dymmyi] = 
std :: tuple< int,int,float>(1, 1,1.0f);

是否有特定原因属性在此处不能使用? (在标准和技术上)。 gcc或clang都不接受。






编辑,收集支持状态:(感谢 godbolt / compiler Explorer )。它按预期的方式工作(也可能更早):




  • gcc 8.0主干(g ++ 8.0.0 20171015实验)

  • clang 4.0.0

  • icc 18(根据规范

  • msvc 19.22(可能更早)(已修复,根据错误报告



https://gcc.godbolt.org/z/H2duYd

解决方案

在结构绑定文件:



http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0144r2.pdf



t嘿,讨论他们的推理:


3.8是否应该有一种方法可以显式地忽略组件?



动机是使编译器有关未使用名称的警告消失。



我们认为答案应该是不然而。这不是由
用例引起的(使编译器警告静音是一种动机,但它本身不是
用例),最好留给我们,直到我们可以在
上下文中重新审视之为止。一个更通用的模式匹配提案,其中
应该作为特殊情况落空。



与std :: tie对称将建议使用
之类的std :: ignore:

 元组< T1,T2,T3> F(); 
auto [x,std :: ignore,z] = f(); //不建议:忽略第二个元素

但是,这感觉很尴尬。



预期语言
中的模式匹配可能会建议使用_或*之类的通配符,但是由于我们尚没有
模式匹配,因此为时过早选择我们知道与
兼容的语法。这是一个纯扩展名,可以等到
具有模式匹配。


尽管这并未明确解决 [[maybe_unused]] ,我认为推理可能是相同的。停止编译器警告不是用例。


Functional languages with pattern matching (sometimes?) have the possibility to ignore some bound values, but with C++17 structured bindings there seem to be no way to do that (std::ignore with structured bindings?). The advice is to use a dummy name, but then we'll get warnings about unused variables.

With the latest heads of both clang and gcc, this does the expected thing, which is nice and useful,

[[maybe_unused]] auto x =4 ; // fine, no warning
[[maybe_unused]] auto [a,dummyb,dummyc] = std::tuple<int,int,float>(1,1,1.0f); 

but I would also have hoped this would work:

auto [g,[[maybe_unused]]dummyh,[[maybe_unused]]dymmyi] =
      std::tuple<int,int,float>(1,1,1.0f);

is there a specific reason attributes can not be used here? (in the standard as well as technically). Neither gcc or clang accepts this.


Edit, collecting the support status: (thanks to godbolt/compiler explorer). It works as expected in (could be earlier also):

  • gcc 8.0 trunk (g++ 8.0.0 20171015 experimental)
  • clang 4.0.0
  • icc 18 (not tested, according to specs)
  • msvc 19.22 (probably earlier) (Fixed, according to bug report)

Try it out in godbolt at https://gcc.godbolt.org/z/H2duYd

解决方案

In the structure bindings paper:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0144r2.pdf

they discuss their reasoning:

3.8 Should there be a way to explicitly ignore components?

The motivation would be to silence compiler warnings about unused names.

We think the answer should be "not yet." This is not motivated by use cases (silencing compiler warnings is a motivation, but it is not a use case per se), and is best left until we can revisit this in the context of a more general pattern matching proposal where this should fall out as a special case.

Symmetry with std::tie would suggest using something like a std::ignore:

   tuple<T1,T2,T3> f(); 
   auto [x, std::ignore, z] = f(); // NOT proposed: ignore second element 

However, this feels awkward.

Anticipating pattern matching in the language could suggest a wildcard like _ or *, but since we do not yet have pattern matching it is premature to pick a syntax that we know will be compatible. This is a pure extension that can wait to be considered with pattern matching.

Although this does not explicitly address [[maybe_unused]], I assume the reasoning might be the same. Stopping compiler warnings is not a use-case.

这篇关于与[[maybe_unused]]的结构化绑定的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆