如何避免out参数？

Question

我见过很多论点，认为使用返回值比输出参数更可取。我确信避免它们的原因，但我发现自己不确定是否遇到了不可避免的情况。

我的问题的第一部分是：您最喜欢/常见的使用 out 参数的方法是什么？大意是这样的：伙计，在同行评审中，我总是看到其他程序员这样做，而他们本可以轻松地这样做。

我的问题的第二部分涉及我遇到的一些特定情况，在这些情况下我想避免使用 out 参数，但无法想出一种干净的方法来做到这一点。

示例1： 我有一堂课，里面有一本我想避免的昂贵副本。可以在该对象上完成工作，这使得对象的复制成本很高。建立数据的工作也并非微不足道。目前，我将把这个对象传递给一个函数来修改该对象的状态。对我来说，这比新建工作函数内部的对象并将其返回更可取，因为它允许我将内容保留在堆栈上。

class ExpensiveCopy //Defines some interface I can't change.
{
public:
    ExpensiveCopy(const ExpensiveCopy toCopy){ /*Ouch! This hurts.*/ };
    ExpensiveCopy& operator=(const ExpensiveCopy& toCopy){/*Ouch! This hurts.*/};

    void addToData(SomeData);
    SomeData getData();
}

class B
{
public:
    static void doWork(ExpensiveCopy& ec_out, int someParam);
    //or
    // Your Function Here.
}

使用我的函数，我调用这样的代码：

const int SOME_PARAM = 5;
ExpensiveCopy toModify;
B::doWork(toModify, SOME_PARAM);

我想要这样的东西：

ExpensiveCopy theResult = B::doWork(SOME_PARAM);

但我不知道这是否可能。

第二个例子： 我有一系列对象。数组中的对象是复杂类型，我需要对每个元素进行工作，我希望将这些工作与访问每个元素的主循环分开。目前的代码如下所示：

std::vector<ComplexType> theCollection;
for(int index = 0; index < theCollection.size(); ++index)
{
    doWork(theCollection[index]);
}

void doWork(ComplexType& ct_out)
{
   //Do work on the individual element.
}

关于如何处理其中一些情况有什么建议吗？我主要使用 C++ 工作，但我有兴趣了解其他语言是否有助于更轻松的设置。我遇到过 RVO 作为一种可能的解决方案，但我需要阅读更多内容，它听起来像是编译器特定的功能。

Answer 1

据我所知，更喜欢返回值而不是输出参数的原因是它更清晰，并且它适用于纯函数式编程（如果函数仅依赖于输入参数、返回值并且具有无副作用）。第一个原因是风格上的，在我看来并不是那么重要。第二个不太适合 C++。因此，我不会尝试扭曲任何内容以避免参数丢失。

简单的事实是，某些函数必须返回多个内容，并且在大多数语言中，这建议输出参数。 Common Lisp 有multiple-value-bind 和multiple-value-return，其中绑定提供符号列表并返回值列表。在某些情况下，函数可以返回复合值，例如随后将被解构的值列表，对于 C++ 函数返回 std::pair 来说并不是什么大问题。在 C++ 中以这种方式返回两个以上的值会变得很尴尬。定义一个结构体总是可以的，但是定义和创建它通常比输出参数更混乱。

在某些情况下，返回值会过载。在 C 中， getchar() 返回一个 int ，其想法是 int 值比 char 更多（在我知道的所有实现中为 true，在我可以轻松想象的一些实现中为 false），因此其中之一这些值可用于表示文件结束。 atoi() 返回一个整数，要么是它所传递的字符串表示的整数，要么是零（如果没有），因此它对“0”和“frog”返回相同的值。 （如果您想知道是否存在 int 值，请使用 strtol()，它有一个 out 参数。）

在发生错误时总是有抛出异常的技术，但是并非所有多个返回值都是错误，也并非所有错误都是异常的。

因此，重载的返回值会导致问题，多个值返回并不容易在所有语言中使用，并且单个返回并不总是存在。抛出异常通常是不合适的。使用 out 参数通常是最干净的解决方案。

Answer 2

问问自己为什么要使用某种方法来对这个复制成本高昂的对象执行工作。假设您有一棵树，您会将树发送到某种构建方法中，还是为树提供自己的构建方法？当你的设计有点偏离时，这样的情况就会经常出现，但当你把它拍下来时，往往会自行折叠起来。

我知道在实践中我们并不总是能够改变每个对象，但是传入参数是一种副作用操作，它使得弄清楚发生了什么变得更加困难，而且你永远不需要这样做（除非在其他人的代码框架内工作而被迫）。

有时它更容易，但毫无理由地使用它绝对是不可取的（如果您经历过一些大型项目，其中总是有六个输出参数，您就会明白我的意思）。

Answer 3

我不确定您为什么试图避免在这里传递引用。几乎在这些情况下，存在引用传递语义。

该代码

static void doWork(ExpensiveCopy& ec_out, int someParam);

对我来说看起来非常好。

如果你真的想修改它，那么你有几个选项

1. 移动 doWork ，这样它就是 ExpenseCopy 的成员（你说你不能这样做，所以那就出局了）
2. 从 doWork 返回一个（智能）指针而不是复制它。 （你不想这样做，因为你想将东西保留在堆栈上）
3. 依赖RVO（其他人指出几乎所有现代编译器都支持RVO）

Answer 4

如果启用了优化，每个有用的编译器都会执行 RVO（返回值优化），因此以下操作实际上不会导致复制：

Expensive work() {
    // ... no branched returns here
    return Expensive(foo);
}

Expensive e = work();

在某些情况下，编译器也可以应用 NRVO，即返回值优化：

Expensive work() {
    Expensive e; // named object
    // ... no branched returns here
    return e; // return named object
}

但这并不完全可靠，仅适用于更琐碎的情况，并且必须经过测试。如果您无法测试每种情况，只需在第二种情况下使用带有引用的输出参数即可。

Answer 5

在我看来，您应该问自己的第一件事是复制 ExppressiveCopy 是否真的如此昂贵。为了回答这个问题，您通常需要一个分析器。除非探查器告诉您复制确实是一个瓶颈，否则只需编写更易于阅读的代码：ExpenseCopy obj = doWork(param);。

当然，确实存在出于性能或其他原因无法复制对象的情况。那么尼尔的答案适用。

Answer 6

除了这里的所有评论之外，我还要提到，在 C++0x 中，您很少会使用输出参数来实现优化目的——因为移动构造函数（请参阅 此处）

Answer 7

除非你走“一切都是不可变的”路线，这不太适合 C++。您无法轻易避免 out 参数。 C++ 标准库使用它们，对它来说足够好的对我来说就足够了。

Answer 8

至于您的第一个示例：返回值优化通常允许直接在中创建返回的对象-place，而不必四处复制对象。所有现代编译器都这样做。

Answer 9

您在什么平台上工作？

我问的原因是很多人建议返回值优化，这是几乎每个编译器中都存在的非常方便的编译器优化。此外，微软和英特尔还实施了他们所谓的命名返回值优化，这更加方便。

在标准返回值优化中，您的返回语句是对对象构造函数的调用，它告诉编译器消除临时值（不一定是复制操作）。

在命名返回值优化中，您可以按名称返回值，编译器也会执行相同的操作。 NRVO 的优点是您可以在返回创建的值之前对其执行更复杂的操作（例如对其调用函数）。

虽然如果返回的数据非常大，这些都不能真正消除昂贵的副本，但它们确实有帮助。

就避免复制而言，唯一真正的方法是使用指针或引用，因为您的函数需要在您希望其最终到达的位置修改数据。这意味着您可能希望有一个传递-参考参数。

另外，我认为我应该指出，由于这个原因，按引用传递在高性能代码中非常常见。复制数据的成本可能非常高，而且人们在优化代码时常常会忽略这一点。