Barry Revzin
brevzin.github.io · Personal blog · on HN since 2019
Barry Revzin, a C++ standards committee contributor, writes technical posts on C++ features such as reflection, constexpr, and ranges, and compares them with Rust.
What HN saysHN commenters link his posts when discussing C++26 reflection, if constexpr, and his comparison of Rust and C++ formatting.
31HN people shared it
4linked it in comments
56stories submitted
883story points
5 months agolast shared
2019people per year2026
Most-shared posts
- 1Rust vs. C++ Formatting6 people · 5 points · first shared 2023 · 1 comments on HN
- 2Implementing a Struct of Arrays5 people · 138 points · first shared 2025 · 50 comments on HN
- 3Reflecting JSON into C++ Objects4 people · 29 points · first shared 2025 · 5 comments on HN
- 4What's so hard about constexpr allocation?3 people · 84 points · first shared 2024 · 35 comments on HN
- 5The Ignorability of Attributes in C++3 people · 12 points · first shared 2025 · discussion on HN
- 6Code Generation in Rust vs. C++262 people · 134 points · first shared 2024 · 91 comments on HN
- 7C++ : if constexpr isn't broken2 people · 74 points · first shared 2019 · 80 comments on HN
- 8Using Token Sequences to Iterate Ranges2 people · 30 points · first shared 2025 · discussion on HN
- 9Copy-on-Write with Deducing This2 people · 19 points · first shared 2022 · 1 comments on HN
- 10Polymorphic, Defaulted Equality2 people · 5 points · first shared 2025 · discussion on HN
- 11What's so hard about class types as non-type template parameters?2 people · 4 points · first shared 2024 · discussion on HN
- 12The constexpr array size problem2 people · 4 points · first shared 2022 · discussion on HN
- 13Implementing a Better views::split2 people · 3 points · first shared 2020 · discussion on HN
- 14What's the right hash table API?2 people · 2 points · first shared 2023 · discussion on HN
- 15Projections Are Function Adaptors2 people · 2 points · first shared 2022 · discussion on HN
What HN people wrote when they linked it
jevndev · 2026-06-03
For what it’s worth, a common example of the capabilities of c++26 reflection is exactly this use case. I can’t remember where I first saw it, but this article [0] showcases the technique pretty well. It’s opt-in so not the compiler optimization that you’re imagining but still neat that it’s possible
[0] https://brevzin.github.io/c++/2025/05/02/soa/
teleforce · 2021-09-13
It seems that C++ is moving in a full speed following trail-blazed by D language than Bjarne will care to admit:
https://brevzin.github.io/c++/2019/01/15/if-constexpr-isnt-broken/
gavinhoward · 2023-01-17
> What do more experienced people here think of that?
"Experienced" person here. I've done a parser generator grammar or two. I've implemented several parsers.
I mostly agree, but it depends on your use case.
Most people writing parsers are doing so for a bespoke language, usually for config of an internal-use-only program or something like that. Such parsers won't be great, but they will work for people that:
1. Know the language, or
2. Are expected to know the language.
In that case, I agree with Guy Steele.
Why these two caveats? Because as people have said, error reporting from the parser will be subpar. This includes hand-written recursive descent ones. So knowing the language is important.
(The second item is specifically for situations where new employees might not know the language yet, but it's part of their job, so they will learn it.)
This is, by far, the greatest amount of parsers in use. I would estimate 99.5% or more.
Of course, most people don't think about those parsers; they think about the hardened parsers for general-purpose languages in wide use, but while they get a lot of attention, they are few and far between.
Guy Steele's advice doesn't apply as well to such situations. For me, I wrote a parser for an existing language. I had to write the parser to that, and that language had a lot of baggage. It made no sense in that case.
For the parser I'm currently writing, it also makes no sense. This is for what I hope to become a widely-used…
tialaramex · 2023-07-12
Barry Revzin's comparison to what Rust chose here is interesting
https://brevzin.github.io/c++/2023/01/02/rust-cpp-format/
I think Barry under-estimates how long it will be before C++ programmers actually get the equivalent of #[derive(Debug)] and as a result the impact on ergonomics. But of course I might be wrong.