c++ - 为什么要避免在 HRESULT 处理中使用宏？

Question

为什么在定义错误/HRESULT 处理/日志记录时会选择或不选择使用宏？

我正在处理一个通过接口(interface)调用的错误处理类，因此我可以使用 Boost 共享指针在我需要的时间和地点调用该类。 (老实说；我不知道这是否是最好的方法，但我主要想看看我是否能做到，以及它会是什么样子)。即:

typedef std::shared_ptr<iErrorHandling> Error_Handler;

Error_Handler Err_Handler(new ErrHandling);

if (error)
{
    Err_Handler->vDX_ERR(ERR_D3D_INIT_SWAP);
}

我开始在 DirectX 中使用该类，由于 DirectX 需要大量 HRESULT 处理，因此有人指出我使用宏来避免所有 if/else 语句。我遇到了这个:

#define lengthof(rg) (sizeof(rg)/sizeof(*rg))

inline const char* StringFromError(char* szErr, long nSize, long nErr)
{
    _ASSERTE(szErr);
    *szErr = 0;
    DWORD cb = FormatMessageA(FORMAT_MESSAGE_FROM_SYSTEM, 0, nErr, 0, szErr, nSize, 0);
    char szUnk[] = "<unknown>";
    if( !cb && nSize >= lengthof(szUnk) ) lstrcpyA(szErr, szUnk);
    return szErr;
}

inline HRESULT TraceHR(const char* pszFile, long nLine, HRESULT hr)
{
    if( FAILED(hr) )
    {
        char szErr[128];
        char sz[_MAX_PATH + lengthof(szErr) + 64];
        wsprintfA(sz, "%s(%d) : error 0x%x: %s\n", pszFile, nLine, hr,
            StringFromError(szErr, lengthof(szErr), hr));
        OutputDebugStringA(sz);
    }
    return hr;
}

#ifdef _DEBUG
#define TRACEHR(_hr) TraceHR(__FILE__, __LINE__, _hr)
#else
#define TRACEHR(_hr) _hr
#endif

#define HR(ex) { HRESULT _hr = ex; if(FAILED(_hr)) return TRACEHR(_hr), _hr; }

(来自:https://www.sellsbrothers.com/writing/a_young_person.htm)

虽然这对我来说看起来很棒，但我也发现了一些将宏描述为“邪恶”并且应该尽量少用的网站。

哪种方法效果更好，为什么？还有其他方法我还没有发现吗？

此外；使用 __FILE__ __FUNC__ __LINE__ 定义宏来创建错误日志字符串是否有意义，或者定义您自己的特定错误并将它们列在头文件中是否可以接受？

即:

 static LPTSTR ERR_D3D_INIT_HW =        __T("cD3D::Initialize: Failed to establish hardware.");
static LPTSTR ERR_D3D_INIT_SWAP =       __T("cD3D::Initialize: Failed to create the swap device.");

不管这两种方法的实现需要多少时间，哪种方法的性能更好？

Answer 1

宏本身并不是邪恶的。但是，它们往往会使代码难以阅读，如果使用不当，可能会导致难以调试的错误。由于这些原因，一般建议总是支持较少的宏。您提出的是两个非常具体的情况，在这些情况下宏都可以。

• 包含 __LINE__ 等的日志/跟踪宏很常见，如果没有宏，很难(/不可能)达到相同的效果。恕我直言，他们没有任何问题。
• FAILED(hr) 之类的宏也很常见，没有任何错误或难以阅读。您可以改用函数，而对于今天的编译器，它可能会在大部分时间被内联，但情况并非总是如此。 FAILED 特别是 COM/DirectX 的一部分已有 20 年，人们习惯于解析它。