constexpr std::vector<int> f() { return {1,2,3}; }
constinit std::vector<int> p = f(); // error
const(int)[] f() { return [1,2,3]; }
immutable int[] aaa = f();
internal:
db 001h,000h,000h,000h,002h,000h,000h,000h ;........
db 003h,000h,000h,000h,000h,000h,000h,000h ;........
__D5test63aaayAi:
db 003h,000h,000h,000h,000h,000h,000h,000h ;........
db 000h,000h,000h,000h,000h,000h,000h,000h ;........This is a great line.
constexpr and std::execution seem like neat ideas, maybe I'll give them a shot if I build an AI harness around the compiler so it doesn't make me feel like a hopeless idiot for trying new things.
The standard does require that if work was done at compile time the compiler is supposed to tell you if that was nonsense but (a) actually C++ is so complicated your compiler likely has many bugs in this respect and (b) you probably aren't sure the compiler did the work you expected at compile time, knowing all the excuses requires considerable expertise.
If all you want to do is bake data into a compiled program, there is the #embed feature added to C++26.
New (and delete) can be used in constexpr functions, however memory "allocated" like that cannot leave the constexpr "sandbox" so to speak, therefore std::vector cannot be generated at compile-time, but std::array may.
If you are working with fixed-size data like LUTs, just use std::array [1]
[1] Make sure not to use std::to_array when embedding 200KB+ files, as it's a mere constexpr function and not a language construct and will exceed constexpr limits; either specify the size or use a C-style array in this case
This does not look like a productive way to get things done.
This does not look like a productive way to get things done.
You will lose many nice features like fancy strings and easy array resizing (which may or may not be acceptable to you), but you don’t have to pay for it if you don’t use it. (Mostly)
This does seem pretty complicated. And I doubt I will ever use it. But for some the trade off is worth it, and they get to make the choice.
In the real world I would think trying to do any of the things discussed in this article should be an automatic commit rejection on any project.
In the real world, failing to understand what you're reading and eagerly generalising to the entire language should be an automatic hiring rejection in any team.