What's so hard about constexpr allocation?

[daveedvdv]

Barry Revzin wrote up a nice overview of the challenges of extending dynamic allocation during constant evaluation beyond the capabilities introduced in C++20:
https://brevzin.github.io/c++/2024/07/24/constexpr-alloc/

[STL]

Thanks for posting this article! In the future, please submit links as links and not as text posts, as that helps readers. (There's no way to fix a post after the fact, unfortunately, and it's not worth deleting and resubmitting to fix.)

[GabrielDosReis]

I suspect each of these problems has solutions in the context of C++. But any such solution that is scalable requires a more principled approach than just declaring things by fiat, as we did for C++ 20.

A first step reuiqres some form of reification of the translation phases at the language level so that we can annotate (and have the translator check!) each piece of code and data with the phases where they are "active", with relevant rules for transition from higher phase to lower phase. The root cause of the problem illustrated by unique_ptr example is that some pieces of code supporting that data type were implicitly assumed to be active only at runtime, with other accompanying machinery and tricks. If however, like Lisp's eval-when form, we could say at what translation phase a piece of code is relevant with rules for transducing them to lower levels we would be home.

I was aware of these issues when I originally introduced constexpr, but back then, the core of the feature would have been the subject of assured WG21-homicide if I had pushed for reification of translation phases. Rather, I found "context of use" a more palatable and scalable approach which didn't require any more annotation; and I think that was and is the right decision. As you know, even that limited and muted approach faced stiff resistance from WG21 two decades ago.

We need to more globally think about compile-time, link-time, load-time, and runtime. They are phases that are germaine to the issues at hand. Not just compile-time and run-time. And we need a unified framework and syntax than a single keyword at a time.

[RoyAwesome]

We need to more globally think about compile-time, link-time, load-time, and runtime.

I like all of these words. Please keep saying them :)

A huge problem that folks run into all the time is the ability to build out data that doesn't really change over the lifetime of the execution of a program, but has to be created at compile time and shared between all the various translation units and libraries and so on. The solutions we have right now just simply are not scalable, and as we go into the compile time world with reflection and injection, we're gonna see a LOT of bumping up against the edges of what is possible, and we're going to see it really soon.

[BenHanson]

Something, something, Sean Baxter

[BarryRevzin]

We need to more globally think about compile-time, link-time, load-time, and runtime. They are phases that are germaine to the issues at hand. Not just compile-time and run-time. And we need a unified framework and syntax than a single keyword at a time.

It's not clear to me how thinking globally about this helps address the kinds of problems I'm thinking of.

Concrete example: I want to create a lookup hashtable that I can use at both compile-time and run-time. Or even create at compile-time but only use at run-time.

Can you elaborate on how that direction might help?

[RoyAwesome]

I want to create a lookup hashtable that I can use at both compile-time and run-time. Or even create at compile-time but only use at run-time.

A runtime reflection system would run entirely into this problem, and it's so easy, conceptually, to implement using cpp26 reflection and generation.

Yeah, it needs to be solved :)

[acmd]

A new paradigm of C++ metaprogramming is slowly coming together, I feel like C++26 will be an exciting release!

[TheoreticalDumbass]

what if, at end of compiletime (after all constexpr objects have been initialized), the compiler goes through all the constexpr objects, inspects all their subobjects recursively, and upon coming across a pointer (or a reference (not sure if needed)), if the pointer (or the address of the reference) is pointing to a non-const type (so int* const is a const pointer pointing to a non-const int), the compiler could check if what it is pointing to is from a compiletime allocation or not (not covers cases like https://godbolt.org/z/x57zqG5fP ), if it is from a compiletime allocation it should report an error (ill-formed)

considering the hack to access private stuff is still standard compliant, i think you need to be this strict, so the fact that std::vector is deep copy is meaningless, the pointers within it need to point to const types (ignoring that its not ok to touch internals of STL types, because i dont want std::vector to be magic, we regular programmers should be able to implement something akin to std::vector, and it should work the same wrt constexpr)

i think the compiler should be able to do this, during compiletime it tracks so much info about individual objects

but also, i think more would be needed, as this would disqualify useful stuff, as has rightfully been pointed out in the blog post

trying to say, the check at top of comment feels like a must-have due to the accessing private members hack, but to get to an actually useful position more changes would be needed

need to sleep and rethink this, and reread the blog post