友元函数定义未被导出原因及编译器目标文件函数纳入规则咨询

嘿，这个问题问到点子上了！我来给你掰扯清楚背后的逻辑，以及GCC和Clang到底是怎么决定哪些函数要放进目标文件的。

首先先复盘一下你遇到的场景，方便咱们对齐问题：

// header.h
#pragma once
int g(int val);

// main.cpp
#include "header.h"
int main() {
  return g(1);
}

// g.cpp
#include "header.h"
class C {
  /*[[gnu::used]]*/ friend int g(int val) {
    return val;
  }
};

编译链接时会报g(int)未定义，但给友元g加上[[gnu::used]]就正常了；如果把g写成普通全局函数，也不会有问题。核心疑问就是：编译器为啥会把这个友元函数给“丢了”？

接下来分几部分给你解释：

一、编译器默认的函数纳入规则 #

咱们先搞懂基础逻辑：GCC和Clang在编译单个.cpp文件（也就是编译单元）时，默认会把这些函数的定义放进目标文件（.o）：

• 非内联的全局/命名空间级函数，只要有外部可见的声明（比如你头文件里的int g(int);），哪怕当前编译单元里没调用它，编译器也会保留它的定义——因为编译器知道其他编译单元可能会调用它。
• 类的成员函数（非内联），只要类的实例可能被外部使用，或者函数被外部调用，也会被保留。
• 但如果编译器能100%确定某个函数在当前编译单元内完全没被使用，而且外部也不可能调用到它，就会把这个函数的定义从目标文件里移除，也就是所谓的“未使用函数消除”优化。

二、类内定义的友元函数的特殊之处 #

这就是你踩的坑了：当你在类内部定义友元函数时，这个函数的作用域和可见性有个特殊点——默认情况下，它是“隐藏”在类的作用域里的，除非你在类外部再做一次声明，把它“暴露”到全局/命名空间作用域。

编译器在处理g.cpp时的逻辑大概是这样的：

这个友元函数g的定义是在类C内部，而且在当前编译单元里，类C的任何成员都没调用过它。虽然头文件里有g的声明，但我没办法确定外部编译单元的调用（比如main.cpp里的g(1)）是不是真的指向这个友元定义——毕竟这个友元默认是隐藏的，外部本来就没法直接访问它。那既然它在当前单元没用，外部也用不上，就把它优化掉吧。

而如果是普通的全局函数，编译器明确知道头文件里的声明就是指向这个定义，外部编译单元肯定会调用它，所以一定会保留它的定义到目标文件里。

三、标准要求还是实现细节？ #

• C++标准并没有强制要求编译器必须保留这类友元函数的定义，标准只规定了友元函数的可见性和链接属性。所以你遇到的这个情况，本质上是GCC和Clang的实现优化——它们的“未使用函数消除”逻辑把这个友元函数判定为“无用”，所以没放进目标文件。
• 而[[gnu::used]]属性的作用，就是直接给编译器“下命令”：“别管你怎么判断，这个函数我有用，必须把它放进目标文件”，强制编译器保留它的定义，这样链接的时候main.cpp就能找到它了。

最后再给你提炼一下核心判定逻辑：

• 对于外部链接的函数：编译器默认保留，除非能确定它在当前编译单元无使用，且外部无法访问/调用它。
• 类内定义的友元函数：因为默认隐藏的特性，编译器容易判定它“外部无法调用”，所以会被优化掉，除非你用[[gnu::used]]强制保留，或者在类外部再做一次声明，让编译器知道这个函数是暴露给外部的。

内容来源于stack exchange