3 ms·

We already have the preprocessor, and additional abstractions carry more than linear cost. I'm dissatisfied with these half-measure patches on static-time code

We 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 ago
What makes them half measures and not full measures?
- shadowgovt 3y ago
  Mostly 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 ago
      Yes. 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.
  - paulddraper 3y ago
    constexpr is pretty different then include and line number (which are addressed by other features). IDK what to say....a 40+ year old language has some warts and it has old code using those warts. Doesn't mean you have to be stuck actually using them forever and ever
    - shadowgovt 3y ago
      > Doesn't mean you have to be stuck actually using them forever and ever If I'm writing new code, probably not. But since it's a 40+ year old language, I'm doing more comprehension, maintenance, and extension of old code than writing new, and every new feature makes that task harder over time.

We 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 ago

What makes them half measures and not full measures?

shadowgovt 3y ago
Mostly 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 ago
    Yes. 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.
- paulddraper 3y ago
  constexpr is pretty different then include and line number (which are addressed by other features). IDK what to say....a 40+ year old language has some warts and it has old code using those warts. Doesn't mean you have to be stuck actually using them forever and ever
  - shadowgovt 3y ago
    > Doesn't mean you have to be stuck actually using them forever and ever If I'm writing new code, probably not. But since it's a 40+ year old language, I'm doing more comprehension, maintenance, and extension of old code than writing new, and every new feature makes that task harder over time.