企业官网建设流程全解析

别再只会用__func__了！C/C++中7种获取函数名的方法全解析

调试日志里千篇一律的__func__输出是否让你感到厌倦？当你的项目从简单Demo演变为复杂系统时，函数调用链追踪的精确性直接决定了调试效率。本文将带你突破基础用法，系统梳理7种函数名获取技术，从经典的宏函数到C++20的source_location，助你构建更强大的代码自省能力。

1. 基础宏函数：从变量名到函数名的字符串化魔法

许多开发者尚未意识到，通过简单的宏预处理就能实现变量名和函数名的字符串化转换。#预处理运算符是这项技术的核心，它可以将宏参数直接转换为字符串字面量。

#define TO_STR(x) #x int sampleVar = 42; printf("%s -> %d", TO_STR(sampleVar), sampleVar); // 输出：sampleVar -> 42

这种技术最实用的场景是创建自描述的调试输出。我们可以进一步封装成调试专用宏：

#define DEBUG_VAR(var) \ printf("[DEBUG] %s:%d %s = %d\n", \ __FILE__, __LINE__, #var, var) void test() { int counter = 0; DEBUG_VAR(counter); // 输出：[DEBUG] test.cpp:15 counter = 0 }

注意事项：

• 宏展开发生在预处理阶段，无法获取运行时信息
• 对于函数指针等复杂表达式，字符串化结果可能不符合预期
• 在模板编程中需要额外处理类型参数

2. 标准预定义标识符：__func__的局限与优势

作为C99引入的标准特性，__func__的优势在于跨平台一致性，但其输出内容也最为基础。它在不同上下文中的表现值得注意：

namespace MyNS { class MyClass { public: static void staticFunc() { printf("%s\n", __func__); // 输出：staticFunc } void memberFunc() { printf("%s\n", __func__); // 输出：memberFunc } }; }

与常见误解不同，__func__实际上是隐式声明的static const char[]数组，而非宏定义。这意味着：

// 以下代码可以编译通过 const char* get_func_name() { return __func__; // 合法，返回指向静态数组的指针 }

提示：在日志系统中使用__func__时，建议配合__LINE__使用，以提供更精确的代码定位信息。

3. 编译器扩展：GCC/Clang的__PRETTY_FUNCTION__

当基础函数名无法满足需求时，GCC和Clang提供的__PRETTY_FUNCTION__能给出包含类名和参数类型的完整签名：

典型用例对比：

template<typename T> void templateFunc(T param) { cout << "__func__: " << __func__ << endl; cout << "__PRETTY_FUNCTION__: " << __PRETTY_FUNCTION__ << endl; } // 调用templateFunc<int>(42)输出： // __func__: templateFunc // __PRETTY_FUNCTION__: void templateFunc(T) [with T = int]

在模板元编程调试中，__PRETTY_FUNCTION__能直观显示模板实例化类型，这是它无可替代的价值。

4. MSVC生态：FUNCSIG__与__FUNCDNAME

Windows开发环境下，MSVC提供了一组特有的宏来满足不同粒度的需求：

• __FUNCTION__：基础函数名（类似__func__）
• __FUNCSIG__：完整函数签名（包含调用约定）
• __FUNCDNAME__：修饰后的函数名（用于链接器识别）

class __declspec(dllexport) MyClass { public: void __stdcall Method(int x) { std::cout << "__FUNCTION__: " << __FUNCTION__ << "\n"; std::cout << "__FUNCSIG__: " << __FUNCSIG__ << "\n"; std::cout << "__FUNCDNAME__: " << __FUNCDNAME__ << "\n"; } }; /* 输出示例： __FUNCTION__: Method __FUNCSIG__: void __stdcall MyClass::Method(int) __FUNCDNAME__: ?Method@MyClass@@QAGXH@Z */

这些特性在以下场景特别有用：

• 分析导出函数的名称修饰规则
• 调试COM组件调用约定问题
• 逆向工程中识别函数边界

5. C++20的革命：source_location全信息获取

现代C++引入的<source_location>头文件提供了更系统化的解决方案。与之前各方案相比，它具有以下优势：

1. 标准化而非编译器扩展
2. 同时获取文件名、行号、函数名
3. 可通过参数传递位置信息

#include <source_location> void log(const std::string& message, const std::source_location& loc = std::source_location::current()) { std::cout << loc.file_name() << "(" << loc.line() << "): " << loc.function_name() << " - " << message << "\n"; } void test() { log("Hello"); // 输出：main.cpp(15): void test() - Hello }

实际项目中使用时，可以结合编译期检测实现优雅降级：

#if __has_include(<source_location>) #include <source_location> using source_location = std::source_location; #else struct source_location { static constexpr auto current() { return source_location{}; } constexpr auto function_name() const { return ""; } // 其他成员函数的简化实现... }; #endif

6. 性能考量与各方案对比

不同方案的运行时开销差异显著，下表是在x86-64平台上的基准测试结果（纳秒/调用）：

关键发现：

• 优化编译后所有方案开销都大幅降低
• source_location在优化后接近__func__的性能
• 包含复杂信息的宏（如__PRETTY_FUNCTION__）开销较大

注意：在性能敏感的热路径中，建议使用轻量级的__func__或缓存source_location结果。

7. 实战应用：构建智能日志系统

结合多种技术，我们可以实现分级的日志输出系统：

class Logger { public: enum Level { Debug, Info, Warning, Error }; template<typename... Args> static void log(Level level, Args&&... args, const source_location& loc = source_location::current()) { if (level < current_level) return; std::ostringstream oss; (oss << ... << args); std::string prefix; switch(level) { case Debug: prefix = "[DEBUG] "; break; case Error: prefix = "[ERROR] "; break; // 其他级别处理... } std::cout << loc.file_name() << "(" << loc.line() << "): " << prefix << loc.function_name() << " - " << oss.str() << "\n"; } static Level current_level; }; // 使用示例 void processData(int value) { Logger::log(Logger::Debug, "Processing value: ", value); // 输出示例：main.cpp(42): processData - [DEBUG] Processing value: 100 }

在跨平台项目中，可以定义统一的宏来屏蔽编译器差异：

#if defined(_MSC_VER) #define FUNC_NAME __FUNCSIG__ #elif defined(__GNUC__) || defined(__clang__) #define FUNC_NAME __PRETTY_FUNCTION__ #else #define FUNC_NAME __func__ #endif

经过多个大型项目的实践验证，这种组合方案既保持了代码可读性，又提供了丰富的调试信息。当遇到难以复现的边界条件问题时，详细的函数签名信息往往能帮助快速定位问题根源。