Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

foonathan.net

Post reply on HN
Print view View original

41–50 of 65 posts

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

#41

Post by inglor_cz »

rualca wrote: post #13
flohofwoe wrote: post #9

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 l…

> 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 langua…

Oh my. Once I spent two hours chasing a bug in my colleague's code (uni, not corp), until I arrived at this gem of his:

#define ZERO 1

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

#42

Post by flohofwoe »

yakubin wrote: post #37
rwmj wrote: post #30

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 solvi…

You can use "if constexpr" for that.

In this case this doesn't work because "if constexpr" parses both branches. If the new library version changes function signatures, the if-branch for the old library version produces an error:

https://www.godbolt.org/z/4KK997

PS: interesting to note that Zig does the "right thing":

https://www.godbolt.org/z/9c13PY

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

#43

Post by rcxdude »

flohofwoe wrote: post #9

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 l…

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.

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

#44

Post by rcxdude »

banachtarski wrote: post #25
flohofwoe wrote: post #9

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 l…

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.

That's only because of #include, however. preprocessing is very fast, it's just because C++ lacks a sane way to import definitions that it dumps a huge amount of text into the frontend of the compiler.

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

#46

Post by scatters »

tkln wrote: post #15
eugene3306 wrote: post #5

Earlier quoted context omitted.

> How can we replace nested comments? you may use multiline string literals

Care to elaborate on how that's supposed work in practice?

Wow, ugly, but it works:

    (void) R"long-comment(
    /* C-style comment */
    std::cout

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

#47

Post by emidln »

banachtarski wrote: post #25
flohofwoe wrote: post #9

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 l…

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.

This doesn't pass the sniff test regarding throughput. I've observed both cc and various linkers take hundreds to thousands of seconds on template-heavy and sometimes not-well-organized c++ on machines running around 4ghz with ddr4, nvme storage, and plenty of both to not be constrained (1TB RAM, 6TB disk). The preprocessor steps barely register in the bazel profile of my repo, compared to places where we hit slot paths in the compiler and linker due to massive mains which are fundamentally separate programs glued together with a switch/case and a read from a config file.

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

#48

Post by scatters »

secondcoming wrote: post #8

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::functio…

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
        M(T C::*e) : p{reinterpret_cast(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...

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

#49

Post by identity0 »

banachtarski wrote: post #25
flohofwoe wrote: post #9

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 l…

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.

I'm not so sure about that. Surely it would take longer to parse both branches of an if-constexpr then it would for the preprocessor to see the #if and discard half of it.

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

#50

Post by sesuximo »

Aardwolf wrote: post #2

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!

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

Post reply on HN