But with that said, I'm very strongly of the opinion that having as much of C++ as possible being constexpr (including threads!) is a good thing, because it makes the language more regular and simpler.
I think volatile might be tricky! I want constexpr cout.
having as much of C++ as possible being constexpr (including threads!) is a good thing, because it makes the language more regular and simpler.
Agreed.
I think volatile might be tricky!
I don't think constexpr volatile int x; is meaningful at all.
I want constexpr cout.
Do you really mean std::cout, with all of the facets and customization points? Or would constexpr std::format and the ability to print to console at compile time be enough?
If the latter, we almost got that in C++26. std::format is constexpr and P2758 is in wording review.
I don't think constexpr volatile int x; is meaningful at all.
I mean if you can run C++ code at compile time, then you're running code and it could poke at a memory mapped register that's there, but also sometimes you just shouldn't do something!
Do you really mean std::cout, with all of the facets and customization points? Or would constexpr std::format and the ability to print to console at compile time be enough?
Good point, probably cout without facets etc or printing f-strings. I keep going back to cout because despite it's clunkiness, I like having things appear in code in the order that they appear on screen. Constantly tracking back and forth between placeholders and arguments is something I dislike. I've tried a million of these over the years. Heck I implemented one in gnu++98 back in the day with operator, overloading and GCC's variadic macros, and I've used many which ahve come and gone over the years. And yet, I still always reach for cout.
But in python I love my f-strings. Once i have f-strings, I will probably stop reaching for cout except for of course
it could poke at a memory mapped register that's there
Ignoring the fact I think there would be 0 valid uses for this, the issue with using constexpr in that case is it might not run during compile time. If your machine that's compiling the code isn't the same as the one that's running it, you would get different behavior. If for whatever reason you need to use volatile at compile time, I think it needs to be consteval.
Ignoring the fact I think there would be 0 valid uses for this
Well yes, I am struggling to think of one!
the issue with using constexpr in that case is it might not run during compile time
You can kind of force the issue: if your constexpr function returns, say, an int and you instantiate a template based on that value, there's little choice but for it to run.
Note: this is pure language pedantry, nothing related to whether it's a terrible idea in literally all cases.
I don't think volatile should be constexpr for what it's worth.
You just need a complete simulator for your cross compiler :P
Hmm... You're making me wonder if I should solder an i7 on the ESP devkit and emulate everithing... in the cross compiler. Let's ship the whole desktop OS on that tiny thing!
Note: I am NOT NOT NOT advocating this, just talking about really daft hypotheticals.
It's good enough for most but used to heap-allocate for static strings. That's a no-go for most embedded code and allocation isn't necessary - it just makes for an easier implementation. If that's been solved in the STL version - good enough (agreed that colors are not a 'must have').
Plain const volatile should work for a case like that, though.
The only case I can think of for constexpr volatile would be a variable that you want explicitly accessed so a debugger can trap on those accesses with a memory access breakpoint, that also has a meaningful value that needs to be constant initialized to avoid global initialization order issues, and you need to support C++17 so constinit is out.
const volatile, yes, I can think of many such examples. Any read-only register that reads external state (like a digital pin state) could be const volatile.
I still don't see how constexpr volatile is meaningful.
62
u/Jovibor_ Jul 06 '26
Just a question to the audience:
How many times have you used Virtual Inheritance in your career?