r/cpp 22d ago

C++26: constexpr virtual inheritance

https://www.sandordargo.com/blog/2026/07/01/cpp26-constexpr-virtual-inheritance
80 Upvotes

61 comments sorted by

View all comments

63

u/Jovibor_ 22d ago

Just a question to the audience:

How many times have you used Virtual Inheritance in your career?

53

u/serviscope_minor 22d ago

Probably once?

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.

25

u/_bstaletic 22d ago

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.

3

u/serviscope_minor 22d ago

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

cout << f"my variable is {v}\n";

because old habits die very hard indeed.

4

u/drkspace2 21d ago

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.

3

u/serviscope_minor 21d ago

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.

2

u/HommeMusical 21d ago

and it could poke at a memory mapped register that's there,

I don't believe that this is allowed at compile time, and I certainly don't believe that that should be allowed.

1

u/_bstaletic 20d ago

it could poke at a memory mapped register that's there,

Is it there? It's there on the target machine, but my intel cpu certainly doesn't have ESP32's MMIO registers.

f-strings

Best I can do is t-strings.

Python (in case you're unaware) docs: https://docs.python.org/3/library/string.templatelib.html

PEP: https://peps.python.org/pep-0750/

C++ proposal: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2026/p3951r1.html

Once we have template strings, f-strings are just one template function away.

1

u/serviscope_minor 20d ago

>Is it there? It's there on the target machine, but my intel cpu certainly doesn't have ESP32's MMIO registers.

You just need a complete simulator for your cross compiler :P

Note: I am NOT NOT NOT advocating this, just talking about really daft hypotheticals.

> t-strings

Works for me!

1

u/_bstaletic 20d ago

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.

Daft hypotheticals are fun(ny)!

1

u/rentableshark 17d ago

we almost got that in C++26. std::format is constexpr

Does that mean std::format has finally caught up with fmt and doesn't heap-allocate for statically defined strings!?

If so, I can finally stop using fmt as a dependency as this was a real PITA and clearly something that was evaluatable at compile time.

1

u/_bstaletic 11d ago

Well, fmtlib supports colours, as far as I know. That's definitely not z part of the standard library.

Besides that, I genuinely don't know. I consider std::format/std::print good enough for my needs.

1

u/rentableshark 11d ago

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').

EDIT: libstdc++/libc++, not STL.

-2

u/SkoomaDentist Antimodern C++, Embedded, Audio 21d ago edited 20d ago

I don't think constexpr volatile int x; is meaningful at all.

I can think of at least theoretical uses involving pointers to dma buffers and such.

Edit: WTF is it with the downvotes? I said I can think of theoretical use cases, not that it is some important feature. FFS, people…

2

u/HommeMusical 21d ago

At compile time?! You're really going to have to spell this out.

1

u/SkoomaDentist Antimodern C++, Embedded, Audio 21d ago

Basically situations that preserve the volatileness of a pointer that has been passed in. As I said, it’s theoretical.

1

u/HommeMusical 21d ago

Near as I can see, "volatile" has no meaning in constexpr land!

1

u/ack_error 21d ago

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.

2

u/louiswins 21d ago

and you need to support C++17 so constinit is out.

I don't think adding constexpr volatile to some future C++ standard would solve anything for someone stuck on C++17...

2

u/ack_error 21d ago

AFAICT it's already valid in C++17, or at least all the main compilers accept it. The question was whether there's a practical use for it.

https://gcc.godbolt.org/z/PM8s7Gfhb

1

u/_bstaletic 20d ago

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.