Is the preprocessor still needed in C++? (2017)

[rwmj]

Missing the most important case: Some external library you need changes a function signature and you need to be able to compile against the old or the new library, eg:

  #if LIBVERSION >= 2
    draw_point (2, 3, RED);
  #else
    set_color (RED);
    draw_point (2, 3);
  #endif

This is actually a case where the C preprocessor would be useful in many more languages. OCaml has cppo which is like a better cpp and is very useful for solving these sorts of problems. (https://github.com/ocaml-community/cppo)

[yakubin]

You can use "if constexpr" for that.

[flohofwoe]

TBH the length that C++ goes to replace every single use of the preprocessor "just because" is close to zealotry.

Every single "fix" probably requires more lines of code under the hood than the entire preprocessor and in the end you have added tons of additional features to the language to fix problems that (often) don't need fixing.

The preprocessor being a simple text replacement tool is a feature, not a bug, but like every universal tool it requires some common sense to not abuse it.

[rcxdude]

It would be fine if the preprocessor was actually replaced by something similar in concept, just with the glaring issues fixed like any other macro system devloped recently. But instead there's a bunch of ad-hoc rules trying to cover the things people use the preprocessor for.

[banachtarski]

The reason I don't agree with this is because the preprocessor is the main killer of compiler throughput in a large project, preventing a number of optimizations that would otherwise be possible.

[cmrdporcupine]

Overuse of the preprocessor is perhaps the #1 cause of inscrutable compile error messages.

And certainly doesn't help with compile times.

[imtringued]

The preprocessor is a big roadblock for C++ modules

[suprfsat]

Template instantiation is a simple text replacement tool and it seems to work just fine.

[rualca]

> TBH the length that C++ goes to replace every single use of the preprocessor "just because" is close to zealotry.

This comment is short-sighted.

Take for example C++'s use of include guards to use translation units instead of modules to just compile a damn file. No one in their right mind would argue in favour of a preprocessor with #include instead of proper modules if they were to develop a new programming language.

Using #define to specify constant values is also absolutely awful.

[dig1]

The best thing about C++ preprocessor is that it is dumb. Text goes in, text goes out. Easy to debug, simple rules. Anything I saw as an alternative either requires a significant amount of code, bending C++ rules, or specialized tools to see what is going on.

Java tried so hard to "do the right thing" by abolishing the preprocessor, and we ended up with another preprocessor called IDE, unnecessary code patterns, and (oh my) Maven profiles for conditional compilation (among other things).

[humanrebar]

On the other hand, the preprocessor is so dumb that having a normal variable or enum named "OK" or "STATUS" is a risk, even if all of your dependencies are clean. All it takes is a user to include your header and some header that #defines any name in your header to be something else.

So that means you really need to name your preprocessor symbols (and any other all-caps names, because that's the convention) in ways that probably won't collide. Like MYLIB_OK.

So it starts off dumb, but then you have to start layering on convention and defensive programming immediately. And it complicates entire other features of the language, naming constants and enumerated values especially.

[mhh__]

D has no preprocessor and has none of those problems.

[Aardwolf]

How can we replace nested comments? You can't comment out code that contains /* */ in it except with #if 0

Also, why is std::experimental::source_location loc = std::experimental::source_location::current(); loc.line better than __LINE__? what an unreadable monster that is!

[sesuximo]

Source location is so much more than that macro!!

- it has file name, line number, and char number! That already makes the number of characters more similar if that’s your metric

- it can be forwarded/passed around. It’s much harder to pass macros around

- it can easily capture the caller’s location rather than the location of the macro

[MauranKilom]

Presumably it would become

  auto loc = std::source_location::current();

at some point, which seems fair enough to me.

[mhh__]

The idea is to get the location of the caller without using a macro.

D just uses __LINE__, because it hasn't got a preprocessor so the compiler can resolve the token properly.

The implementation of that is at https://github.com/dlang/dmd/blob/v2.094.2/src/dmd/expressio...

[layer8]

> How can we replace nested comments?

s/^/\/\// (and the reverse) work well for me. It nests.

[eugene3306]

> How can we replace nested comments?

you may use multiline string literals

[secondcoming]

Just yesterday I had to wrap up offsetof in a macro for use in some pseudo-reflection code

    #define MEMBER(C, M) { offsetof(C, M), sizeof(C::M) }

I couldn't figure out nice a way to do this without the preprocessor. The best I came up with was to use a lambda:

    [] (const C& c) { return std::cref(c.m); }

But these are stored in a std::map which means I have to use function pointers or accept the overhead of std::function

[scatters]

Rather than storing the offset within the struct, you could store a type-erased pointer to data member:

    struct M {
        std::byte M::*p;
        std::size_t l;
        template<class C, class T>
        M(T C::*e) : p{reinterpret_cast<std::byte M::*>(e)}, l{sizeof(T)} {}
    };

Also there are ways (not necessarily legal) to convert a pointer to data member to an offset; see the proposal http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p090...

[elitepleb]

We just need an interpreter that can work on C++ files, supported by the standard.

Something akin to the https://www.python.org/dev/peps/pep-0638/

Code generators/transformers are rare only because it's so hard to actually start.

Too bad https://www.circle-lang.org never took off.

[tylerhou]

A few years ago Herb Sutter proposed Python-like metaclasses in C++ through compile-time code generation. Not sure if anything has been proposed for general use.

https://www.youtube.com/watch?v=4AfRAVcThyA

[wwright]

Isn’t that what templates and constexpr are?

[banachtarski]

The preprocessor is still needed to implement a routine that allocates memory on the stack in a cross platform way.

[OneGuy123]

TLDR of the article: the new C++ features can replace some macro usages, but not all.

"With current C++(17), most of the preprocessor use can’t be replaced easily."

"And even then: I think that proper macros, which are part of the compiler and very powerful tools for AST generation, are a useful thing to have. Something like Herb Sutter’s metaclasses, for example. However, I definitely don’t want the primitive text replacement of #define."

[foundry27]

People often voice concerns over the type-safety or performance or flexibility of the preprocessor, arguing that since those all leave something to be desired, the preprocessor should be replaced. I’d like to make a few comments on those points.

First, and perhaps controversially, the preprocessor is type-safe; it just isn’t the same type system that C and C++ use. The syntactic elements that make up the preprocessor language like parentheses, commas, whitespace, hash signs and alphanumeric characters have their own unique types, and can only be used in contexts where those types are expected. You’ll receive an error if your preprocessor program tries to token-paste parentheses, or end function-like macro invocations with whitespace instead of parentheses, or skip commas in macro arguments when they’re expected. It’s important that people stop thinking of the preprocessor as “the thing that turns BIG_ALL_CAPS_CONSTANTS into C code”; the preprocessor it’s its own distinct language, and its purely by coincidence and some nudging by people involved in the early days of C 50 years ago that it happens to have its language interpreter run during the C compilation process.

As far as performance goes, the implementations used by the big three compilers are horrific in terms of memory usage (reaching tens of gigabytes in larger preprocessor programs, nothing ever gets freed) and processing speed (exponential algorithms galore). Clang’s preprocessor still isn’t fully standard-compliant even today. Heck, it took until 2020 for MSVC to get the /Zc:preprocessor flag to enable correct functionality. Twenty years after the last major addition! There’s a lot to be desired with the tools we use, even taking into account the complex macro expansion rules that some faster preprocessors (see: Warp) break to trade functionality for speed. It could be argued that any language that takes that long to get correct (let alone performant) implementations built is worth replacing to get rid of that complexity alone, but it’s worth keeping in mind that what we’re working with today could be much, much better than it is.

Lastly, the crappiness of the preprocessor as a general-purpose code generation language is greatly exaggerated, mostly because it isn’t Turing-complete. Yes, there’s no such thing as direct recursion with macros. But, there is such thing as indirect recursion, where each scan applied by the preprocessor can evaluate a macro again even if it was just evaluated. So, if you can set up a chain of macros that is capable of applying some huge number or scans (2^32, 2^64, whatever), even if that number is finite, it’s enough to do any conceivable code generation task. https://github.com/rofl0r/order-pp/blob/master/doc/notes.txt is the poster child of where that idea gets you; a functional programming language built on the preprocessor that can output any sequence of preprocessing tokens, with high-level language features like closures, lexical scoping, first-class functions, arbitrary precision arithmetic, eval, call/cc, etc.

The preprocessor is still the most powerful metaprogramming and language extension tool available in C++, since it’s the only tool we have to just.. generate code. No necessary reliance on compiler optimization to translate our recursive pattern-matching sfinae’d templates and constexpr functions into the code we expect. Just plain, simple text. I think that’s beautiful, and it’s not something that’s easy to replace.

[GuB-42]

tl;dr: Yes

Despite the author clearly disliking the preprocessor, for justified reasons, most of the article is about how essential it still is.