6 ms·
So much of modern c++ is trying to get around just using the preprocessor.
by shadowgovt 3y ago
So much of modern c++ is trying to get around just using the preprocessor.
- gumby 3y agoThe preprocessor is such a botch (charitably, state of the art 1975). As Stroustrup said to me once in a discussion on the topic, "Once an ecological niche has been colonized it's almost impossible to clean up, so you have to work around it."
- shadowgovt 3y agoYeah, but they're trying to replace it with more botch. "If constexpr can be used to precompute statically-determinable logic, except except except..."
- ok123456 3y agoConstexpr can replace most per-processor macros in a subset of C++. This is a huge improvement over preprocessor macros and functions which are very difficult to refactor. Even if it turns out to be 'botch', we can reason about the 'botch' and find ways to mitigate problems with it through static analysis.
- Warwolt 3y agoAnd for good reason?
- WalterBright 3y agoC++ should finish the job and deprecate the preprocessor.
- gpderetta 3y agoModules get rid of includes and includes guards. Unfortunately the preprocessor is still needed for stringyfication and other symbol manipulation. C++26 (2126 of course) will introduce enough reflection to finally get rid of the preprocessor.
- WalterBright 3y agoI added enough to D that it didn't need a preprocessor, yet could do all those things.
- shadowgovt 3y agoI really need to get around to looking into D.
- FpUser 3y agoWhen D showed up I really wanted it to become mainstream language. Unfortunately it did not.
- WalterBright 3y agoDoesn't mean you can't use it. Lots of people do.
- pjmlp 3y agoIt does, because many delivery projects chose languages based on the product SDKs, so if it isn't in the box, they don't come into the discussion at all. Also in the meantime, most of the cool stuff in D is showing up on the languages that come on those SDKs (C++, Java, C#), weakening the argument to look outside of SDK supported languages. Doesn't matter if D had it first, or if it has a better implementation, worse is better, when ecosystem, tooling, IDE and technical support are part of the equation. So it remains a language for hobby coding.
- paulddraper 3y ago> So much of modern c++ is trying to get around just using the preprocessor. ...and that's a good thing
- shadowgovt 3y agoWe already have the preprocessor, and additional abstractions carry more than linear cost. I'm dissatisfied with these half-measure patches on static-time code evaluation.
- paulddraper 3y agoWhat makes them half measures and not full measures?
- shadowgovt 3y agoMostly the fact that the preprocessor doesn't go away. I still need it for the include system, I still need it for string interpolation, the file and line macros...
- csb6 3y ago> I still need it for the include system The goal is to get rid of this using C++20 modules (and potentially reduce compile times due to repeated expansion of header files). > the file and line macros This is addressed by C++20's std::source_location [0] > I still need it for string interpolation If you mean the `#` macro operator, then yeah that is still needed. The point is to provide ways of doing these tasks that don't require a weird text replacement macro language and instead do them with C++. Obviously due to legacy codebases the preprocessor is going to stick around. [0] https://en.cppreference.com/w/cpp/utility/source_location https://en.cppreference.com/w/cpp/utility/source_location
- shadowgovt 3y agoYes. My biggest frustration with c++ as a language is that there are often two ways to do things: the right way, and the way you will find in tutorials and codebases because the right way didn't exist yet when they were written. This means the cognitive load to use the language in any context that isn't "greenfield project with experts" is significant relative to other languages.