Hacker News Reader

Comment by Ididntdothis | Hacker News Reader

All I can say is that I really miss the preprocessor. There are so many things that could easily be done with the preprocessor but instead have to be done with reflection or code generation in a more complex way.

Sure, it can be be abused/misused but I am not sure that's a good reason to take it away completely like for example in C#.

View on HN

C# has other mechanisms to achieve what macros are commonly used for, though. In a bit, with Roslyn's source generators there will be an even better way for some of them.

One place where preprocessors shine is where the language itself has changed in an incompatible way, where "language" can be interpreted broadly including calls to external libraries. For example some function you need to call added an extra parameter:

  #if LIB_VERSION_GE_3
    lib_f (1, NULL);
  #else
    lib_f (1);
  #endif

It can be difficult to do this with other mechanisms where the compiler is actually compiling and therefore type checking both branches.

OCaml is a pretty rich language with many features, but we fall back on preprocessors like cppo (or even cpp) to deal with these kinds of cases.

You can do that with .NET conditional compilation, no need for the C style macros.

Assuming you mean this: https://docs.microsoft.com/en-us/dotnet/csharp/language-refe... it looks like a restricted form of the C preprocessor. (We may quibble about whether it is separately "pre" processed or not, but even cpp doesn't run as a separate stage in modern C compilers).

The C# preprocessor is unnecessarily restricted. It has a few features but it feels very arbitrary what they include or exclude. I think they didn’t like the idea but couldn’t avoid it totally so they did something half assed. I bet a lot of frameworks that need reflection could be replaced with macros if the preprocessor had a few more features.

It is not half assed, rather what has been proven since the 60's to work properly in all languages that aren't C, nor copy-paste compatible with C.

Even C++ is reducing the need to keep using the pre-processor with each ISO revision, in an ideal modern C++ world without C legacy baggage, the pre-processor will be so half assed like in C#. C++20 is already almost there.

The C pre-processor doesn't have the monopoly on conditional compilation, it wasn't even the first language to support such features, they were already available in Algol variants and Macro Assemblers.

I'm not sure we're disagreeing. My point was that you need something separate from the language to deal with certain language compatibility issues.

Fair enough, but C is the snowflake here, in other languages conditional compilation is part of the language.

Actually even in ISO C, the pre-processor is not required to be separated from the language, it is just kept that way in most compilers due to how C was originally implemented.

No, it does not "shine"

It merely serves to alleviate an issue with a language limitation. And the library writers should have known better than to simply change the signature of an existing call.

(also this example reminds me of all the #ifndef/#define game that headers do which should have been built into the system in the first place)

> And the library writers should have known better than to simply change the signature of an existing call.

I agree, unfortunately they do this and we have to cope with it.

It has a lot of mechanisms but they are usually way more complex with more code. For example when I do data binding in WPF I could write a five line macro that fires change notification events as needed. There are other approaches but they are way more complicated.

Reply on news.ycombinator.com