C++友元注入仅MSVC可编译、其余编译器报错未声明的合规与实现咨询

结论非常明确：MSVC的这套编译行为完全不符合C++标准的强制要求。

C++标准对类内部定义的友元函数，定了两个绕不开的查找规则：

• 类内部定义的友元函数，不会被自动注入到类所在的外围命名空间的普通查找作用域。也就是说你写在bar结构体内部的create函数定义，默认不会在外围全局作用域留下一个可以被普通名字搜索找到的函数声明。
• 对这类藏在类内部的友元函数，唯一的合法查找触发途径是参数依赖查找（ADL）：只有当函数调用的实参类型，和定义友元函数的类属于同一个关联查找集合时，编译器才能找到这个函数。

对比两个能跨所有编译器正常编译的例子就能看出区别：
第一个全兼容的示例里，create是定义在foo类内部的，调用语句create(foo{})的实参是foo类型，ADL的查找范围天然会覆盖foo类本身，自然能找到藏在foo内部的友元函数。
而有问题的示例里，create藏在bar类内部，函数参数是foo类型——调用create(foo{})时，ADL的查找范围只会覆盖和foo关联的类、命名空间集合，完全不会触达bar的作用域，自然会报找不到声明的错误。

MSVC之所以能编译过这段代码，是早年为了兼容不规范的历史代码留的非标准扩展：它会把类内定义的友元函数隐式提升到外围全局命名空间的普通查找作用域里，完全绕过了标准要求的ADL查找规则。这种行为和GCC、Clang遵循的两阶段名字查找规则是冲突的，属于编译器的非标准偏差，根本不是可移植的合法C++代码。对做模板库开发的场景来说，这种偏差的风险尤其高，很容易在跨编译器编译时引出难以排查的模板实例化错误。

在不挪走bar内部友元函数定义的前提下，完全可以写出跨所有标准编译器兼容的代码，常用的可靠方案有两种：

方案1：在外围命名空间提前做函数前向声明 #

这是最无侵入、完全不改变原有函数接口的方案。只要在bar结构体定义之前，在外围的命名空间里把create的函数签名提前声明一次即可：

// 提前做类型前向声明，解决函数签名的编译依赖
struct foo;
struct bar;

// 提前把create的名字注入到外围命名空间的普通查找作用域
bar create(foo arg);

// 后续的类型定义、友元函数定义和原有写法完全一致
struct foo {};
struct bar {
  // 友元函数的定义依然写在bar内部，会直接匹配之前的前向声明
  friend bar create(foo) { return {}; }
};

int main() {
  auto a = create(foo{}); // 所有遵循标准的编译器都能正常通过
  return 0;
}

这个方案的核心逻辑是：提前的前向声明会把create的名字正式绑定到外围命名空间，后续在bar内部写的友元实现，会直接匹配这个提前声明的函数实体，不会生成标准规则下的“隐藏友元”，普通查找就能定位到函数，完全兼容所有编译器。哪怕是带模板参数的场景，只要把对应的模板签名提前做前向声明即可，没有额外的复杂度。

方案2：调整函数参数列表触发ADL查找 #

如果不想在外围提前写前向声明，可以给create函数加一个带默认值的bar类型参数，让ADL的查找范围自然覆盖bar：

struct foo {};
struct bar {
  // 类内定义友元函数，带一个默认值的bar类型参数
  friend bar create(foo, bar = {}) { return {}; }
};

int main() {
  auto a = create(foo{}); 
  // 调用时编译器展开默认参数，ADL的查找范围会包含bar类，自然能找到内部的友元函数
  return 0;
}

这个方案同样符合标准规则。如果担心外部可以显式传两个参数调用破坏原有接口，可以在bar内部定义一个仅自身可构造的私有标记类型替换这个默认参数，彻底屏蔽外部的非法调用路径。

内容的提问来源于stack exchange，提问作者김선달