diff --git a/zh-cn/contribute/OpenHarmony-cpp-coding-style-guide.md b/zh-cn/contribute/OpenHarmony-cpp-coding-style-guide.md index 6cdb3adfc3b74f1799105112407f875d0694bd0c..e33f8b5df29f912c3c31bc7cb26adeeed0d676a4 100755 --- a/zh-cn/contribute/OpenHarmony-cpp-coding-style-guide.md +++ b/zh-cn/contribute/OpenHarmony-cpp-coding-style-guide.md @@ -508,11 +508,12 @@ int&p = i; // Bad ### 规则3.13.2 避免使用宏 宏会忽略作用域,类型系统以及各种规则,容易引发问题。应尽量避免使用宏定义,如果必须使用宏,要保证证宏名的唯一性。 -在C++中,有许多方式来避免使用宏: -- 用const或enum定义易于理解的常量 -- 用namespace避免名字冲突 -- 用inline函数避免函数调用的开销 -- 用template函数来处理多种类型 +在C++中,有许多方式来避免使用宏: +- 用const或enum定义易于理解的常量 +- 用namespace避免名字冲突 +- 用inline函数避免函数调用的开销 +- 用template函数来处理多种类型 + 在文件头保护宏、条件编译、日志记录等必要场景中可以使用宏。 ### 规则3.13.3 禁止使用宏来表示常量 @@ -520,23 +521,24 @@ int&p = i; // Bad ### 规则3.13.4 禁止使用函数式宏 宏义函数式宏前,应考虑能否用函数替代。对于可替代场景,建议用函数替代宏。 -函数式宏的缺点如下: -- 函数式宏缺乏类型检查,不如函数调用检查严格 -- 宏展开时宏参数不求值,可能会产生非预期结果 -- 宏没有独立的作用域 +函数式宏的缺点如下: +- 函数式宏缺乏类型检查,不如函数调用检查严格 +- 宏展开时宏参数不求值,可能会产生非预期结果 +- 宏没有独立的作用域 - 宏的技巧性太强,例如#的用法和无处不在的括号,影响可读性 - 在特定场景中必须用编译器对宏的扩展语法,如GCC的statement expression,影响可移植性 -- 宏在预编译阶段展开后,在期后编译、链接和调试时都不可见;而且包含多行的宏会展开为一行。函数式宏难以调试、难以打断点,不利于定位问题 -- 对于包含大量语句的宏,在每个调用点都要展开。如果调用点很多,会造成代码空间的膨胀 +- 宏在预编译阶段展开后,在期后编译、链接和调试时都不可见;而且包含多行的宏会展开为一行。函数式宏难以调试、难以打断点,不利于定位问题 +- 对于包含大量语句的宏,在每个调用点都要展开。如果调用点很多,会造成代码空间的膨胀 函数没有宏的上述缺点。但是,函数相比宏,最大的劣势是执行效率不高(增加函数调用的开销和编译器优化的难度)。 为此,可以在必要时使用内联函数。内联函数跟宏类似,也是在调用点展开。不同之处在于内联函数是在编译时展开。 - -内联函数兼具函数和宏的优点: -- 内联函数执行严格的类型检查 + +内联函数兼具函数和宏的优点: +- 内联函数执行严格的类型检查 - 内联函数的参数求值只会进行一次 - 内联函数就地展开,没有函数调用的开销 -- 内联函数比函数优化得更好 +- 内联函数比函数优化得更好 + 对于性能要求高的产品代码,可以考虑用内联函数代替函数。 例外: