问题标签 [structured-bindings]

为什么在这种情况下我不能使用 C++17 结构化绑定？

来自cppref

与引用一样，结构化绑定是现有对象的别名。与引用不同，结构化绑定的类型不必是引用类型。

例如：

x并且y是别名而不是引用。我的问题：

如何实现类型检查功能is_alias_v<decltype(x)>？

我在 GCC 中遇到了这段代码的分段错误，但使用 MSVC 编译得很好

结构化绑定会发出段错误。

日志：

解决方案

将结构化绑定声明为引用。

看起来 GCC 无法推断出限定符，因为 operator[] 返回一个 T&。

我有一个模板采用在结构上可绑定到两个别名的类型（可以是元组，也可以是结构）。我需要别名指向的这两个变量的类型。

在实际使用结构化绑定之前，我需要知道类型：

我正在提取一个元组，auto [...]但我只使用一些元组坐标。我想知道是否有一些优雅的方法可以避免unused-variable编译器警告？这是我的代码。

这是编译行+警告：

（我使用了一个类似 Haskell 的变量_来自我记录最后一个 int 是一个无关值的事实）。

我有一个std::vector<T> vec感兴趣的 3 个元素的连续块。为了便于处理，我想提取这些元素。目前，代码如下所示：

我想使用结构化绑定将 , 的提取压缩a到b一行c。

一个简单的选项将类似于以下内容：

问题是我想避免无用的数据复制。我不确定，但似乎向量元素将在这里复制到元组中。使用std::tuple<T&, T&, T&>是一种选择吗？

此代码编译并运行，并带有“未使用的变量 i”警告：

我想忽略 i，所以我将其替换为std::ignore. 以下代码无法编译：

出现此错误：

这个警告：

因为它无法识别 std::ignore。

一些上下文：

• 我将 C++17 与 gcc 7.4.0 和 Eclipse CDT 一起使用。
• 语法检查器显示与编译器相同的错误。这是连贯的。
• 同一项目的许多 cpp 文件中的其他范围也存在同样的问题。这是一个普遍的问题，而不是特别局限于那条特定的线。

• 只是为了测试，这一行编译得很好：

  标准::忽略 = 0;

所以 gcc 识别 std::ignore，它只是在范围内没有这样做。

已经阅读了这个关于忽略结构化绑定的好问题和答案。

有没有人有类似的问题？

谢谢！

我试图通过使用 和 来查看 unordered_map 的结构化绑定中的auto推导auto &类型auto &&。

无论我使用for(auto [k,v]:m)or for(auto & [k,v]:m)or for(auto && [k,v]:m)，输出总是

我的问题是：

• 为什么在or的情况下decltype(k)anddecltype(v)不是引用类型？for(auto & [k,v]:m)for(auto && [k,v]:m)

• 为什么decltype(k)是类型const的情况下for(auto [k,v]:m)？

解构 a 时有没有办法隐藏现有变量std::pair？例如，如果我定义了以下函数：

然后这个main函数工作正常，因为我从返回的新变量std::pair：

输出：

但我不能使用相同的变量名并隐藏现有变量，因为这会尝试再次实际声明它们：

错误：

我也试过没有auto，但这给出了一个完全不同的错误：

错误：

有没有办法做到这一点？

Consider the following class foo:

I would like to implement structured bindings for foo, so I added the following:

Now, if the user is to perform structure bindings, he/she has to explicitly add a const qualifier:

(Because we cannot bind int& to a int const&)

Or, alternatively, I can make tuple_element typedef a const int. Now all four statements compiles:

Now note that even if no const qualifier is present in their declarations, a, b, x, and y are all int const. This might be confusing to the user.

So my question is: which one of the above is considered a better practice?