大家好，我是痞子衡，是正经搞技术的痞子。今天痞子衡给大家介绍的是MCUXpresso IDE下C++源文件中嵌套定义的复合数据类型命名空间认定。
痞子衡之前写过一篇文章 《MCUXpresso IDE下添加C++源文件进SDK工程编译的方法》，通过这篇文章我们知道嵌入式工程里是能够支持 C 源文件和 C++ 源文件混合编译的（因为有很多开源的库是基于 C++ 语言的，我们需要移植到嵌入式工程里）。
最近有一个 RW612 客户在使用官方 SDK 时就遇到一个 C/C++ 混合编译问题，主要涉及复合数据类型（结构体、联合体、枚举）嵌套定义时的命名空间范围认定，今天我们就来聊一聊这个话题：
- Note1：测试软件版本为 MCUXpresso IDE v11.10.0_3133
- Note2：该问题普遍存在于不同 IDE 编译器，非 GCC 专属
一、引出编译问题
客户使用得是 SDK_2_16_000_RD-RW612-BGA 开发包里的基础 hello_world 例程模板，当客户尝试在工程里添加自己创建的 C++ 源文件，并且在该 C++ 源文件中使用 fsl_clock.h 里声明的如下 clock_frg_clk_config_t 复合数据类型时遇到了编译错误：
typedef struct _clock_frg_clk_config
{
uint8_t num;
enum
{
kCLOCK_FrgMainClk = 0,
kCLOCK_FrgPllDiv,
kCLOCK_FrgSFro,
kCLOCK_FrgFFro,
} sfg_clock_src;
uint8_t divider;
uint8_t mult;
} clock_frg_clk_config_t;
客户出现问题的 C++ 源代码也足够简单，只是定义了 clock_frg_clk_config_t 类型的变量 frg_config，并对其中 sfg_clock_src 成员进行赋值，结果编译报错 'kCLOCK_FrgPllDiv' was not declared in this scope。
clock_frg_clk_config_t frg_config;
frg_config.sfg_clock_src = kCLOCK_FrgPllDiv;
当我们尝试在 C 源代码里使用相同的代码时，编译是没问题的，因此可知 clock_frg_clk_config_t 结构体里直接嵌套的 sfg_clock_src 枚举类型申明在 C 编译器（arm-none-eabi-gcc）下命名空间是整个文件，而在 C++ 编译器（arm-none-eabi-c++）下命名空间仅在 clock_frg_clk_config_t 结构体内。
二、解决编译问题
知道了编译问题和命名空间有关，要解决问题，那就通过 C++ 的作用域解析运算符 :: 来解决，修改代码如下，此时编译正常。但是这样是完美的解决方案吗？很显然，同样功能的代码，在 C/C++ 源文件里写法不一致，这看起来很别扭。
clock_frg_clk_config_t frg_config;
frg_config.sfg_clock_src = clock_frg_clk_config_t::kCLOCK_FrgPllDiv;
什么是更好的解决方案？答案就是单独申明每个复合数据类型原型，让所有复合数据类型命名空间都一样，这样我们统一用 C 语言语法即可。实际上在恩智浦官方 SDK 里一直是这样的设计准则，客户遇到的这个情况是个“美丽”的意外。
typedef enum _sfg_clock_src
{
kCLOCK_FrgMainClk = 0,
kCLOCK_FrgPllDiv,
kCLOCK_FrgSFro,
kCLOCK_FrgFFro,
} sfg_clock_src_t;
typedef struct _clock_frg_clk_config
{
uint8_t num;
sfg_clock_src_t sfgClockSrc
uint8_t divider;
uint8_t mult;
} clock_frg_clk_config_t;
至此，MCUXpresso IDE下C++源文件中嵌套定义的复合数据类型命名空间认定痞子衡便介绍完毕了，掌声在哪里~~~
欢迎订阅
文章会同时发布到我的 博客园主页、CSDN主页、知乎主页、微信公众号 平台上。
微信搜索"痞子衡嵌入式"或者扫描下面二维码，就可以在手机上第一时间看了哦。
