Redefining DEBUG

I'm building a library that was originally written to be compiled with gcc (I'm using MSVC). Most of the functions look something like this:-

Code:

---

void the_function_name ()
{
  assert ( <whatever> );

  if (DEBUG (BUFFER)) {
    // Dump some Debug information
  }

  // Rest of the function
}

---

I looked through the header files and discovered that one of them re-defines DEBUG - like so:-

Code:

---

#define DEBUG_LEVEL(WHAT, LEVEL) (_hb_debug ((LEVEL), HB_DEBUG_##WHAT))
#define DEBUG(WHAT) (DEBUG_LEVEL (WHAT, 0))

---

If I build a Debug version I see the expected warning from MSVC:-

Quote:

---

warning C4005: 'DEBUG' : macro redefinition

---

That in itself doesn't worry me unduly. What worries me more is that there's no guard around the above re-definition. So I'm worried in case DEBUG will now be defined for my Release builds as well as my Debug builds. I contacted the author who said that this won't happen because the compiler will optimize everything away when building a Release version. Does anyone know if that's true, either for gcc or MSVC?

Can't you circumvent the name conflict problem by simply referring to _DEBUG rather than DEBUG in your own code?

For my own code I probably could but I'm more concerned about existing header files (i.e. someone else's files) which might be conditionally including stuff, depending on whether DEBUG is or isn't defined. They probably won't have been written with the assumption that one particular module will define DEBUG - even when all the others don't.

Of course, if the author's correct (in saying that the compiler itself will optimize his macros away) then I'm worrying unnecessarily - but I'm not really sure if that's true.

Actually, http://msdn.microsoft.com/en-us/libr...v=vs.100).aspx doesn't list DEBUG (and, to my surprise, not even NDEBUG), so apparently it's neither standard nor documented MS-specific. (_DEBUG is listed, but it's MS-specific and not compromised here at all.) I'd say 3rd party code making any assumptions about non-standard undocumented macros they didn't define themself rather is their problem... ;)

Quote:

---

Originally Posted by John E

Of course, if the author's correct (in saying that the compiler itself will optimize his macros away) then I'm worrying unnecessarily - but I'm not really sure if that's true.

---

As Eri523 pointed out, the author's mistake is to use names such as "DEBUG" for the macro. Using such a common name is begging for a name clash to occur somewhere.

If anything, a name such as LIBRARYNAME_DEBUG, where "LIBRARYNAME" is the name of the library would have been better suited.

Regards,

Paul McKenzie