0

could anyone define what is a STRAY DEFINITION? .the second questionis: I'm reading "Teach yourself c++ in 21 days" in the book he said we should not define the term DEBUG. I want to know why?

ProDev7
  • 75
  • 7
  • 6
    You should probably read your book. – progrenhard Aug 29 '13 at 23:33
  • 1
    There's nothing wrong with `DEBUG` as far as I know. You want to stay away from identifiers that start with underscores, though. They're reserved for use by the implementation in various ways, so you might step on something's toes doing that. – Carl Norum Aug 29 '13 at 23:35
  • People often use `DEBUG` as a flag to indicate debug-mode; there may be preprocessor conditionals in other people's code that say "if `DEBUG` is defined, then spit out a lot of diagnostic information". So it's not something you'd want to turn on unintentionally. – Beta Aug 29 '13 at 23:41
  • but you didn't explained STRAY DEFINITION. would you? – ProDev7 Aug 29 '13 at 23:41
  • I'm not familiar with `STRAY DEFINITION`. I don't recall ever hearing the term before. – Beta Aug 29 '13 at 23:42
  • 1
    Doesn't MSVC (Visual Studio) use `-DDEBUG` when building in debug mode? Though that may not be a big problem if you want your debug code to be compiled into your program when it is compiled for debug. – Jonathan Leffler Aug 29 '13 at 23:43
  • 1
    When using C++, stay away from `#define`s as much as possible. Check out http://stackoverflow.com/questions/1637332/static-const-vs-define – franji1 Aug 30 '13 at 00:06

1 Answers1

7

First part of the question:

A stray definition is a preprocessor definition that changes the behavior of some other code (or the actual code), which most likely won't be intentional. For example, you could write a header file and use the following line:

#define main is_awesome

This won't have any direct impact in your header file, possibly not even in your code, but someone else including this header file in a file containing the function int main(int argc, char **argv) will run into problems, because this stray definition will change that function's name into int is_awesome(int argc, char **argv) and suddenly there is no longer a main entry point for the application!

In a similar way the macro DEBUG can cause such problems. Typically, DEBUG should only be defined by the compiler itself, based on whether it's building debug code or not (based on your compiler you might have to set it yourself as well). If you're defining DEBUG somewhere on your own, you might trigger debug code even though you're actually creating a release build.

In general, such bugs or issues can be really hard to track down, especially if you don't know how to have a look at the preprocessed code (you can't see the problems/errors in your base code and most likely line numbers reported will be off as well).

How to avoid this? Three simple rules that will make your life and that of others a lot easier:

  • Only use preprocessor definitions when you really have to (e.g. to control code inclusion at compile time).
  • Always clean up (#undef) preprocessor definition you don't need outside your header file.
  • If you have to use some global preprocessor definition, make it's name unique, e.g. by prepending your library or project name. E.g. rather than defining DEBUG you could use MYLIB_DEBUG.
Mario
  • 35,726
  • 5
  • 62
  • 78