C# Preprocessor

Question

While the C# spec does include a pre-processor and basic directives (#define, #if, etc), the language does not have the same flexible pre-processor found in languages such as C/C++. I believe the lack of such a flexible pre-processor was a design decision made by Anders Hejlsberg (although, unfortunately, I can't find reference to this now). From experience, this is certainly a good decision, as there were some really terrible un-maintainable macros created back when I was doing a lot of C/C++.

That said, there are a number of scenarios where I could find a slightly more flexible pre-processor to be useful. Code such as the following could be improved by some simple pre-processor directives:

public string MyProperty
{
  get { return _myProperty; }
  set
  {
    if (value != _myProperty)
    {
      _myProperty = value;
      NotifyPropertyChanged("MyProperty");
      // This line above could be improved by replacing the literal string with
      // a pre-processor directive like "#Property", which could be translated
      // to the string value "MyProperty" This new notify call would be as follows:
      // NotifyPropertyChanged(#Property);
    }
  }
}

Would it be a good idea to write a pre-processor to handle extremely simple cases like this? Steve McConnell wrote in Code Complete (p208):

Write your own preprocessor If a language doesn't include a preprocessor, it's fairly easy to write one...

I am torn. It was a design decision to leave such a flexible pre-processor out of C#. However, an author I highly respect mentions it may be ok in some circumstances.

Should I build a C# pre-processor? Is there one available that does the simple things I want to do?

Answer 1

Consider taking a look at an aspect-oriented solution like PostSharp, which injects code after the fact based on custom attributes. It's the opposite of a precompiler but can give you the sort of functionality you're looking for (PropertyChanged notifications etc).

Answer 2

Should I build a C# pre-processor? Is there one available that does the simple things I want to do?

You can always use the C pre-processor -- C# is close enough, syntax-wise. M4 is also an option.

Answer 3

I know a lot of people think short code equals elegant code but that isn't true.

The example you propose is perfectly solved in code, as you have shown so, what do you need a preprocessor directive to? You don't want to "preprocess" your code, you want the compiler to insert some code for you in your properties. It's common code but that's not the purpose of the preprocessor.

With your example, Where do you put the limit? Clearly that satisfies an observer pattern and there's no doubt that will be useful but there are a lot of things that would be useful that are actually done because code provides flexibility where as the preprocessor does not. If you try to implement common patterns through preprocessor directives you'll end with a preprocessor which needs to be as powerful as the language itself. If you want to process your code in a different way the use a preprocessor directive but if you just want a code snippet then find another way because the preprocessor wasn't meant to do that.

Answer 4

Using a C++-style preprocessor, the OP's code could be reduced to this one line:

 OBSERVABLE_PROPERTY(string, MyProperty)

OBSERVABLE_PROPERTY would look more or less like this:

#define OBSERVABLE_PROPERTY(propType, propName) \
private propType _##propName; \
public propType propName \
{ \
  get { return _##propName; } \
  set \
  { \
    if (value != _##propName) \
    { \
      _##propName = value; \
      NotifyPropertyChanged(#propName); \
    } \
  } \
}

If you have 100 properties to deal with, that's ~1,200 lines of code vs. ~100. Which is easier to read and understand? Which is easier to write?

With C#, assuming you cut-and-paste to create each property, that's 8 pastes per property, 800 total. With the macro, no pasting at all. Which is more likely to contain coding errors? Which is easier to change if you have to add e.g. an IsDirty flag?

Macros are not as helpful when there are likely to be custom variations in a significant number of cases.

Like any tool, macros can be abused, and may even be dangerous in the wrong hands. For some programmers, this is a religious issue, and the merits of one approach over another are irrelevant; if that's you, you should avoid macros. For those of us who regularly, skillfully, and safely use extremely sharp tools, macros can offer not only an immediate productivity gain while coding, but downstream as well during debugging and maintenance.

Answer 5

The main argument agaisnt building a pre-rocessor for C# is integration in Visual Studio: it would take a lot of efforts (if at all possible) to get intellisense and the new background compiling to work seamlessly.

Alternatives are to use a Visual Studio productivity plugin like ReSharper or CodeRush. The latter has -to the best of my knowledge- an unmatched templating system and comes with an excellent refactoring tool.

Another thing that could be helpful in solving the exact types of problems you are referring to is an AOP framework like PostSharp.
You can then use custom attributes to add common functionality.

Answer 6

I think you're possibly missing one important part of the problem when implementing the INotifyPropertyChanged. Your consumer needs a way of determining the property name. For this reason you should have your property names defined as constants or static readonly strings, this way the consumer does not have to `guess' the property names. If you used a preprocessor, how would the consumer know what the string name of the property is?

public static string MyPropertyPropertyName
public string MyProperty {
    get { return _myProperty; }
    set {
        if (!String.Equals(value, _myProperty)) {
            _myProperty = value;
            NotifyPropertyChanged(MyPropertyPropertyName);
        }
    }
}

// in the consumer.
private void MyPropertyChangedHandler(object sender,
                                      PropertyChangedEventArgs args) {
    switch (e.PropertyName) {
        case MyClass.MyPropertyPropertyName:
            // Handle property change.
            break;
    }
}

Answer 7

To get the name of the currently executed method, you can look at the stack trace:

public static string GetNameOfCurrentMethod()
{
    // Skip 1 frame (this method call)
    var trace = new System.Diagnostics.StackTrace( 1 );
    var frame = trace.GetFrame( 0 );
    return frame.GetMethod().Name;
}

When you are in a property set method, the name is set_Property.

Using the same technique, you can also query the source file and line/column info.

However, I did not benchmark this, creating the stacktrace object once for every property set might be a too time consuming operation.

Answer 8

At least for the provided scenario, there's a cleaner, type-safe solution than building a pre-processor:

Use generics. Like so:

public static class ObjectExtensions 
{
    public static string PropertyName<TModel, TProperty>( this TModel @this, Expression<Func<TModel, TProperty>> expr )
    {
        Type source = typeof(TModel);
        MemberExpression member = expr.Body as MemberExpression;

        if (member == null)
            throw new ArgumentException(String.Format(
                "Expression '{0}' refers to a method, not a property",
                expr.ToString( )));

        PropertyInfo property = member.Member as PropertyInfo;

        if (property == null)
            throw new ArgumentException(String.Format(
                "Expression '{0}' refers to a field, not a property",
                expr.ToString( )));

        if (source != property.ReflectedType ||
            !source.IsSubclassOf(property.ReflectedType) ||
            !property.ReflectedType.IsAssignableFrom(source))
            throw new ArgumentException(String.Format(
                "Expression '{0}' refers to a property that is not a member of type '{1}'.",
                expr.ToString( ),
                source));

        return property.Name;
    }
}

This can easily be extended to return a PropertyInfo instead, allowing you to get way more stuff than just the name of the property.

Since it's an Extension method, you can use this method on virtually every object.

Also, this is type-safe.
Can't stress that enough.

(I know its an old question, but I found it lacking a practical solution.)

Answer 9

If I were designing the next version of C#, I'd think about each function having an automatically included local variable holding the name of the class and the name of the function. In most cases, the compiler's optimizer would take it out.

I'm not sure there's much of a demand for that sort of thing though.

Answer 10

@Jorge wrote: If you want to process your code in a different way the use a preprocessor directive but if you just want a code snippet then find another way because the preprocessor wasn't meant to do that.

Interesting. I don't really consider a preprocessor to necessarily work this way. In the example provided, I am doing a simple text substitution, which is in-line with the definition of a preprocessor on Wikipedia.

If this isn't the proper use of a preprocessor, what should we call a simple text replacement, which generally needs to occur before a compilation?

Answer 11

Under VS2019, you do get enhanced ability to precompile, without losing intellisense, when using a generator (see https://devblogs.microsoft.com/dotnet/introducing-c-source-generators/).

For example: if you would be in need to remove readonly keywords (useful when manipulating constructors), then your generator could act as a precompiler to remove these keywords at compile time and generate the actual source that is to be compiled instead.

Your original source would then look like the following (the §RegexReplace macro is to be executed by the Generator and subsequently commented out in the generated source):

#if Precompiled || DEBUG
 #if Precompiled
    §RegexReplace("((private|internal|public|protected)( static)?) readonly","$1")
 #endif
 #if !Precompiled && DEBUG
 namespace NotPrecompiled
 {
 #endif

 ... // your code

 #if !Precompiled && DEBUG
 }
 #endif
#endif // Precompiled || DEBUG

The generated source would then have:

#define Precompiled

at the top and the Generator would have executed the other required changes to the source.

During development, you could thus still have intellisense, but the release version would only have the generated code. Care should be taken to never reference the NotPrecompiled namespace anywhere.

Answer 12

While there are plenty of good reflection-based answers here, the most obvious answer is missing and that is to use the compiler, at compile time. Note that the following method has been supported in C# and .NET since .NET 4.5 and C# 5.

The compiler does in fact have some support for obtaining this information, just in a slightly roundabout way, and that is through the CallerMemberNameAttribute attribute. This allows you to get the compiler to inject the name of the member that is calling a method. There are two sibling attributes as well, but I think an example is easier to understand:

Given this simple class:

public static class Code
{
    [MethodImplAttribute(MethodImplOptions.AggressiveInlining | MethodImplOptions.AggressiveOptimization)]
    public static string MemberName([CallerMemberName] string name = null) => name;
    
    [MethodImplAttribute(MethodImplOptions.AggressiveInlining | MethodImplOptions.AggressiveOptimization)]
    public static string FilePath([CallerFilePathAttribute] string filePath = null) => filePath;
    
    [MethodImplAttribute(MethodImplOptions.AggressiveInlining | MethodImplOptions.AggressiveOptimization)]
    public static int LineNumber([CallerLineNumberAttribute] int lineNumber = 0) => lineNumber;
}

of which in the context of this question you actually only need the first method, you can use it like this:

public class Test : INotifyPropertyChanged
{
    private string _myProperty;
    public string MyProperty
    {
        get => _myProperty;
        set
        {
            PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(Code.MemberName()));
            _myProperty = value;
        }
    }
    
    public event PropertyChangedEventHandler PropertyChanged;
}

Now, since this method is only returning the argument back to the caller, chances are that it will be inlined completely which means the actual code at runtime will just grab the string that contains the name of the property.

Example usage:

void Main()
{
    var t = new Test();
    t.PropertyChanged += (s, e) => Console.WriteLine(e.PropertyName);
    
    t.MyProperty = "Test";
}

output:

MyProperty

The property code actually looks like this when decompiled:

IL_0000 ldarg.0 
IL_0001 ldfld   Test.PropertyChanged
IL_0006 dup 
IL_0007 brtrue.s    IL_000C
IL_0009 pop 
IL_000A br.s    IL_0021
IL_000C ldarg.0 

// important bit here
IL_000D ldstr   "MyProperty"
IL_0012 call    Code.MemberName (String)
// important bit here

IL_0017 newobj  PropertyChangedEventArgs..ctor
IL_001C callvirt    PropertyChangedEventHandler.Invoke (Object, PropertyChangedEventArgs)
IL_0021 ldarg.0 
IL_0022 ldarg.1 
IL_0023 stfld   Test._myProperty
IL_0028 ret

Answer 13

If you are ready to ditch C# you might want to check out the Boo language which has incredibly flexible macro support through AST (Abstract Syntax Tree) manipulations. It really is great stuff if you can ditch the C# language.

For more information on Boo see these related questions:

• Non-C++ languages for generative programming?
• https://stackoverflow.com/questions/595593/who-is-using-boo-programming-language
• Boo vs. IronPython
• Good dynamic programming language for .net recommendation
• What can Boo do for you?