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.
Anyone else getting concerned about the rate of development of the C++ Standard vs compiler implementation? We don't even have feature complete C++20 on the major compilers yet. C++23 is even less implemented. How will the committee handle this? Will they reduce feature additions at some point in the future?
Maybe knowing where a language is going will help them implement older features? Also, some things are technically easy once all the conceptual wrinkles are ironed out. There is no reason some of these can't be added before C++20 is 100% supported.
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.
> 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 ...
Scala gets pretty close to LISP-level of metaprogramming support between its intrinsic support for macros[0] (not to be confused with the C/C++ preprocessor of the same name), the Scalameta project[1], and libraries such as Shapeless[2].
Not comparing Scala to D, just identifying a language with similar functionality.
Every time I hear about D it sounds awesome. I actually used it to prototype an image collage-composing algorithm which I then rewrote in Scala[1], and the D version might have been nicer to write.
The only reason I didn't write more stuff in D was that the stack traces from my programs were pretty much useless. Maybe I was supposed to set a --better-stack-traces flag when I compiled it or something idk.
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.
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).
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.
Templates are semi-accidentally Turing-complete. They were intended for writing compile-time-generic, run-time-concrete functions and types - but it turned out you could use them, along with the overload resolution mechanisms, to compute things. The Turing-completeness involves recursive use.
Computing things using templates is not intuitive. Many of us have gotten used to it - but that's because that's all we had for many years. It's a different sub-language within C++. As constexpr capabilities widen, we can avoid "tortuted" templates and can just write our compile-time checks and figurings in plain C++ - more or less.
Sometimes, enhanced language features in C++ allow us to actually throw away and forget about other existing features, or at least - complex and brittle idioms using existing features. Like SFINAE :-)
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?
As a specific example, expanding constexpr means a codebase I recently worked on can move away from template metaprogramming magic to something that is more idiomatic. That means iterating on that code will be easier, faster, and less error-prone. I've already done static dispatch using constexpr and type traits that would have taken longer to do with templates.
Currently constexpr programming needs you to know the specifics of what is supported - ideally you'll be able to infer that from first principles of the invariants that are available at compile time. That leads to faster, more confident development.
It's a similar story for reflection: we were using custom scripts and soon won't have to. The changes usually come out of the problems people are already finding solutions for in the real world, rather than gilding a lily.
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.
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.
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.
> 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.
Anyone else getting concerned about the rate of development of the C++ Standard vs compiler implementation? We don't even have feature complete C++20 on the major compilers yet. C++23 is even less implemented. How will the committee handle this? Will they reduce feature additions at some point in the future?
https://en.cppreference.com/w/cpp/compiler_support
Maybe knowing where a language is going will help them implement older features? Also, some things are technically easy once all the conceptual wrinkles are ironed out. There is no reason some of these can't be added before C++20 is 100% supported.
It would be cool to have the entire language and runtime available at compile-time like in Lisp
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.
> 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 ...
Scala gets pretty close to LISP-level of metaprogramming support between its intrinsic support for macros[0] (not to be confused with the C/C++ preprocessor of the same name), the Scalameta project[1], and libraries such as Shapeless[2].
Not comparing Scala to D, just identifying a language with similar functionality.
0 - https://docs.scala-lang.org/scala3/reference/metaprogramming...
1 - https://scalameta.org/
2 - https://github.com/milessabin/shapeless
Every time I hear about D it sounds awesome. I actually used it to prototype an image collage-composing algorithm which I then rewrote in Scala[1], and the D version might have been nicer to write.
The only reason I didn't write more stuff in D was that the stack traces from my programs were pretty much useless. Maybe I was supposed to set a --better-stack-traces flag when I compiled it or something idk.
[1] One of the algorithms used by https://github.com/TOGoS/PicGrid
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.
Yes. It is not like C++ compilers are written in C++.
This already exists with macros, templates, and compiler extensions, if you want completely unusable/unreadable code that takes forever to build.
Depends on the C++ version.
With C++23 can be made relatively readable, and with the right compiler, builds within sensible timeframe.
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).
Maybe too far afield, but: https://leanprover-community.github.io/lean4-metaprogramming...
Gives what you wished for. It's functional, though (among other things). Unlike most lisps, (dependently) typed. But hey, available at compile-time.
Circle C++ does that
Could you show some examples?
...isn't that what templates were made for? Template metaprogramming in C++ is Turing-complete.
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.
“C++ Templates are Turing Complete” by Todd L. Veldhuizen has the history of discovery, early elaboration.
Templates are semi-accidentally Turing-complete. They were intended for writing compile-time-generic, run-time-concrete functions and types - but it turned out you could use them, along with the overload resolution mechanisms, to compute things. The Turing-completeness involves recursive use.
Computing things using templates is not intuitive. Many of us have gotten used to it - but that's because that's all we had for many years. It's a different sub-language within C++. As constexpr capabilities widen, we can avoid "tortuted" templates and can just write our compile-time checks and figurings in plain C++ - more or less.
Sometimes, enhanced language features in C++ allow us to actually throw away and forget about other existing features, or at least - complex and brittle idioms using existing features. Like SFINAE :-)
[dead]
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.
This compiles in clang 21.1.2 with c++26.
> 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.
Maybe they meant reinterpret_cast from/to char to u8, which in this case isn't possible in constexpr.
Why would you need to do that though if you can static_cast?
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?
The resources here are amplified elsewhere.
As a specific example, expanding constexpr means a codebase I recently worked on can move away from template metaprogramming magic to something that is more idiomatic. That means iterating on that code will be easier, faster, and less error-prone. I've already done static dispatch using constexpr and type traits that would have taken longer to do with templates.
Currently constexpr programming needs you to know the specifics of what is supported - ideally you'll be able to infer that from first principles of the invariants that are available at compile time. That leads to faster, more confident development.
It's a similar story for reflection: we were using custom scripts and soon won't have to. The changes usually come out of the problems people are already finding solutions for in the real world, rather than gilding a lily.
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.
COBOL is being actively developed as a language, the latest standard was published in 2023.
> 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.
from which other language can I make a GUI with Qt while doing low-level graphics and DSP?
Why is Qt the only option? Rust has plenty of suitable options. Slint is used in production and works on tiny embedded devices.
Probably zig tbh
Do you like using a fast web browser?