wow thanks at minute 12:20 I have understood what I need. I programmed a sql class that creates a string. I wanted to convert it to constexpr, but I failed a lot in allocating dynamic memory at compile time. It's going to be a tough adventure, but now I have the right equipment to succeed.
@@SkegAudio you lose in compilation time, but you gain in not having to compute the values every time the binary runs... in other words, the more you can leave to the compiler to do, the better... you don't pay at runtime for it
@@SkegAudio you forget it exists. it doesn't make any sense *yet* if you are in the "hello world". TLDR: it tells the compiler to arrange the binary layout 😮 assembler code in such a way (reducing/optimizing) that whatever function/s you are calling should, if possible, be transformed into something that returns whatever you expected to first place, by performing the necessary computations at compile time. it's always a trade-off between readability, speed, size and skill.
This is a type of problem I reached while doing things in constexpr, essentially you have to have MAX_LIMITS for oversized array, have a computation run once where you basically compute the size of the result (usually just computing the entire thing) then discard every result and just return the size. Then take the size as a constexpr then again run the computation in an appropriate sized array not to blow up the memory. This caused massive issues for compile times. I reached the same copy twice method for compile-time later, but unfortunately my usecase deemed c++ constexpr interpreter thing too slow. This led me to switch my library to zig comptime. Which has much better semantics than C++ unfortunately for compile time stuff. Not to mention it doesn't color functions as constexpr, it just runs it if possible to run it in comptime.
Meh. That's lame for constexpr. It's still ended up writing a really different code for compile-time and runtime parts of program. Also, why not just when you get a std::string or std::vector get their size and use it? Then the oversize_array is useless and just use an std::array. std::to_array also a great function.
wow thanks at minute 12:20 I have understood what I need. I programmed a sql class that creates a string. I wanted to convert it to constexpr, but I failed a lot in allocating dynamic memory at compile time. It's going to be a tough adventure, but now I have the right equipment to succeed.
39:38 couldn't it work with C++23's `static constexpr operator()` on `Builder`?
If you're looking for code that generates a string at compile time, you definitely need to watch this lecture.👍
just got started with cpp. What's the significance of this feature?
@@SkegAudio Using constexpr string, you can get faster and more predictable code.
@@SkegAudio you lose in compilation time, but you gain in not having to compute the values every time the binary runs... in other words, the more you can leave to the compiler to do, the better... you don't pay at runtime for it
@@SkegAudio you forget it exists. it doesn't make any sense *yet* if you are in the "hello world".
TLDR: it tells the compiler to arrange the binary layout 😮 assembler code in such a way (reducing/optimizing) that whatever function/s you are calling should, if possible, be transformed into something that returns whatever you expected to first place, by performing the necessary computations at compile time. it's always a trade-off between readability, speed, size and skill.
This is a type of problem I reached while doing things in constexpr, essentially you have to have MAX_LIMITS for oversized array, have a computation run once where you basically compute the size of the result (usually just computing the entire thing) then discard every result and just return the size. Then take the size as a constexpr then again run the computation in an appropriate sized array not to blow up the memory. This caused massive issues for compile times. I reached the same copy twice method for compile-time later, but unfortunately my usecase deemed c++ constexpr interpreter thing too slow.
This led me to switch my library to zig comptime. Which has much better semantics than C++ unfortunately for compile time stuff. Not to mention it doesn't color functions as constexpr, it just runs it if possible to run it in comptime.
Is that even true? Zig colors it's functions with the comptime keyword, no?
Meh. That's lame for constexpr. It's still ended up writing a really different code for compile-time and runtime parts of program.
Also, why not just when you get a std::string or std::vector get their size and use it? Then the oversize_array is useless and just use an std::array. std::to_array also a great function.