3 ms·

C++ people are great at making problems for themselves and then solving them to no end. This does not look like a productive way to get things done.

kevin_thibedeau 5mo ago
C arrays are better than this mess. All the problems caused by the intervening generic programming abstraction machinery disappear.
- compiler-guy 5mo ago
  The nice thing about C++ is that if you want to use plain old C arrays, you can. And there will be no extra overhead over plain C. You will lose many nice features like fancy strings and easy array resizing (which may or may not be acceptable to you), but you don’t have to pay for it if you don’t use it. (Mostly) This does seem pretty complicated. And I doubt I will ever use it. But for some the trade off is worth it, and they get to make the choice.
- SuperV1234 5mo ago
  Didn't know you could use C arrays to get static compile time reflection, guess C was really ahead of its time!
  - kevin_thibedeau 5mo ago
    Wrap them in a class with a consteval constructor.
gkedzierski 5mo ago
What language do you consider to be productive, in comparison?
- htobc 5mo ago
  Rather than engage in an unrelated language-war flame bait, why not actually discuss this particular issue with C++? Yes having a language built around zero cost abstractions for low level programming is a must, but how does that end up justifying this wild complexity around making constexpr more powerful? In the real world I would think trying to do any of the things discussed in this article should be an automatic commit rejection on any project.
  - SuperV1234 5mo ago
    This particular issue is a niche corner case of C++26 reflection, which -- like reflection in other languages -- is a massively useful feature. In the real world, failing to understand what you're reading and eagerly generalising to the entire language should be an automatic hiring rejection in any team.
    - ux266478 5mo ago
      i'd like to point out that C++26's reflection is the third reflection standard defined by the language to cover the "niche corner cases" that have hereto been lacking from the other two (RTTI and type traits). this specific "niche corner case" also would not exist if C++ did not commit to a poorly-bolted on feature that turned out to be accidentally powerful, and instead intentionally designed powerful metaprogramming facilities from day 1. there's a point at which "pragmatism" starts being anything but, and it was around C++11 give or take a standard. how on earth do you use it day to day and not feel the schizophrenic non-design being a generalized property across the whole language?
    - htobc 5mo ago
      Hey buddy, maybe not liking something is not the same thing as not understanding it? Maybe saying, "this specific feature is bad" is not a generalization to the entire language? Maybe niche corner cases are evidence of poorly chosen primitives and bad design? Maybe jumping straight to smarm and skipping past actually defending the feature means you probably create a work environment no one wants to be in? And an esoteric paradigm like "constexpr two-stepping" that is explained in the article by linking a video that is _over an hour long_ is a perfect example of something that, while perhaps the author and demonstrator explored more for fun instead of as a serious thing to do, would only ever be put into a production code base by the most amateur of architecture astronauts, shortly before their startup fails? For real though, defend constexpr two-stepping as a real use case for serious people. Or did you just get a little bit confused and think the criticism here is actually coming from people who are out of their depth from hearing "compile time optimization" or don't know what reflection is?
SuperV1234 5mo ago
C++ critics are great at analyzing niche corner cases of the language and generalising those to the entirety of its feature set. This does not look like a productive way to get things done.
- imtringued 5mo ago
  It's way less productive to spend significant time on criticizing something you don't use. Better spend that type on niche corner cases than be busy with the entire language.

kevin_thibedeau 5mo ago

C arrays are better than this mess. All the problems caused by the intervening generic programming abstraction machinery disappear.

compiler-guy 5mo ago
The nice thing about C++ is that if you want to use plain old C arrays, you can. And there will be no extra overhead over plain C. You will lose many nice features like fancy strings and easy array resizing (which may or may not be acceptable to you), but you don’t have to pay for it if you don’t use it. (Mostly) This does seem pretty complicated. And I doubt I will ever use it. But for some the trade off is worth it, and they get to make the choice.
SuperV1234 5mo ago
Didn't know you could use C arrays to get static compile time reflection, guess C was really ahead of its time!
- kevin_thibedeau 5mo ago
  Wrap them in a class with a consteval constructor.

gkedzierski 5mo ago

What language do you consider to be productive, in comparison?

htobc 5mo ago
Rather than engage in an unrelated language-war flame bait, why not actually discuss this particular issue with C++? Yes having a language built around zero cost abstractions for low level programming is a must, but how does that end up justifying this wild complexity around making constexpr more powerful? In the real world I would think trying to do any of the things discussed in this article should be an automatic commit rejection on any project.
- SuperV1234 5mo ago
  This particular issue is a niche corner case of C++26 reflection, which -- like reflection in other languages -- is a massively useful feature. In the real world, failing to understand what you're reading and eagerly generalising to the entire language should be an automatic hiring rejection in any team.
  - ux266478 5mo ago
    i'd like to point out that C++26's reflection is the third reflection standard defined by the language to cover the "niche corner cases" that have hereto been lacking from the other two (RTTI and type traits). this specific "niche corner case" also would not exist if C++ did not commit to a poorly-bolted on feature that turned out to be accidentally powerful, and instead intentionally designed powerful metaprogramming facilities from day 1. there's a point at which "pragmatism" starts being anything but, and it was around C++11 give or take a standard. how on earth do you use it day to day and not feel the schizophrenic non-design being a generalized property across the whole language?
  - htobc 5mo ago
    Hey buddy, maybe not liking something is not the same thing as not understanding it? Maybe saying, "this specific feature is bad" is not a generalization to the entire language? Maybe niche corner cases are evidence of poorly chosen primitives and bad design? Maybe jumping straight to smarm and skipping past actually defending the feature means you probably create a work environment no one wants to be in? And an esoteric paradigm like "constexpr two-stepping" that is explained in the article by linking a video that is _over an hour long_ is a perfect example of something that, while perhaps the author and demonstrator explored more for fun instead of as a serious thing to do, would only ever be put into a production code base by the most amateur of architecture astronauts, shortly before their startup fails? For real though, defend constexpr two-stepping as a real use case for serious people. Or did you just get a little bit confused and think the criticism here is actually coming from people who are out of their depth from hearing "compile time optimization" or don't know what reflection is?

SuperV1234 5mo ago

C++ critics are great at analyzing niche corner cases of the language and generalising those to the entirety of its feature set. This does not look like a productive way to get things done.

imtringued 5mo ago
It's way less productive to spend significant time on criticizing something you don't use. Better spend that type on niche corner cases than be busy with the entire language.