在 C 中按值传递结构而不是传递指针有什么缺点吗？

Question

在 C 中按值传递结构而不是传递指针有什么缺点吗？

如果结构体很大，显然会存在复制大量数据的性能问题，但对于较小的结构体，它基本上应该与将多个值传递给函数相同。

当用作返回值时，它可能会更有趣。 C 函数只有单个返回值，但您通常需要多个返回值。 因此，一个简单的解决方案是将它们放入一个结构中并返回该结构。

有什么理由支持或反对吗？

由于大家可能不太清楚我在这里所说的内容，所以我举一个简单的例子。

如果您使用 C 进行编程，您迟早会开始编写如下所示的函数：

void examine_data(const char *ptr, size_t len)
{
    ...
}

char *p = ...;
size_t l = ...;
examine_data(p, l);

这不是问题。 唯一的问题是，您必须与同事同意参数的顺序，以便您在所有函数中使用相同的约定。

但是当您想要返回相同类型的信息时会发生什么？ 您通常会得到这样的信息：

char *get_data(size_t *len);
{
    ...
    *len = ...datalen...;
    return ...data...;
}
size_t len;
char *p = get_data(&len);

这工作正常，但问题较多。 返回值就是返回值，但在此实现中它不是。 从上面无法看出函数 get_data 不允许查看 len 指向的内容。 并且没有任何东西可以让编译器检查是否确实通过该指针返回了值。 因此，下个月，当其他人在没有正确理解代码的情况下修改代码时（因为他没有阅读文档？），它会在没有人注意到的情况下被破坏，或者开始随机崩溃。

因此，我提出的解决方案是简单的 struct

struct blob { char *ptr; size_t len; }

这些示例可以这样重写：

void examine_data(const struct blob data)
{
    ... use data.tr and data.len ...
}

struct blob = { .ptr = ..., .len = ... };
examine_data(blob);

struct blob get_data(void);
{
    ...
    return (struct blob){ .ptr = ...data..., .len = ...len... };
}
struct blob data = get_data();

出于某种原因，我认为大多数人会本能地让 examine_data 获取指向 struct blob 的指针，但我不这样做不明白为什么。 它仍然得到一个指针和一个整数，只是它们在一起更加清晰。 在 get_data 情况下，不可能像我之前描述的那样搞乱，因为没有长度的输入值，并且必须有一个返回的长度。

Answer 1

简单的解决方案将返回一个错误代码作为返回值，并将其他所有内容作为函数中的参数，
当然，这个参数可以是一个结构体，但通过值传递它并没有看到任何特殊的优势，只是发送了一个指针。
按值传递结构是危险的，你需要非常小心你传递的是什么，记住C中没有复制构造函数，如果结构参数之一是指针，则指针值将被复制，这可能会非常混乱并且难以理解维持。

只是为了完成答案（完全归功于 Roddy ）堆栈使用情况不按值传递结构的另一个原因是，相信我调试堆栈溢出是真正的 PITA。

重播评论：

通过指针传递结构意味着某个实体拥有该对象的所有权，并且完全了解应该释放什么以及何时释放。 按值传递结构会创建对结构内部数据的隐藏引用（指向另一个结构的指针等），这很难维护（可能但为什么？）。

Answer 2

这里有一点没有人提到：

void examine_data(const char *c, size_t l)
{
    c[0] = 'l'; // compiler error
}

void examine_data(const struct blob blob)
{
    blob.ptr[0] = 'l'; // perfectly legal, quite likely to blow up at runtime
}

const struct 的成员是 const，但如果该成员是一个指针（如 char *），它就变成char *const 而不是我们真正想要的 const char *。 当然，我们可以假设 const 是意图的文档，任何违反这一点的人都在编写糟糕的代码（他们确实如此），但这对于某些人来说还不够好（尤其是那些刚刚花了四小时追踪事故原因）。

另一种方法可能是创建一个 struct const_blob { const char *c; size_t l } 并使用它，但这相当混乱 - 它遇到了与 typedef 指针相同的命名方案问题。 因此，大多数人坚持只使用两个参数（或者，在这种情况下更可能使用字符串库）。

Answer 3

我认为你的问题已经很好地概括了事情。

按值传递结构的另一个优点是内存所有权是显式的。 毫无疑问，该结构是否来自堆，以及谁有责任释放它。

Answer 4

我想说按值传递（不太大的）结构，无论是作为参数还是作为返回值，都是一种完全合法的技术。 当然，必须注意该结构要么是 POD 类型，要么是明确指定的复制语义。

更新：抱歉，我已经具备了 C++ 思维能力。 我记得有一段时间，在 C 中从函数返回结构体是不合法的，但从那时起这可能已经改变了。 我仍然会说，只要您期望使用的所有编译器都支持这种做法，它就是有效的。

Answer 5

http://www.drpaulcarter.com/pcasm/ 上的 PC 组装教程第 150 页有明确的说明关于 C 如何允许函数返回结构体的解释：

C 还允许结构类型
用作函数的返回值
。 显然结构不能
返回到 EAX 寄存器中。
不同的编译器处理这个问题
情况不同。 普通的
编译器使用的解决方案是
在内部将该函数重写为一个
它将结构体指针作为
范围。 指针用于放置
将返回值放入结构体中
在调用的例程之外定义。

我用下面的C代码来验证上面的说法：

struct person {
    int no;
    int age;
};

struct person create() {
    struct person jingguo = { .no = 1, .age = 2};
    return jingguo;
}

int main(int argc, const char *argv[]) {
    struct person result;
    result = create();
    return 0;
}

使用“gcc -S”为这段C代码生成程序集：

    .file   "foo.c"
    .text
.globl create
    .type   create, @function
create:
    pushl   %ebp
    movl    %esp, %ebp
    subl    $16, %esp
    movl    8(%ebp), %ecx
    movl    $1, -8(%ebp)
    movl    $2, -4(%ebp)
    movl    -8(%ebp), %eax
    movl    -4(%ebp), %edx
    movl    %eax, (%ecx)
    movl    %edx, 4(%ecx)
    movl    %ecx, %eax
    leave
    ret $4
    .size   create, .-create
.globl main
    .type   main, @function
main:
    pushl   %ebp
    movl    %esp, %ebp
    subl    $20, %esp
    leal    -8(%ebp), %eax
    movl    %eax, (%esp)
    call    create
    subl    $4, %esp
    movl    $0, %eax
    leave
    ret
    .size   main, .-main
    .ident  "GCC: (Ubuntu 4.4.3-4ubuntu5) 4.4.3"
    .section    .note.GNU-stack,"",@progbits

调用create之前的堆栈：

        +---------------------------+
ebp     | saved ebp                 |
        +---------------------------+
ebp-4   | age part of struct person | 
        +---------------------------+
ebp-8   | no part of struct person  |
        +---------------------------+        
ebp-12  |                           |
        +---------------------------+
ebp-16  |                           |
        +---------------------------+
ebp-20  | ebp-8 (address)           |
        +---------------------------+

调用create之后的堆栈：

        +---------------------------+
        | ebp-8 (address)           |
        +---------------------------+
        | return address            |
        +---------------------------+
ebp,esp | saved ebp                 |
        +---------------------------+

Answer 6

我只想指出按值传递结构的一个优点是优化编译器可以更好地优化您的代码。

Answer 7

考虑到人们所说的所有事情......

1. 在 C 中并不总是允许返回结构。现在是了。
2. 返回结构可以通过三种方式完成......
   A。 返回寄存器中的每个成员（可能是最佳的，但不太可能是实际的......）
   b. 返回堆栈中的结构（比寄存器慢，但仍然比堆内存的冷访问更好......耶缓存！）
   C。 将结构返回到堆的指针中（它只会在您读取或写入时伤害您？一个好的编译器将传递它只读取一次并尝试访问的指针，进行指令重新排序并比需要更早地访问它，因此它你准备好了吗？（颤抖））
3. 因此，不同的编译器设置可能会导致代码接口出现不同的问题。 （不同大小的寄存器、不同的填充量、打开的不同优化）
4. 常量或易失性不会渗透到结构中，并且可能导致一些严重低效或可能导致代码损坏（例如 const 结构foo 不会导致 foo->bar 成为 const。）

阅读本文后我将采取一些简单的措施...

1. 让您的函数接受参数而不是结构。 它允许对常量性和易失性等进行细粒度控制，它还确保传递的所有变量都与使用它们的函数相关。 如果参数都是同一类型，请使用其他方法来强制排序。 （创建类型定义以使函数调用更加强类型化，这是操作系统例行执行的操作。）
2. 不要允许最终基函数返回指向堆中创建的结构的指针，而是提供指向将结果放入的结构的指针。 该结构仍然可能位于堆中，但该结构可能实际上位于堆栈中 - 并且将获得更好的运行时性能。 这也意味着您不需要依赖编译器为您提供结构返回类型。
3. 通过将参数作为片段传递并明确常量性、易失性或限制性，您可以更好地将您的意图传达给编译器，这将使其能够做出更好的优化。

我不确定“太大”和“太小”在哪里，但我猜答案是在 2 到注册数 + 1 名成员之间。
如果我创建了一个包含 1 个 int 成员的结构，那么显然我们不应该传递该结构。 （它不仅效率低下，而且还使意图非常模糊......我想它在某个地方有用途，但不常见）

如果我制作一个包含两个项目的结构，它可能具有清晰的价值，以及编译器可能将其优化为两个成对传播的变量。 （risc-v 指定具有两个成员的结构返回寄存器中的两个成员，假设它们是整数或更小...）

如果我创建一个结构，该结构保存与处理器中的寄存器中一样多的整数和双精度数，从技术上讲，这是一种可能的优化。
不过，在我超出寄存器数量的实例中，将结果结构保留在指针中并仅传递相关参数可能是值得的。 （这可能会使结构更小，函数的功能更少，因为我们现在的系统上有很多寄存器，即使在嵌入式世界中也是如此......）

Answer 8

对于小型结构（例如点、矩形），按值传递是完全可以接受的。 但是，除了速度之外，还有一个原因让您应该小心按值传递/返回大型结构：堆栈空间。

许多 C 编程是针对嵌入式系统的，其中内存非常宝贵，堆栈大小可能以 KB 甚至字节为单位...如果您按值传递或返回结构，这些结构的副本将被放置在堆栈，可能会导致此站点命名的情况...

如果我看到一个应用程序似乎有过多的堆栈使用，则结构按值传递是我首先寻找的东西之一。

Answer 9

不这样做的一个原因（尚未提及）是，这可能会导致二进制兼容性问题。

根据所使用的编译器，结构可以通过堆栈或寄存器传递，具体取决于编译器选项/实现

请参阅：http://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html

-fpcc-struct-return

-freg-struct-return

如果两个编译器不一致，事情可能会崩溃。 不用说，不这样做的主要原因是堆栈消耗和性能原因。

Answer 10

要真正回答这个问题，需要深入挖掘汇编领域：（

以下示例在 x86_64 上使用 gcc。欢迎任何人添加其他架构，如 MSVC、ARM 等）

让我们来看看示例程序：

// foo.c

typedef struct
{
    double x, y;
} point;

void give_two_doubles(double * x, double * y)
{
    *x = 1.0;
    *y = 2.0;
}

point give_point()
{
    point a = {1.0, 2.0};
    return a;
}

int main()
{
    return 0;
}

进行全面优化编译

gcc -Wall -O3 foo.c -o foo

查看程序集：

objdump -d foo | vim -

这就是我们得到的结果：

0000000000400480 <give_two_doubles>:
    400480: 48 ba 00 00 00 00 00    mov    $0x3ff0000000000000,%rdx
    400487: 00 f0 3f 
    40048a: 48 b8 00 00 00 00 00    mov    $0x4000000000000000,%rax
    400491: 00 00 40 
    400494: 48 89 17                mov    %rdx,(%rdi)
    400497: 48 89 06                mov    %rax,(%rsi)
    40049a: c3                      retq   
    40049b: 0f 1f 44 00 00          nopl   0x0(%rax,%rax,1)

00000000004004a0 <give_point>:
    4004a0: 66 0f 28 05 28 01 00    movapd 0x128(%rip),%xmm0
    4004a7: 00 
    4004a8: 66 0f 29 44 24 e8       movapd %xmm0,-0x18(%rsp)
    4004ae: f2 0f 10 05 12 01 00    movsd  0x112(%rip),%xmm0
    4004b5: 00 
    4004b6: f2 0f 10 4c 24 f0       movsd  -0x10(%rsp),%xmm1
    4004bc: c3                      retq   
    4004bd: 0f 1f 00                nopl   (%rax)

排除 nopl pads，give_two_doubles() 有 27 个字节，而 give_point( ) 有 29 个字节。 另一方面，give_point() 比 give_two_doubles() 生成的指令少一条。

有趣的是，我们注意到编译器已经能够优化 mov 进入更快的 SSE2 变体 movapd 和 movsd. 此外，give_two_doubles()实际上将数据移入和移出内存，这使得速度变慢。

显然，其中大部分内容可能不适用于嵌入式环境（这是当今 C 语言的主要竞争环境）。 我不是组装向导，所以欢迎任何评论！

Answer 11

到目前为止，这里的人们忘记提及的一件事（或者我忽略了它）是结构通常有一个填充！

struct {
  short a;
  char b;
  short c;
  char d;
}

每个 char 为 1 个字节，每个 Short 为 2 个字节。 该结构有多大？ 不，这不是 6 个字节。 至少在任何更常用的系统上是这样。 在大多数系统上，它将是 8。问题是，对齐方式不是恒定的，它取决于系统，因此相同的结构在不同的系统上将具有不同的对齐方式和不同的大小。

填充不仅会进一步消耗您的堆栈，还会增加无法提前预测填充的不确定性，除非您知道系统如何填充，然后查看应用程序中的每个结构并计算大小为了它。 传递指针需要可预测的空间量——没有不确定性。 指针的大小对于系统来说是已知的，无论结构是什么样子，它总是相等的，并且指针大小总是以对齐且不需要填充的方式选择。