Rendered at 22:51:35 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
OneDeuxTriSeiGo 27 minutes ago [-]
Okay so I hate to be that person but I'd really caution against sharing Arthur O'Dwyer's work given that they've been essentially ex-communicated from the C++ community.
LLVM and many conferences want nothing to do with him. gcc and the ISO standards committee still invite him to contribute, although not in a leadership role.
O'Dwyer is a remote consultant on C++. It's like the ideal role for a sex offender since it doesn't require him to go outside or put him in a room alone with others.
I don't think he's ever been accused of rape, sexual abuse, or even harassment since being released from jail. This is remarkable given the ISO C++ committee meetings have a reputation for being drunk, unsafe, and harassing women. Many other members have been credibly accused of harassment.
It's easy to say "remote work is a great idea for sex offenders" but difficult to say "in my profession".
And the object file, look ma, aaa[] is statically allocated:
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 ;........
wewtyflakes 3 hours ago [-]
This is so on-brand for C++, whether that is a blessing or curse is left up to the reader.
randusername 2 hours ago [-]
> Think of constexpr evaluation as taking place "in the compiler’s imagination."
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.
tialaramex 44 minutes ago [-]
The problem isn't so much that you feel like an idiot, at least at the time, but that you may think you're a genius and yet actually what you wrote was nonsense and the C++ compiler was under no obligation to tell you about that, indeed in many cases it's forbidden from doing so.
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.
ok123456 2 hours ago [-]
Would the PMR variants of the STL datatypes be a solution here? The compiler could fill in the details of the range in question (the ro section), and give you constexprness?
Maxatar 2 hours ago [-]
No, compile time memory is not the same as static storage duration/ro section.
ghm2180 3 hours ago [-]
To be clear we are — in the service of speed — trying to bake data into compiled program output binaries, which is ostensibly faster because code-pages in memory when executed by CPU as instructions already have it?
TuxSH 6 minutes ago [-]
The point of the article and of define_static_array is to convert stuff like constexpr std::vector to constexpr std::array.
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
Maxatar 3 hours ago [-]
No you are baking data into the compiled program so that you can perform compile time operations on that data. These compile time operations are most often used to guard against erroneous runtime behaviors.
If all you want to do is bake data into a compiled program, there is the #embed feature added to C++26.
oseityphelysiol 5 hours ago [-]
C++ people are great at making problems for themselves and then solving them to no end.
This does not look like a productive way to get things done.
SuperV1234 3 hours ago [-]
C++ critics are great at analyzing niche corner cases of the language and generalising those to the entirety of its feature set.
This does not look like a productive way to get things done.
kevin_thibedeau 4 hours ago [-]
C arrays are better than this mess. All the problems caused by the intervening generic programming abstraction machinery disappear.
compiler-guy 3 hours ago [-]
The nice thing about C++ is that if you want to use plain old C arrays, you can. And there will be no extra overhead over plain C.
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.
SuperV1234 3 hours ago [-]
Didn't know you could use C arrays to get static compile time reflection, guess C was really ahead of its time!
kevin_thibedeau 50 minutes ago [-]
Wrap them in a class with a consteval constructor.
gkedzierski 4 hours ago [-]
What language do you consider to be productive, in comparison?
htobc 4 hours ago [-]
Rather than engage in an unrelated language-war flame bait, why not actually discuss this particular issue with C++? Yes having a language built around zero cost abstractions for low level programming is a must, but how does that end up justifying this wild complexity around making constexpr more powerful?
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.
SuperV1234 3 hours ago [-]
This particular issue is a niche corner case of C++26 reflection, which -- like reflection in other languages -- is a massively useful feature.
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.
ux266478 2 hours ago [-]
i'd like to point out that C++26's reflection is the third reflection standard defined by the language to cover the "niche corner cases" that have hereto been lacking from the other two (RTTI and type traits).
this specific "niche corner case" also would not exist if C++ did not commit to a poorly-bolted on feature that turned out to be accidentally powerful, and instead intentionally designed powerful metaprogramming facilities from day 1.
there's a point at which "pragmatism" starts being anything but, and it was around C++11 give or take a standard. how on earth do you use it day to day and not feel the schizophrenic non-design being a generalized property across the whole language?
htobc 26 minutes ago [-]
Hey buddy, maybe not liking something is not the same thing as not understanding it? Maybe saying, "this specific feature is bad" is not a generalization to the entire language? Maybe niche corner cases are evidence of poorly chosen primitives and bad design? Maybe jumping straight to smarm and skipping past actually defending the feature means you probably create a work environment no one wants to be in? And an esoteric paradigm like "constexpr two-stepping" that is explained in the article by linking a video that is _over an hour long_ is a perfect example of something that, while perhaps the author and demonstrator explored more for fun instead of as a serious thing to do, would only ever be put into a production code base by the most amateur of architecture astronauts, shortly before their startup fails?
For real though, defend constexpr two-stepping as a real use case for serious people.
https://patricia.no/2022/03/08/cppcon.html
https://patricia.no/2022/03/08/proposed-cppcon_safety__trans...
https://izzys.casa/2024/11/on-safe-cxx/
LLVM and many conferences want nothing to do with him. gcc and the ISO standards committee still invite him to contribute, although not in a leadership role.
O'Dwyer is a remote consultant on C++. It's like the ideal role for a sex offender since it doesn't require him to go outside or put him in a room alone with others.
I don't think he's ever been accused of rape, sexual abuse, or even harassment since being released from jail. This is remarkable given the ISO C++ committee meetings have a reputation for being drunk, unsafe, and harassing women. Many other members have been credibly accused of harassment.
It's easy to say "remote work is a great idea for sex offenders" but difficult to say "in my profession".
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.
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
If all you want to do is bake data into a compiled program, there is the #embed feature added to C++26.
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.
there's a point at which "pragmatism" starts being anything but, and it was around C++11 give or take a standard. how on earth do you use it day to day and not feel the schizophrenic non-design being a generalized property across the whole language?
For real though, defend constexpr two-stepping as a real use case for serious people.