为什么在C ++中使用元组并不常见？

为什么似乎没有人在C ++中使用元组，无论是Boost Tuple库还是TR1的标准库？我读了很多C ++代码，很少看到元组的用法，但是我经常看到很多地方元组可以解决许多问题（通常从函数返回多个值）。

元组可以让您做各种很酷的事情，例如：

tie(a,b) = make_tuple(b,a); //swap a and b

那肯定比这更好：

temp=a;
a=b;
b=temp;

当然，您始终可以这样做：

swap(a,b);

但是，如果要轮换三个值怎么办？您可以使用元组来执行此操作：

tie(a,b,c) = make_tuple(b,c,a);

元组还使从函数返回多个变量变得更加容易，这可能比交换值更常见。使用引用返回值当然不是很好。

我没有想到的元组有什么大的缺点吗？如果没有，为什么很少使用它们？他们慢吗？还是仅仅是人们不习惯他们？使用元组是个好主意吗？

因为它不是标准的。任何非标准的障碍都更高。Boost的某些部分之所以流行，是因为程序员大声疾呼。（hash_map让我记忆犹新）。但是，虽然元组很方便，但并不是让人为之烦恼的压倒性的胜利。

一个愤世嫉俗的答案是，许多人使用C ++进行编程，但不了解和/或使用更高级别的功能。有时是因为不允许这样做，但是许多人根本不尝试（甚至不理解）。

作为一个非增强示例：有多少人使用中提供的功能<algorithm>？

换句话说，许多C ++程序员只是使用C ++编译器的C程序员，也许std::vector还有std::list。这就是为什么使用boost::tuple不常见的原因之一。

C ++元组语法可能比大多数人想要的更为冗长。

考虑：

typedef boost::tuple<MyClass1,MyClass2,MyClass3> MyTuple;

因此，如果您想广泛使用元组，那么要么在各处获得元组typedef，要么在各处获得烦人的长类型名。我喜欢元组。我在必要时使用它们。但这通常仅限于两种情况，例如N元素索引或使用多图绑定范围迭代器对时。而且通常范围非常有限。

与Haskell或Python之类的东西相比，它们看起来都非常丑陋。当C ++ 0x到达此处，我们得到'auto'关键字元组时，它们看起来将变得更具吸引力。

元组的有用性与声明，打包和解压缩它们所需的击键数量成反比。

对我来说，这是一种习惯，放下手来：元组不会为我解决任何新问题，只有几个我已经可以应付。以旧的方式交换价值仍然很容易-而且，更重要的是，我并不真正考虑如何交换“更好”。就这样就足够了。

就个人而言，我认为元组不是返回多个值的理想解决方案-听起来像是structs 的工作。

但是，如果要轮换三个值怎么办？

swap(a,b);
swap(b,c);  // I knew those permutation theory lectures would come in handy.

好的，所以有了4个etc值，最终n元组的代码少于n-1个交换。使用默认交换时，它会执行6个分配，而不是您自己实现一个三周期模板时分配的4个分配，尽管我希望编译器会为简单类型解决该分配。

您可以提出交换不方便或不合适的方案，例如：

tie(a,b,c) = make_tuple(b*c,a*c,a*b);

打开包装有点尴尬。

但是，要指出的是，有一些已知的方法可以处理元组最适合的最常见情况，因此没有紧迫性来处理元组。如果没有别的，我不确定：

tie(a,b,c) = make_tuple(b,c,a);

不会进行6次复制，因此完全不适用于某些类型（最明显的是集合）。可以这样说服我，说服元组是“大型”类型的一个好主意，:-)

对于返回多个值，如果值是不兼容的类型，则元组是完美的，但是如果调用者有可能以错误的顺序获取它们，则有些人不喜欢它们。有些人根本不喜欢多个返回值，也不想通过简化返回值来鼓励使用它们。有些人只喜欢使用命名结构来输入和输出参数，可能无法用棒球棒说服使用元组。没有占味。

正如许多人指出的那样，元组只是没有其他功能有用。

1. 交换和旋转头仅仅是头。它们使以前从未见过的人感到困惑，并且由于几乎所有人，这些everyone头只是不良的软件工程实践。

2. 与元组相比，使用元组返回多个值的自我记录要少得多-返回命名类型或使用命名引用。如果没有这种自我记录，那么很容易混淆返回值的顺序（如果它们可以相互转换），并且不明智。

并非所有人都可以使用Boost，TR1尚未广泛使用。

在嵌入式系统上使用C ++时，引入Boost库变得很复杂。它们彼此耦合，所以库的大小增加了。您返回数据结构或使用参数传递代替元组。在Python中返回元组时，数据结构的顺序和返回值的类型不明确。

您很少看到它们，因为设计良好的代码通常不需要它们-在很多情况下，使用匿名结构优于使用命名结构。由于元组真正代表的只是一个匿名结构，因此大多数情况下，大多数编码器都只使用真实的东西。

假设我们有一个函数“ f”，其中元组返回可能有意义。通常，此类功能通常非常复杂，以至于它们可能会失败。

如果“ f”可能失败，那么您需要返回状态-毕竟，您不希望调用者必须检查每个参数以检测失败。“ f”可能适合该模式：

struct ReturnInts ( int y,z; }
bool f(int x, ReturnInts& vals);

int x = 0;
ReturnInts vals;
if(!f(x, vals)) {
    ..report error..
    ..error handling/return...
}

那不是很漂亮，但是看看替代方案有多丑。请注意，我仍然需要一个状态值，但是代码不易读且不短。这可能也较慢，因为我使用元组会产生1份副本的费用。

std::tuple<int, int, bool> f(int x);
int x = 0;
std::tuple<int, int, bool> result = f(x); // or "auto result = f(x)"
if(!result.get<2>()) {
    ... report error, error handling ...
}

另一个重要的缺点隐藏在这里-通过“ ReturnInts”，我可以通过修改“ ReturnInts”而不增加“ f”的接口来添加“ f”的返回值。元组解决方案不提供该关键功能，因此对于任何库代码而言，它都是次等答案。

当然，元组可能是有用的，但是如前所述，在真正使用它们之前，存在一些开销和一两个障碍。

如果您的程序始终找到需要返回多个值或交换多个值的地方，那么走元组路线可能是值得的，但是有时候以经典方式进行操作会更容易。

一般而言，并不是每个人都已经安装了Boost，并且我当然不会为下载它和配置我的include目录而仅为其元组功能使用它而烦恼。我想您会发现，已经使用Boost的人比非Boost用户更容易在其程序中找到元组的使用，并且来自其他语言的移民（想到Python）更可能因缺少元组而感到不安比起在C ++中探索添加元组支持的方法。

由于数据存储std::tuple具有struct和阵列最差的特性；所有访问均基于第n个位置，但无法tuple使用for循环进行遍历。

因此，如果从tuple概念上讲，元素中的元素是数组，那么我将使用数组；如果从概念上讲，元素不是数组，则结构（具有命名元素）将更易于维护。（a.lastname比更具解释性std::get<1>(a)）。

这使OP提到的转换成为元组唯一可行的用例。

我感觉很多人都使用Boost.Any和Boost.Variant（经过一些工程）而不是Boost.Tuple。