GMock使用ElementsAreArray匹配C风格数组编译失败如何解决

问题根因 #

编译错误由C/C++数组退化规则触发：函数形参中声明的const uint8_t buffer[]会在编译阶段被自动退化为const uint8_t*裸指针类型，GoogleMock识别到的第二个参数类型是裸指针，而非带长度信息的数组或STL容器。
ElementsAreArray、ElementsAre类容器匹配器默认仅支持匹配STL容器或未发生退化的原生数组，面对裸指针时无法自动获取数组长度，也无法按容器逻辑解析类型，因此抛出“type is not a class, struct, or union type”的编译错误。将该位置匹配器替换为通配符_后可正常编译，也可印证问题源于匹配器与参数类型不匹配。

可行解决方案 #

结合嵌入式开发不使用STL容器的限制，可根据接口是否允许调整选择对应方案：

方案1：多参数联合匹配（无需修改业务接口，推荐嵌入式场景使用） #

通过With子句联合匹配缓冲区指针和长度参数，用内存比较逻辑校验数据内容，完全兼容裸指针类型，无额外依赖。
示例代码：

#include <cstring>

// 测试用例中定义期望发送的数据
const uint8_t expectedCmd[] = {0x00};
constexpr uint8_t expectedTxLen = sizeof(expectedCmd);

EXPECT_CALL(hal, i2c1Transmit(address0, _, expectedTxLen))
    .With(Args<1, 2>(Truly([&](const uint8_t* txBuf, uint8_t txLen) {
        // 先校验长度匹配，再逐字节比较缓冲区内容
        return txLen == expectedTxLen && memcmp(txBuf, expectedCmd, expectedTxLen) == 0;
    })))
    .WillOnce(Return(HAL_Ok));

该写法逻辑和嵌入式实际数据传输的校验逻辑一致，不会引入STL依赖，适配所有C风格数组传参退化的场景。

方案2：修改接口为数组引用类型（接口可控时使用） #

如果硬件抽象层接口允许调整，可将形参改为数组引用类型，避免数组退化，保留数组长度信息，即可直接使用ElementsAreArray完成匹配。
修改后的接口定义：

// 模板参数N自动推导传入数组的长度
template<size_t N>
virtual I2C_Status_e i2c1Transmit(uint8_t address, 
                                  const uint8_t (&buffer)[N], 
                                  uint8_t length) = 0;

对应Mock方法调整为模板形式后，原测试代码中ElementsAreArray(readStatusCommand, 1)的写法可直接编译通过，无需额外自定义匹配逻辑。注意该方案会让接口成为模板函数，需要评估对业务代码的影响。

注意点 #

ElementsAreArray支持C风格数组的特性，仅针对待匹配参数为未退化的原生数组的场景（如数组引用传参、数组传入不触发退化的上下文）生效。数组作为函数形参退化为裸指针后，会丢失编译期长度信息，容器类匹配器无法直接适配。

内容的提问来源于stack exchange，提问作者Tegan