这确实是一个非常有意思且容易让人困惑的C++嵌套类细节问题，我们一步步拆解背后的原因，覆盖你所有的疑问点：

结论先行：这是标准合规的语言特性，不是编译器Bug #

g和clang的编译行为完全符合C标准的规定，这是针对嵌套类型设计的特殊作用域与名称查找规则导致的，并非编译器的非标准扩展。

背后的核心标准规则 #

要理解这个行为，需要掌握C++中关于类成员函数两阶段查找和嵌套类作用域绑定的两个关键规则：

1. 类成员函数的两阶段名称查找 #

对于类的非静态成员函数，编译器会分两个阶段处理其函数体：

• 第一阶段（声明点检查）：在函数声明的作用域（这里是嵌套类B的作用域）查找名称，若找不到则在外围类C的作用域查找已声明的名称（比如A的前置声明）。这一步确保A* a的指针声明合法——即使A是不完整类型，声明指针也是允许的。
• 第二阶段（外围类完整定义后）：当整个外围类C的定义全部完成后，编译器会再次对成员函数体进行完整的类型检查和名称解析。此时A的完整定义已经存在，所以a->value的访问完全合法——编译器能清晰看到A拥有value成员。

2. 嵌套类的作用域是整体单元 #

嵌套类A和B都属于外围类C的作用域，这个作用域是一个不可分割的整体单元。与全局作用域或命名空间不同，外围类的所有嵌套声明（包括前置声明和完整定义）都会被视为该作用域的一部分，成员函数体的类型检查会延迟到整个外围类定义结束后进行。

为什么调整后会失败？ #

对比你提到的两种失败场景，能更清晰地看到规则的边界：

场景1：把A/B移到全局作用域 #

当A和B是全局类时，B的成员函数体的类型检查会在B的定义点立即完成——全局作用域没有“延迟到整个外围结构完成”的规则，此时A还是不完整类型，自然会触发“非法使用不完整类型”的错误，这符合预期。

场景2：删除A的前置声明 #

如果去掉A的前置声明，在B的作用域中找不到任何A的声明，编译器在第一阶段查找就会失败，连A* a的声明都无法通过，所以会报“未知类型名称'A'”的错误。

标准演化的变化 #

这个特性并非C新标准的产物，它在**C98中就已经存在**，后续的C11、C17、C++20等标准版本都没有修改这个核心规则，反而在后续标准中对两阶段查找的细节进行了更明确的规范，确保不同编译器的行为一致。

实用价值：OMPL的使用场景 #

你提到的Open Motion Planning Library（OMPL）使用这个模式非常合理：它允许开发者在同一个外围类中组织相关的嵌套类型（比如优先级队列的比较器MotionCompare和对应的状态类），不需要严格按照“被依赖类先定义”的顺序编写代码，极大提升了代码的内聚性和可读性。

最终总结 #

1. 这种构造是标准合规的C++特性，依赖于外围类作用域的整体式名称查找和成员函数的两阶段检查规则；
2. 它不是编译器Bug，而是C++为了提升嵌套类型代码组织性而设计的规则；
3. 该规则从C++98到最新标准一直保持稳定，没有发生过影响该构造合法性的变化。

附你的测试代码（便于参考）：

struct C { // #1
    // Forward declaration only
    struct A; // #2
    struct B {
        // Pointer declaration is allowed with incomplete type
        A* a;
        int foo() {
            // Member requires complete definition of A
            return a->value;
        }
    };
    // Complete definition of A given after B
    struct A { int value; };
    // Members and constructor
    A a;
    B b;
    C(int x) : a{x}, b{&a} {}
};
int main() {
    C c{42};
    return c.b.foo(); // returns 42
}