Stupid Question 52: What are preprocessor directives? (In c#)

Unfortunately I also don't have a link, but some historic information (just what pops into my mind).
the preprocessors have been around for a long time. The first time I personally saw them was in the early 90s working with C, later C++.

They basically help you controlling which parts of your code are going to be compiled. Maybe you could call it conditional compilation of your code. Often used to share code amongst platforms with small differences in code required.

Hope I didn't confuse more than explain ;) 

Hello, Iris) As I know, probably, the most used scenario is so-called "conditional compilation". For example, at my previous job, we had some third-party component, which most of the team didn't work with, and so, parts of code that use that component were under some #if use_component and so on. So, the most of the developers could build the project without that component. It is useful sometimes, but, as for me, there are also some great problems with that. With all these conditions a lot of chaos could be created, when you are not able to see clearly, what parts of code will be compiled now and what will be excluded. So, I would be very careful with that.
For the alternative Debug scenario, I think, you could check these articles: Conditional Methods Tutorial, The Conditional attribute.
Good luck! 

They're actually quite useful in a variety of ways.

You can output #warnings during compilation to the IDE output window (and the  IDE Error List) e.g:
#warning You've done something really hacky here!

Or consider throwing a not implemented exception at runtime. Well the equivalent at compile time (which will halt compilation) would be:
#if !MY_SYMBOL
#error Compilation outside of debug
#endif

Then there is ignoring warnings that you are aware of (and want to ignore in an attempt to get to 0 warnings by fixing those you can, and accepting those you can't)
#pragma warning disable 414, 3021
[CLSCompliant(false)]
public class C
{
   ...
}
#pragma warning restore 3021
[CLSCompliant(false)]  // CS3021
public class D
{
   ...
}


A list of warnings codes can be found here: http://msdn.microsoft.com/en-us/library/ms228296%28v=VS.90%29.aspx


I use #if #else directives sometimes when refactoring code when I don't want to create a new branch, or I want different behaviour from compilation symbols. Like, for example, to prevent any caching while debugging, or some other condition.

#if STRONGER_CACHING
Dictionary cache = new Dictionary();
#endif

public object MyMethod(string key)
{
  object value = null;
#if STRONGER_CACHING
    if(!cache.TryGetValue(key, out value))
        cache[key] = value = //...get from data store
#else
    value = //...get from data store
#endif
  return value;
}
 

We call them build flags at my work, as they only do stuff depending on the build configuration (e.g debug)

And example where we have had to use these in the past is to handle some horribly written libraries from ComponentOne where the win-forms and web-forms dlls had exactly the same namespaces that would cause ambiguous name referencing. So when building a shared dll under a win-forms configuration, we used build flags to point to a correct wrapper class.

It was extremely horrible and we walked away from those libraries as soon as we could. 

Hi, 

First of all, thank you for all your posts they are great!!! (answers from people toooo :p)

For the preprocessor directives I have examples... with the "#if DEBUG". My software is protected by a hardware key. 
So if I don't pluged my key into the computer than my software will stop. In development mode, this is a pain in the ass!!! 
It's also really usefull in debug mode to go where the application crash (yes sometime it crash...) but for user you want a nice error message... so here is how I start my app:


	    var haveToCheckHardwareKey = true; 
#if DEBUG    
            haveToCheckHardwareKey = false;
            Application.Run(new Screen.Principale(haveToCheckHardwareKey));
#else
            try
            {
                Application.Run(new Screen.Principale(haveToCheckkey));
            }
            catch (Exception ex)
            {
                MessageBox.Show("Sorry... blablabla...", "Error");
            }
#endif


//JYC 

I've used them in the past when writing libraries that build both Windows and Silverlight versions. As Silverlight only supports a subset of .NET you sometimes need to code things differently and can take advantage of the fact that SILVERLIGHT is defined for Silverlight projects. So you end up with code like


#if SILVERLIGHT
  // Silverlight specific code
#else
  // normal code
#endif


Depending on which project is being built you get the correct code for it. 

In C and C++ the preprocessor is  much more powerful than it is in C#.  You could use it to write "macros" which look like functions, but are handled by simple text substitution:

#define square(x) (x*x)

int twentyfive = square(5);

Now, in the early days, there was four distinct steps in compiling C code : Preprocessor, compiler,  assembler, linking.

The preprocessor , as it's name implies, runs first, and handles the directive.  The output of the above would be :

int twentyfive = (5*5);

The preprocessor knows nothing about the syntax of C, and could actually be used on non-C/C++ text files.

The compiler, in those days, would output assembler code (as a text file). The assember would create the actual binary output.  The linker merges in external libraries.  (The C# compiler blurs these steps together).

Preprocessor macros were always a problem, since they don't follow scoping and naming rules, and are just simple text substitution.  If you used the above macro like this:

int xyxy = square(x+y);

and you'll get:

in xyxy = (x+y*x+y);

which is not the value I'd expect.  In fact, you could write:
char* shello = square("Hello");

which will happily give you 

char* shello = ("Hello" * "Hello");

which is just a syntax error. 

Right, I used to use macros like that in C quite a bit. They were a bit like C# generic methods but not as safe, as you mention.