编译宏控过滤和宏替换工具，还是放出来吧，也许对一些人有点用。

最新推荐文章于 2023-08-03 22:16:23 发布

原创最新推荐文章于 2023-08-03 22:16:23 发布 · 1.7k 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#c #C #c++ #C++ #宏替换 #编译器 #编译控制宏

C/C++ 专栏收录该内容

9 篇文章

订阅专栏

博客涉及C和C++语言，重点提及宏替换和编译控制宏相关内容，还给出了一个下载链接http://download.youkuaiyun.com/detail/taodm/5075958 。

http://download.youkuaiyun.com/detail/taodm/5075958

确定要放弃本次机会？

福利倒计时

: :

立减 ¥

普通VIP年卡可用

立即使用

taodm

关注关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
1
评论
分享

复制链接

分享到 QQ

分享到新浪微博

扫一扫
举报

举报

专栏目录

1 宏的使用大全

hope_wisdom的技术博客

02-08

3122

宏，也叫宏定义，并不是C/C++语言本身的一部分，不能直接对宏进行编译。在编译程序前，必须先对宏进行预先的处理（专业术语叫作“预处理”）。预处理器会分析所有的源文件，当遇到宏名称严格匹配时，就会展开宏，也就是用定义好的文本来代替宏名称。宏的用途主要有三点：一是可以为程序员的开发提供一定的便利性；二是可以有效减少源文件中大量重复的、相似的代码；三是可以在一定程度上减少系统的开销，提高程序的运行效率。C/C++语言预定义了一些宏定义，常用的宏定义如下表。宏名称数据类型备注__FILE__字符串。

编译宏控过滤和宏替换工具stedit1.2.5pro

02-20

为stedit1.2.5增加了比较强大的编译宏控过滤和宏替换功能。 2.tools-Manual 的auto deduce macro replace是智能推导模式，将根据用户指定的编译宏控、include路径，自动推导出当前文件所包含的所有的宏，经用户选择后，进行宏替换动作。 a)选中要进行宏替换的代码段 b)选择auto deduce macro replace 菜单 c)在新弹出的宏替换的主对话框里点击“设定宏” d)在新对话框里点“重新推导” e)会弹出对话框， 1.输入include目录，每行一个目录即可。 2.启用预置宏，如果是要分析boost的preprocess相关宏的替换过程，请勾选上所有内置宏 f)耐心等待后，会显示代码一共直接用了哪些宏等等。注意：至少确保左下“需要确定的宏”是空的，这是现在就知道已经用到，但是定义不唯一的，请对其进行适当的勾选。 g)点“确定”，退出此对话框 h)回到宏替换的主对话框，点“转换” i)如果过程中遇到没有确定的宏，会跳对话框，要求进行选择 j)请使用boost的低版本preprocess库：1.4x到1.5x

1 条评论您还未登录，请先登录后发表或查看评论

c++语言工具 宏替换工具

02-17

能够将宏的内容展开的工具能够将宏的内容展开的工具(目前已有更新版本，不必下载这个)

C编译预处理宏

chaoshui7758的博客

09-04

535

一、编译预处理作用：对源程序编译之前做一些处理,生成扩展C源程序种类宏定义 #define #ifdef #ifndef 文件包含 #include 条件编译 #if--#else--#endif等其他宏定义 #line #error #pragma 格式： “#”开头占单独一行句末不用加分号 1-2

第六章(隔离)

08-02

728

都在说解耦合，但是如何解，哪些情况下有偶尔呢？看看前人的总结总是好的此处都是针对编译时的解偶尔，不涉及链接和最后发布。 1、编译时耦合 1.1 IsA的关系继承：class D: public B 不管继承方式，B的变化都将影响D的重新编译。D的重新编译将会继续递归下去 1.2 Has A

利用宏定义实现调试语句的有效管理

LinSeanYu's Blog

02-10

995

在编代码的过程中，我们常常要写很多调试语句来观察代码的运行情况，但是，如果代码很长且输出内容很多的时候，输出的调试内容往往会影响到我们分析输出的结果，这时只要使用宏，就能很好地控制的调试语句的输出与否了，在大型的项目开发中使用的也是这种方法. 实例： #ifndef DEBUG #define print_bg() #else #define prin

TCC（TinyC）编译器汉化（中文编译器、汉语编程）之八：汇编处理

yuan722723的博客

11-25

1130

汇编处理源码如下： /* * GAS之类的ZHI汇编程序 */ #定义全局_使用 #导入 "zhi.h" #如果已定义配置_ZHI_汇编静态段 *最后_代码_段; /* 处理.previous asm指令 */ 静态_函数整数型汇编_获取_局部_标签_名称(知心状态机 *状态机1, 无符号整数型 n) { 字符型 buf[64]; 单词存储结构 *ts; snprintf(buf, 取大小(buf), "L..%u", n); ts = 单词表_查

如何为驱动程序添加宏控制

wjf201003050643的博客

04-10

403

背景：很多情况下，我们会在不同的项目上使用同一套代码，但是项目的不同会导致需求的不同，而宏控制可以解决这种或者诸多类似的问题。问题：如何在不影响其他项目的情况下为指定项目修改源代码？解决方案：（1）在该项目的配置文件*_deconfig中添加如下代码：CONFIG_XXXXXX=y（2）在*.c文件所在的文件夹下的Kconfig文件中添加如下代码：config XXXXXX tristate...

【SV宏】systemverilog中宏macro的使用__宏替换

m0_55406843的博客

08-03

3604

sv宏使用

C++宏详解

lovemysea的专栏

01-28

1330

C++宏详解代码自动生成-宏带来的奇技淫巧众多C++书籍都忠告我们C语言宏是万恶之首，但事情总不如我们想象的那么坏，就如同goto一样。宏有一个很大的作用，就是自动为我们产生代码。如果说模板可以为我们产生各种型别的代码(型别替换)，那么宏其实可以为我们在符号上产生新的代码(即符号替换、增加)。关于宏的一些语法问题，可以在google上找到。相信我，你对于宏的了解绝对没你想象的那么多。如

编译和宏

GodNotAMen的博客

05-19

2198

简单的介绍编译过程，以及宏的用法。

Android.bp正确姿势添加宏控制编译指南

转载和创作优秀的博客

01-10

4713

引言随着Android版本的迭代，越来越多的移动终端都用上了香喷喷的Android 9和10系统。相对于原来的Android版本，Android 9和10越来越多的使用Android.bp替换以前的Android.mk编译脚本。我们知道 Android.mk采用Makefile的语言，所以为了控制条件编译和多版本适配，我们可以在不同产品直接在Android.mk中采用Makefile语言控制编译。虽然我们也可以通过Android的预置工具androidmk将Android.mk转换为Android.b

宏的进一步理解

08-03

383

1 条件include 如下 CODE #ifndef MAIN_H_ #define MAIN_H_ 其它内容 #endif 上面在看到头文件时会看到作用就是阻止这个头文件被多次include 多次include就会出现重复的定义情况

[ Android 编译 ] Android.bp 根据条件添加宏定义

a572423926的博客

09-29

3823

如果不需要添加控制逻辑，只是单纯地添加宏定义，直接在 Android.bp 对应模块的 cflags / cppflags 中添加 "-DXXX" 即可。但是如果需要添加控制逻辑，由于 bp 文件跟 mk 文件不同，它是纯粹的配置，没有分支等流程控制，所以只能通过编写 Go 语言实现。之前没接触过 go 语言，但是编程语言都是相通的，百度一下相关的文章，根据自己的实际情况进行修改，磕磕绊绊地也算是完成了这个需求，这里记录一下实现的整个流程。

宏:makefile/c/java

邦的大杂烩

04-01

341

[记录曾经做过的一个项目宏控制] 一套代码做几个项目之类的，特别讨厌了。为了避免干扰，用宏做项目隔离是一个好办法。下面说一下我曾经实现过的一套方案。为不同项目创建宏定义并用特定文件记录解析文件并生成环境变量，用于makefile的编译隔离生成特定java全局变量，用于java代码隔离生成特定h头文件，定义#define，用于c代码隔离分析：为何用文件记录宏？当宏数量越來越多

makefile设置宏定义进行条件编译，实现多版本代码同时维护

m0_37635769的博客

09-16

3800

由于项目需求，本人需要同时维护多套代码（不同场景版本、debug版、release版等），同时每套代码之间大同小异，因此想通到设置宏定义进行条件编译，实现代码的多版本管理。优点：该种方法，只需要在makefile中定义好宏定义，其他地方不需要再定义，因为此时宏定义作用域为工程的所有文件。效率高、不容易出错。缺点：宏定义作用域有限，当需要在较多工程文件内条件编译时，需要注意定义宏定义，效率低、容易出错。补充2、makefile中变量值后面的空格问题。优点：写法简单，即插即用。

c语言进阶篇：宏

Jessica的博客

03-01

1474

define本质上是将文本内容在编译时进行替换,又因为他可以替换参数所以就出现了宏。 #define替换文本语法:#define name stuff 举一个例子 #define MAX 1000 #define reg register //为 register这个关键字，创建一个简短的名字 #define do_forever for(;;) //用更形象的符号来替换一种实现 #define CASE break;case //在写case语句的时候自动把 .

头文件中，如何使用宏控控制一个函数编译与否

最新发布

07-15

<think>我们讨论在头文件中使用宏控制函数条件编译的方法。根据引用[1]和[3]，头文件中通常包含函数声明，而函数定义通常在源文件中。但有时我们也会在头文件中定义内联函数或模板函数（C++）。在头文件中使用宏控制函数条件编译有两种情况：控制函数声明和控制函数定义（内联函数）。 ### 方法1：控制函数声明在头文件中，我们可以使用宏来控制是否声明某个函数。这样，当宏未定义时，该函数不会被声明，从而在链接时如果使用该函数会导致链接错误。 ```c // example.h #ifndef EXAMPLE_H #define EXAMPLE_H // 声明一个宏，用于控制函数声明 #ifdef ENABLE_FEATURE_X void feature_x_function(); // 条件编译的函数声明 #endif #endif // EXAMPLE_H ``` ### 方法2：控制函数定义（内联函数）如果函数是内联函数（在头文件中定义），那么我们可以使用宏来控制整个函数的定义。注意，内联函数的定义必须放在头文件中（或者被多个源文件包含的头文件中）。 ```c // example.h #ifndef EXAMPLE_H #define EXAMPLE_H // 内联函数定义的条件编译 #ifdef ENABLE_FEATURE_Y inline void feature_y_function() { // 函数实现 } #endif #endif // EXAMPLE_H ``` ### 方法3：控制函数定义（普通函数）通常情况下，普通函数的定义不应该放在头文件中，因为如果多个源文件包含该头文件，会导致多重定义错误。但是，我们可以使用`static`关键字将函数限定为文件作用域，这样每个包含该头文件的源文件都会有自己的副本。此时，我们可以用宏控制： ```c // example.h #ifndef EXAMPLE_H #define EXAMPLE_H #ifdef ENABLE_FEATURE_Z static void feature_z_function() { // 函数实现 } #endif #endif // EXAMPLE_H ``` 注意：使用`static`函数可能会导致代码膨胀，因为每个源文件都会有一个该函数的副本。 ### 方法4：控制函数定义（C++的模板函数）在C++中，模板函数通常必须在头文件中定义。我们可以使用宏来控制模板函数的实例化或定义。 ```cpp // example.hpp #ifndef EXAMPLE_HPP #define EXAMPLE_HPP template <typename T> void template_function(T value) { // 通用实现 } #ifdef ENABLE_SPECIALIZATION // 条件编译的特化版本 template <> void template_function<int>(int value) { // 针对int的特化实现 } #endif #endif // EXAMPLE_HPP ``` ### 注意事项 1. **宏定义的位置**：通常，我们会在编译命令中定义宏（如`gcc -DENABLE_FEATURE_X`）或者在头文件之前定义（但要注意避免在多个地方重复定义导致不一致）。 2. **头文件保护**：始终使用头文件保护宏（`#ifndef ... #define ... #endif`）来防止重复包含[^1]。 3. **内联函数**：在头文件中定义内联函数是合法的，但要注意内联函数应该短小，否则编译器可能忽略内联请求[^3]。 4. **静态函数**：使用`static`在头文件中定义函数，虽然可以避免链接错误，但会导致每个包含该头文件的源文件都有一份函数副本，增加代码体积。 5. **可维护性**：过多的条件编译可能会降低代码可读性，建议将条件编译集中在头文件的特定区域，并添加清晰的注释。 ### 示例：综合应用 ```c // config.h #ifndef CONFIG_H #define CONFIG_H // 条件编译函数声明 #ifdef LOGGING_ENABLED void log_message(const char* msg); #endif // 条件编译内联函数 #ifdef DEBUG_MODE inline void debug_print(const char* msg) { // 调试模式下的详细输出 printf("[DEBUG] %s\n", msg); } #endif // 条件编译静态函数 #ifdef USE_CUSTOM_ALLOCATOR static void* custom_alloc(size_t size) { // 自定义内存分配器 return malloc(size); } #endif #endif // CONFIG_H ``` ### 替代方案（不推荐在头文件中定义非内联函数）对于普通函数（非内联、非模板），建议将函数声明放在头文件中，而函数定义放在源文件中，并在源文件中使用条件编译： ```c // example.h void conditional_function(); // example.c #ifdef ENABLE_FUNCTION void conditional_function() { // 实现 } #else void conditional_function() { // 空实现或错误处理 } #endif ``` 这样，头文件中的声明始终存在，但函数的具体实现由宏控制。这样避免了在头文件中定义函数可能带来的问题。 ### 总结在头文件中使用宏控制函数条件编译，主要适用于： 1. 函数声明：通过宏控制是否声明函数。 2. 内联函数：通过宏控制内联函数的定义。 3. 静态函数：通过宏控制静态函数的定义（每个源文件独立）。 4. 模板函数（C++）：通过宏控制模板特化等。对于普通函数，建议将条件编译放在源文件中，而头文件只做声明。 --- §§相关问题§§ 1. 在头文件中使用宏控制函数定义时，如何避免多重定义错误？ 2. 条件编译的函数在不同编译单元（源文件）中宏定义不一致会导致什么问题？ 3. 如何测试条件编译的函数是否被正确包含或排除？</think>### 在C/C++头文件中使用宏控制函数条件编译的完整指南在头文件中使用宏控制函数条件编译时，需要根据函数类型采用不同的策略。以下是三种核心方法及其应用场景： --- #### 方法1：控制函数声明（推荐做法） ```c // myheader.h #pragma once // 基础函数声明（始终存在） void core_function(); // 条件编译的函数声明 #ifdef ENABLE_FEATURE_X void feature_x_function(); // 条件函数声明[^1] #endif #ifdef ENABLE_DEBUG_MODE void debug_log(const char* msg); // 调试函数声明 #endif ``` **特点**： 1. 使用`#ifdef`保护函数声明 2. 函数定义放在对应的`.c/.cpp`文件中 3. 头文件接口清晰，避免多重定义错误[^3] 4. 不同编译单元可独立配置宏定义 --- #### 方法2：控制内联函数定义 ```c // math_utils.h #pragma once // 条件编译的内联函数 #if defined(USE_OPTIMIZED_MATH) && USE_OPTIMIZED_MODE == 1 inline float fast_sqrt(float x) { // SIMD优化实现 return _mm_sqrt_ss(x); } #else inline float fast_sqrt(float x) { // 标准实现 return sqrtf(x); } #endif ``` **适用场景**： 1. 短小的内联函数（编译器自动内联）[^3] 2. 性能关键路径的优化切换 3. 平台特定的指令集优化（如SSE/AVX） 4. 需在头文件实现的模板函数（C++） --- #### 方法3：控制静态函数（谨慎使用） ```c // local_helpers.h #pragma once // 条件编译的静态函数 #ifdef ENABLE_LOCAL_CACHE static void init_cache() { // 每个编译单元独立副本 // 缓存初始化代码 } #endif ``` **注意事项**： 1. 使用`static`限定作用域避免链接冲突 2. 每个包含头文件的编译单元会创建独立副本 3. 仅适用于小型工具函数 4. 可能增加代码体积（慎用于大型函数）[^3] --- ### 关键实践原则 1. **头文件保护机制** ```c #pragma once // 或 #ifndef HEADER_NAME / #define HEADER_NAME ``` 防止多重包含导致的重复定义[^1] 2. **宏定义管理** ```makefile # Makefile示例 CFLAGS += -DENABLE_FEATURE_X -DDEBUG_MODE=1 ``` 通过编译命令统一控制宏开关 3. **跨平台兼容处理** ```c // platform_adapt.h #if defined(_WIN32) #define API_EXPORT __declspec(dllexport) #elif defined(__linux__) #define API_EXPORT __attribute__((visibility("default"))) #endif #ifdef BUILD_DLL API_EXPORT void dll_function(); #endif ``` 4. **条件函数的配套宏** ```c // 为条件函数提供默认实现宏 #ifndef ENABLE_ADVANCED_FEAT #define advanced_function() ((void)0) // 无操作宏 #endif ``` --- ### 错误示例分析 ```c // 错误：普通函数定义在头文件中 #ifdef ENABLE_ERROR void error_func() { // 多个源文件包含将导致多重定义! /* 实现代码 */ } #endif ``` **正确做法**： ```c // 头文件声明 #ifdef ENABLE_ERROR void error_func(); // 仅声明 #endif // 源文件定义 #ifdef ENABLE_ERROR void error_func() { /* 实现 */ } // 单一定义 #endif ``` --- ### 条件编译函数类型对照表 | **函数类型** | **推荐方法 | **优点** | 风险点 | |--------------------|------------------|------------------------------|----------------------| | 普通函数 | 方法1（声明控制）| 避免链接错误 | 需同步维护声明/定义 | | 内联函数 | 方法2（内联控制）| 零开销切换 | 可能增加代码膨胀 | | 静态工具函数 | 方法3（静态控制）| 文件作用域安全 | 多副本内存浪费 | | 模板函数(C++) | 方法2（内联控制）| 必需在头文件实现 | 编译时间可能增加 | > 💡 最佳实践：优先使用方法1（声明控制），内联/模板函数用方法2，静态函数仅在小范围辅助场景使用方法3 ---