[HN Gopher] C++26: more constexpr in the core language
___________________________________________________________________
C++26: more constexpr in the core language
Author : jandeboevrie
Score : 48 points
Date : 2025-04-23 19:13 UTC (3 hours ago)
(HTM) web link (www.sandordargo.com)
(TXT) w3m dump (www.sandordargo.com)
| psyclobe wrote:
| That's super cool; c++ is always the sharpest tool in the drawer
| (and by virtue the funnest!)..
|
| It's too bad you still can't cast a char to a uint8_t though in a
| constexpr expression.
| vinkelhake wrote:
| > It's too bad you still can't cast a char to a uint8_t though
| in a constexpr expression.
|
| Uh, what? That has worked fine since the introduction of
| constexpr in C++11.
| TuxSH wrote:
| Maybe they meant reinterpret_cast from/to char to u8, which
| in this case isn't possible in constexpr.
| lbhdc wrote:
| This compiles in clang 21.1.2 with c++26.
| #include <cstdint> #include <print>
| constexpr uint8_t f(char ch) { return
| static_cast<uint8_t>(ch); } int main() {
| constexpr uint8_t r = f('a'); std::print("{}", r);
| }
| Quitschquat wrote:
| It would be cool to have the entire language and runtime
| available at compile-time like in Lisp
| kazinator wrote:
| It would be cool, except for the entire language that is
| available at compile-time being C++, and thus entirely
| unsuitable for manipulating C++ programs.
| gpderetta wrote:
| Yes. It is not like C++ compilers are written in C++.
| klipt wrote:
| Circle C++ does that
| dataflow wrote:
| Could you show some examples?
| chrisrodrigue wrote:
| ...isn't that what templates were made for? Template
| metaprogramming in C++ is Turing-complete.
| pjmlp wrote:
| Not at all, originally template metaprogramming was
| discovered by accident.
|
| Cannot recall any longer if the original article on the
| matter appeared on The C/C++ Users Journal or Dr. Dobbs.
|
| Eventually it started to get abused and the Turing
| completeness has been discovered.
|
| Since C++11, the approach to a more sane way to do
| metaprogramming with templates has been improving.
|
| Instead of tag dispatch, ADL and SFINAE, we can make use of
| concepts, if constexpr/eval/init, type traits, and eventually
| reflection, instead of the old clunky ways.
| jjmarr wrote:
| This already exists with macros, templates, and compiler
| extensions, if you want completely unusable/unreadable code
| that takes forever to build.
| pjmlp wrote:
| Depends on the C++ version.
|
| With C++23 can be made relatively readable, and with the
| right compiler, builds within sensible timeframe.
| jjmarr wrote:
| C++23 doesn't have full reflection yet. That's coming in
| C++26.
|
| I've seen the vast majority of build time in a very large
| C++23 project be taken up by reflection in fmtlib and
| magic_enum because both have to use templates (I think).
| MrRadar wrote:
| The D language basically does that. You can write D programs
| that evaluate D code at compile time to generate strings of new
| D code which you can then basically compile-time eval into your
| code as needed. Combined with the extremely powerful compile-
| time reflection capabilities of D it's the closest thing I've
| seen to Lisp metaprogramming outside of that family of
| languages and it's easier to read than Rust macros or C++
| template metaprogramming.
| veilrap wrote:
| I always like these new comile time features getting into the C++
| spec.
|
| I'm actually looking forward to the related reflection features
| that I think are currently in scope for C++26. I've run into a
| number of places where the combination of reflection and
| constexpr could be really valuable... the current workarounds
| often involving macros, runtime tricks, or both.
| steveklabnik wrote:
| > I'm actually looking forward to the related reflection
| features that I think are currently in scope for C++26.
|
| The core of reflection should be in C++26, yes. In my
| understanding, there's more to do after that as well. We'll see
| when the final meeting is done.
| worik wrote:
| Are they flogging a dead horse?
|
| C++ is, should be, like COBOL. A very important language because
| of the installed base. But why the continual enhancements? Surely
| there are better uses of all those resources?
| MrRadar wrote:
| COBOL is being actively developed as a language, the latest
| standard was published in 2023.
| arjonagelhout wrote:
| Although there are excellent alternatives to C++ such as Rust,
| C++ is still widely used as many open-source and commercial
| codebases are built with it.
|
| Adding features to a language that is still actively used does
| not seem like a bad thing.
| dietr1ch wrote:
| > Are they flogging a dead horse?
|
| Not exactly. There's a lot of C++ code that still can't be
| rewritten into cool languages overnight without risking
| correctness, performance and readability.
|
| I'm always happy to see C++ pushing itself and the compiler
| backends as it benefits the victims of lame codebases and also
| the cool kids using the improved compiler backends.
| jcelerier wrote:
| from which other language can I make a GUI with Qt while doing
| low-level graphics and DSP?
___________________________________________________________________
(page generated 2025-04-23 23:00 UTC)