2014-09-13 6 views
4

오류/HRESULT 처리/기록을 정의하는 동안 매크로를 사용하도록 선택하거나 선택하지 않는 이유는 무엇입니까?HRESULT 처리시 매크로를 사용하지 않는 이유는 무엇입니까?

클래스를 호출 할 때 부스트 공유 포인터를 사용할 수 있으므로 인터페이스를 통해 호출되는 오류 처리 클래스가 가까워지고 있습니다. 필요할 때 클래스를 호출 할 수 있습니다. (솔직히 말해서, 그것이 최선의 접근법인지는 모르겠지만, 나는 그것을 할 수 있는지 그리고 어떻게 생겼는지를보고 싶다.) 즉이 :

typedef std::shared_ptr<iErrorHandling> Error_Handler; 

Error_Handler Err_Handler(new ErrHandling); 

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

나는 다이렉트 X와 클래스를 사용하기 시작 및 DirectX는 HRESULT 처리를 많이 필요로 나는 모든 경우/다른 문을 방지하기 위해 매크로를 사용 향해 지적했다. 나는이 건너 온 :

#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."); 

?

+0

Alexander Gessler가 정확합니다. 매크로는 본질적으로 "악"하지 않으며 시나리오는 매크로가 적절하고 도움이되는 좋은 예입니다. – FoggyDay

답변

4

매크로는 본래 나쁘지 않습니다. 그러나 코드를 읽기가 어렵게 만들고 부적절하게 사용하면 디버그 오류가 발생할 수 있습니다. 이러한 이유로 일반 권장 사항은 항상 적은 매크로를 선호합니다. 매크로를 작성한 두 가지 매우 구체적인 경우가 있습니다.

  • __LINE__ 등을 통합하는 로그/추적 매크로는 일반적이며 매크로없이 동일한 효과를 얻는 것은 어렵습니다. IMHO에는 그 (것)들에 관하여 틀린 아무것도 없다.
  • FAILED(hr) 같은 매크로도 꽤 일반적이며 잘못된 내용이나 읽는 법이 없습니다. 대신에 함수를 사용할 수 있으며 오늘날의 컴파일러에서 대부분의 시간에 인라인 될 가능성이 있지만 항상 그렇지는 않습니다. 특히 FAILED은 20 년 동안 COM/DirectX에 포함되어 있으며 사람들은이를 파싱하는 데 익숙합니다.
관련 문제