   I s a preprocessor a bad thing?
  No new languages I know of have them. #include is replaced by using or import. On the other hand in the source for some commercial projects e.g QUAKE I see alot of defines used for debugging#ifdef DEBUG...#endifand also#ifdef DEMO...#endifso I am wondering how bad it is to do someting like the above. And if it isnt that bad why dot any new languages allow you at least a partial preprocessor? 
  Preprocessors are just flags that tell the compiler whether or not the code should be compile during a build. For example, if you were debugging some code and you had something like:#ifdef DEBUGcerr << " Error in function blah blah"#endifIt simply means that if you compiled in debug mode, youd be able to see the error message, whereas it would be ommitted in a release build (where all bugs have been fixed, theoretically anyway). Preprocessors serve a purpose. However keep in mind that reckless use of preprocessors affects code readability and thus they are often given a negative connotation.The ''new'' languages (like Java and C#) aim more for simplicity than absolute power and flexibility, thus they often choose to exclude assets that are potentially harmful. ;  Of course, you''re neglecting to mention that the preprocessor can also be used for macros, but that''s beside the point.Personally I think carefuly use of the pp is ok in some cases.  I don''t go crazy with my macros or conditional compilation but I do have that baked into logging library so I can compile it out with one pp define...Regards,Jeff ;quote:Original post by psamty10   Preprocessors are just flags that tell the compiler whether or not the code should be compile during a build. hmm... no.Preprocessors are programs that do text substitutions in files based on a number of directives. They are completely independent of the compiler that works on the so processed file. For example, the "C" preprocessor is commonly used for, well, C, C++ and Fortran.#include "foo.txt" literally cuts-and-pastes the file foo.txt into the current file. #define FOO BAR literally replaces all instances of the text token FOO with the token BAR. A non-matching #ifdef/#endif block is, once again, literally excised from the file.The compiler that follows never   sees any of those. It only sees the result. There is nothing stopping you from using C preprocessor directives in a Java or C# file, so long as you actually run the C processor on them before feeding them to your compiler.And you have to remember that a number of language enhancements (e.g. AspectJ) begin their life as preprocessors tacked on other compilers. C++  is no exception in that (CFront preprocessor that converted "C with classes" into C).The trend nowadays is indeed to stay away from the C preprocessors and to have module inclusion directives directly built into the language (using, import ...), specifically because the C preprocessor is dumb, does not respect scopes, etc. This is also why people tell you "macros are evil". Having directives built into the language lets the compiler be actually aware of them, which can improve both error-reporting, and language flexibility (i.e. it lets the compiler do "the right thing").   “Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.”    — Brian W. Kernighan (C programming language co-inventor) [edited by - Fruny on February 13, 2004 1:45:35 AM];  I was referring to their usage in try_catch_this'' original message - their funcionality in an (#ifdef) is basically as a compiler flag. ;  apart from it not being a flag to the compiler its completely true... Because of the scope issues the author of C++ Gotchas surguests using const bools to make the compiler remove blocks of code const bool foo = true;somefunc(){   if(foo)   { // error code here   }}So, in your debugging you make it true and the code gets included (infact, if the compiler is feeling clever it could remove the ''if'' section so the code just drops right throughtIn your release build you set it as false and the compiler should, assuming its half decent, work out that code cant be reached and not include it in the final exe.The book goes on to explain it better, but you get the idea ;  Yeah if you do#ifdef DEBUGprintf("running in debug mode\n");#endifThen this text is removed from your .h/.cpp file before the compiler ever sees it. That makes it vey useful for quickly turning on/off debug information when you implement new functionality in a game (we used it a lot also where I worked as each person had a USER environment var - you could do #ifdef BOB and it would only copmile that code on BOB''s machine).The problem I see is that your code not getting compiled can have errors or become outdated as you change the code it relies on without getting any warnings/errors - when you re-enable the #define it needs suddenly everything goes wrong! ;quote:Original post by psamty10  I was referring to their usage in try_catch_this'' original message - their funcionality in an (#ifdef) is basically as a compiler flag.   No, not really. The compiler never sees them; that was Fruny''s point. They''re not in the file that the compiler uses for input; they''ve been taken out by that point. ;quote:Original post by _the_phantom_    So, in your debugging you make it true and the code gets included (infact, if the compiler is feeling clever it could remove the 'if' section so the code just drops right throughtIn your release build you set it as false and the compiler should, assuming its half decent, work out that code cant be reached and not include it in the final exe.But doesn't that mean you have to manually change the value of "const bool foo" each time you want to switch between compiling the debug and release versions? A nice thing in MSVC++ is that you can define different #defines for different build configurations... e.g. by default the Debug build configuration has _DEBUG defined by default, whereas the release version does not... which means that you don't need to change anything with the code when changing between build configurations if you do this:#ifdef _DEBUGcout << "This is the debug version yo!" << endl;#endif [edited by - SpaceDude on February 13, 2004 12:15:18 PM];  Maybe so, but you are overlooking a major benfit, scoped debugging code in release modeby placing the const bool in a (anon?) namespace, you limit the visibily of it, which means you could do a release mode, with full optermisation, yet still have the code in place to debug your network subsystemMaybe its a bit more inconvient, however the benfits such as that and that the code is ALWAYS syntax checked by the compiler, if even its not included in the output, makes it worth while imo, and i''ll be switching to this system in the near future as i rewrite a project 