C++ Weekly - Ep 432 - Why constexpr Matters
Vložit
- čas přidán 9. 06. 2024
- ☟☟ Awesome T-Shirts! Sponsors! Books! ☟☟
Upcoming Workshop: Understanding Object Lifetime, C++ On Sea, July 2, 2024
► cpponsea.uk/2024/sessions/und...
Upcoming Workshop: C++ Best Practices, NDC TechTown, Sept 9-10, 2024
► ndctechtown.com/workshops/c-b...
Upcoming Workshop: Applied constexpr: The Power of Compile-Time Resources, C++ Under The Sea, October 10, 2024
► cppunderthesea.nl/workshops/
CLion is a cross-platform JetBrains IDE for C and C++ with:
- A smart C and C++ editor to navigate and maintain your code base productively.
- Code analysis with quick-fixes to identify and fix bugs and style inconsistencies.
- An integrated debugger - along with other essential tools from the ecosystem - available
straight out of the box.
- And much more!
jb.gg/clion_ide code: CppWeeklyCLion
Episode details: github.com/lefticus/cpp_weekl...
T-SHIRTS AVAILABLE!
► The best C++ T-Shirts anywhere! my-store-d16a2f.creator-sprin...
WANT MORE JASON?
► My Training Classes: emptycrate.com/training.html
► Follow me on twitter: / lefticus
SUPPORT THE CHANNEL
► Patreon: / lefticus
► Github Sponsors: github.com/sponsors/lefticus
► Paypal Donation: www.paypal.com/donate/?hosted...
GET INVOLVED
► Video Idea List: github.com/lefticus/cpp_weekl...
JASON'S BOOKS
► C++23 Best Practices
Leanpub Ebook: leanpub.com/cpp23_best_practi...
► C++ Best Practices
Amazon Paperback: amzn.to/3wpAU3Z
Leanpub Ebook: leanpub.com/cppbestpractices
JASON'S PUZZLE BOOKS
► Object Lifetime Puzzlers Book 1
Amazon Paperback: amzn.to/3g6Ervj
Leanpub Ebook: leanpub.com/objectlifetimepuz...
► Object Lifetime Puzzlers Book 2
Amazon Paperback: amzn.to/3whdUDU
Leanpub Ebook: leanpub.com/objectlifetimepuz...
► Object Lifetime Puzzlers Book 3
Leanpub Ebook: leanpub.com/objectlifetimepuz...
► Copy and Reference Puzzlers Book 1
Amazon Paperback: amzn.to/3g7ZVb9
Leanpub Ebook: leanpub.com/copyandreferencep...
► Copy and Reference Puzzlers Book 2
Amazon Paperback: amzn.to/3X1LOIx
Leanpub Ebook: leanpub.com/copyandreferencep...
► Copy and Reference Puzzlers Book 3
Leanpub Ebook: leanpub.com/copyandreferencep...
► OpCode Puzzlers Book 1
Amazon Paperback: amzn.to/3KCNJg6
Leanpub Ebook: leanpub.com/opcodepuzzlers_book1
RECOMMENDED BOOKS
► Bjarne Stroustrup's A Tour of C++ (now with C++20/23!): amzn.to/3X4Wypr
AWESOME PROJECTS
► The C++ Starter Project - Gets you started with Best Practices Quickly - github.com/cpp-best-practices...
► C++ Best Practices Forkable Coding Standards - github.com/cpp-best-practices...
O'Reilly VIDEOS
► Inheritance and Polymorphism in C++ - www.oreilly.com/library/view/...
► Learning C++ Best Practices - www.oreilly.com/library/view/... - Věda a technologie
Most C++ code can be divided on the basis of "computation" and "I/O or interfacing with the system". In modern C++ (post C++20) all "computation" code should be constexpr so it can be reused, if needed, for compile time computation. C++ has become flexible enough for that to be feasible.
I remember when i was first learning programming in college, we were writing java and implementing comparable on classes. I always found it odd that we wrote this generic comparison function which required testing for castability using the 'instanceof' keyword and then casting to use the class's respective .equals function. C++ is the first and only language I know of that allows the programmer to do all of this at compile time rather than runtime. some languages might have had done this when compiling, but c++ let's the programmer have that control. That alone, for me, makes constexpr (and extensions like if constexpr and consteval) an incredibly cool feature.
In general best single contained illustration on when constexpr matters is when it removes magic numbers
sqrt(2) is always better for maintenance than 1.414.....
if sqrt is constexpr then it also comes for free at execution and people who will have to maintain your code will thank you for that as your intent is then much more explicit
Unfortunately I don't think we have the float/double constexpr math functions yet in the standard library.
@@TsvetanDimitrov1976But float/double constexpr sqrt's do exist, even if they're not in the standard libraries, and the benefit to code readability is probably worth the slightly increased compilation times that a dedicated consteval Newton-Raphson implementation would entail.
That's basically what I use it for. In place of the "#defines". I haven't found much use for it otherwise. I could imagine using it for generating CRC tables at compile time.
I predict that a science will arise to help us structure our programs to best take advantage of compile-time processing. This video portrays the problem as the first few steps of some programming task can be done at compile time with the rest done at run time. This order reflects that of the final version of your code for obvious reasons: compile time comes before run time. However, the program as initially conceived by the programmer may not have this order. The ability to do some of a task at compile time should affect how one structures their code. We need patterns for taking advantage of constexpr.
A cool use case for `constexpr` that could be really useful and can showcase reasoning behind `constexpr`. Imagine using `constexpr` to create regular expressions from compile-time strings. This way, the regex can be compiled and validated at compile-time, ensuring it's correct and efficient. Then, you can use this pre-compiled regex during runtime for high-performance string matching operations. This method not only boosts performance but also catches errors early in the development process.
This is exactly what the CTRE library does :)
@@coder2k I know that there are already libraries that use this technique. It just seems to me that this example of usage is more illustrative and easier to understand. Jason provided a more abstract example, which is harder to grasp.
@@smidimir Totally agree!
@@coder2k Gee, I thought I was providing the example that was more relatable, like "how do I apply this to *my* project"
Thanks a lot for the video!
It'll be very interesting to know whether there are some compiler flags that allow to increase the threshold of the compiler being able to do more stuff at compile time that is not specifically labled constexpr-like.
This will also allow some diagnostics or recommendation from the compiler to guide it with constexpr or consteval keywords for that kind of scenarios
I think to say it matters you have to show an example of where it will actually provide a computing advantage. Anything under a trivial amount can most likely be computed on an out of order processor faster than it can be loaded from memory. Anything over a trivial amount is likely to alter the operation enough to affect runtime performance. I've studied heavy compute projects (rendering, video encoding, etc) and they are almost devoid of it. If it is such a panacea, why isn't it everywhere in compute?
- Code to compute something is often larger than the result. It can also depend on operands that are same size or larger than the result. The code and operands must be loaded from memory aswell.
- There are many reasons why constexpr functions might not be used: SIMD intrinsics won't work in constexpr context, project might want to support older C++, code author might not know better...
@@fl4shi238 The point of the video is you have a wide range of values, most of which cannot be known at runtime. Unless you do a regression on the dataset, you're just picking out a few outliers that could or could not be statistically relevant. For the most part the compiler is smarter than all of us, telling it to always precompute values regardless of outcome seems counter intuitive.
Best is for creating cache at compile time, like in one parser I need map `char` to `isDig`, `isAlpha` etc. we can check it by `'a'
you can still throw in constexpr, if you don't expect to catch the exception (which is impossible) You probably don't want to generate "invalid" constexpr result
I've always thought that a language system should do as much computation as it can at build time. In fact, this is the basis of most compiler optimization. What bothers me about C++'s approach to compile time processing is that the programmer has to ask for it explicitly using constexpr and the like. The default should be that the build system does it for you when it can. The programmer should only have to worry about it if they don't want the default behavior or simply want to check that the system is doing what they think it is doing.
The compiler is free to optimize as much as it wants without introducing undefined behavior. It's just with things such as consteval you are forced into writing your code in a way that can be optimized away
@@__Brandon__ In my perfect language, everything that can be done at compile time is done at compile time. Hints are needed only if that behavior isn't what the programmer wants.
@@PaulTopping1 I completely agree. While there are certainly circumstances where the compiler doesn't have a chance to figure it out, think of restrict in library functions in C, in cases like what Jason shows in the video, the compiler should be able to figure it out on its own, with the only caveat being that it's computationally intensive enough to require enabling optimizations at the command line with -O3. However, I think that the hint word should just be const, and the keywords consteval and constexpr should never have existed, but the potential for breaking code made everyone skittish on that front.
@@PaulTopping1 and the compiler is free to do that, but a something very trivial can make it impossible to do a calculation at compile time and consteval is a keyword that flags all the trivial things so guarantee that you don't introduce anything that will stop compile time computations. You need to have a way of asserting that it is actually being done at compile time, or a way of opting into running at runtime. You have to make on the default to fallback on and then you can optionally choose to allow the other one to be an error. Otherwise how is the compiler supposed to know if you made a mistake or if you were writing code for runtime when you meant compile time.
@@__Brandon__ Let me give you an example. The latest C++ versions provide compile-time compilation of std::format constructs. However, if one provides a custom formatting class, one has to make its methods explicitly constexpr. Instead, I would prefer the compiler to just figure out that my methods can be run at compile time without me having to say so. Right now, this is not too much of a burden but I suspect it is going to get much worse as the standard library gets updated to be constexpr-friendly. We'll end up having to sprinkle constexpr all over code that uses stdlib. I would instead prefer that we only have to specify what we don't want to run at compile time.
In your example the compile time limitation was the number of operations, but all the information was available in compile time. what if the input string of the parser was given via argv, or via socket, or a file, like in the real world. moreover when you write unit tests for the parser, you supply it a compile time input, while in 'production' environment the input wont be available. it creates a scenario when the unit tests run in compile time while the important code in productions does the job in run time. the unit test wont actually test the same operation. if the code doesn't support constexpr, the unit test more likely simulate the production environment even though the input examples will be available in compile time.
This is why all of my unit tests are compiled twice - once with constexpr and once without. this is a Best Practice I have published and also what my example projects show.
Hello Json, thanks for the videos. Can you please make a videos on pimpling a variadic templated class ?
That's not really possible. You'd have to pick the exact number and types of parameters you want to expose, unless you want to wrap all parameters in a vector of any or something
3, 2, 1 and 0 are all magic numbers. Would this example work if they were well named variables?
@cppweekly you are required by CZcams to select the box "My video contains paid promotion" when it's the case, such as here with the CLion promotion.
I thought I had. I went back and double checked my videos a few days ago.
Sorry about that!
Yes I just double checked, the box is definitely checked on this video, and was already before I looked at it.
something that is "done in compile time" is meta-programming, it is control over your language itself, the compiler or whatever machinery that runs your language. If people don't get how it is powerful, there is probably no point explaining it.
It's out of scope of the video but I don't where to ask anymore.
CLion reports a few unreachable code when using constexpr in my math library. I copy paste it part of it into Compiler Explorer, make sure I use the same toolchain, enable all warnings and it doesn't report anything. So, am I doing something wrong?
I cannot find any CLion forum that solve this problem
How could this be applied to robotics, for example where the process is read from sensor - compute based on sensor data - update actuator signal? It seems to me the entire chain requires runtime data (input sensor).
Similarly, the provided example would not work if the input to parse came via argv instead of hardcoded.
Depending on what the computation of the sensor data is, I could see constexpr being used to initialize a value map at compile time. "If the sensor data is between X and Y, update the actuator signal with Z" kind of thing.
@@ranseus Yes, that makes sense perhaps for discrete systems, where you have a finite set of actuator values.
I was more thinking of a continuous signal system, take for example a drone that needs to compute the output PWM signal for the motors based on the input IMU data, which needs some complex processing.
I suppose the real advantage of this could be to unit-test at compile time (and guarantee that no UB occurs), say for a representative set of input sensor values. But ultimately most of the processing will have to happen at runtime. Of course it's still good if one can keep this in mind and make a clear separation between the compile-time and runtime code.
You are arguing the same as if "return argc+3" is only known at runtime. Yes, it is. But you are forgetting that the programmer could always do simple easy change to "return 5+3" and voila, this is compile time computation now.
Now, imagine much more complicated example. My point is, the human did simple change, often without need to fully understand the entire system or algorithm and the computer (compiler in this case) did the boring tedious job for him. And thanks to constexpr friendly "everything" it was able to produce even better code compared to other languages (imagine C) and tools.
My point is: Even simple change somewhere else in wast codebase could surprisingly bring big benefits. But only if the code around is already constexpr friendly.
"Similarly, the provided example would not work if the input to parse came via argv instead of hardcoded."
This is wrong. The constexpr function would work, it would just be evaluated run-time. That's the point; It can be evaluated at compile time when possible, but it can also be done at run time without writing it multiple times.
In your example there might be parts in "compute based on sensor data" that does not depend on any run-time values (sensor_value * constexpr_func(compile_time_determined_value)). Or address values for HW for sensors/actuators could be computed using some constexpr functions/statements from compile-time known base address. Or some supporting code around those specific tasks in the same program might have use cases for it...
@@fl4shi238yes, constexpr function will work, but not as constexpr. This feature is just a tool, not an ultimate performance problem solver. The tool must be chosen according to a task, not just because it exists.
Hello, love your videos! Do you have any tips for separating coding from work, if you are a programmer? For me, when I think about c++, I think about work, and vice versa. Makes it difficult to gather momentum on trying new things and growing with the language, rather than thinking about the needs of my company. Any advice on making the little I have outside outside of work really count? Thanks
My only advice is to work on something that's completely different from what you do at work. Also - I always suggest doing something that sounds "easy" (like a calculator) then continuing to grow and grow it over time as you learn and apply new things.
@@cppweekly thanks for the advice! I can really deeply relate to the point about "easy", having shot myself in the foot by now too many times to count. Working in an interdisciplinary team is fun but also means that software challenges are mine alone to deal with, but I am improving slowly but surely. Just trying now to descend Mt. Dunning Kruger as gracefully as possible 😜
I don't think there are a lot of programs where one knows a subset of the work which is independent of the input data in advance.
Sure, some exist and for these constexpr is great, but for me constexpr is just a better way for dealing with constants (and even then you have constants which will only be known at runtime).
Nonetheless I hope that over time constexpr will evolve into something as powerful as Zig's comptime (if you don't know how this works, you are missing out), because it would open up way more opportunities.
TBH, I am not sure what C++ is missing here... In additionto constexpr functions and variables C++ has consteval functions and variables. You might need to decarate different place on code, but result is same.
For Zig's comptime blocks C++ has "if constexpr" and "if consteval" statements. For comptime arguments you can use non-type template parameters.
Am I missing something?
@@fl4shi238 You are missing for example constexpr loops.
Another thing you are missing: If you look into Zig's GeneralPurposeAllocator, you can give it a config struct during initialization. In there you can specify for example how Threadsafety should be handle. So in the GPA's code you can see this:
const mutex_init = if (config.MutexType) |T|
T{}
else if (config.thread_safe)
std.Thread.Mutex{}
else
DummyMutex{};
If it would be just that you can specify the type of the mutex, this would be easily doable. But here it's dependent on if you set something and otherwise a bool. I don't think one can do this kind of behaviour with constexpr or templates and if, well, I doubt most (experienced) C++ developers can understand it.
@@kuhluhOG Yeah, that's basically just a preprocessor macro. In C++, and in C as well, you could use #define and #if #else #elseif to deal with that.
@@anon_y_mousse sure, but this has one problem: you can't have multiple GPA with different configs
well, technically you could include the header multiple times with different defines, but that brings with it's own share of problems
@@kuhluhOG That's actually a pretty common thing amongst some programmers. Take for instance the single header libraries for various data structures and the like. You define a macro stating that this is where the implementation goes and then include it in one module where the implementation will live. Then each module that uses it otherwise just includes it as is. Also, you can't forget X macros for building multiple versions of tabular data.
how could you known before hand the extent of the optimizer decision? in my perceptive it could also parse all of it in compile time. I wouldnt want to arbitrarily try pushing stuff into conateval function
In my mind it isn't arbitrary, it's "literally everything that can be done at compile time, should be done at compile time" I was just able to show one succinct example. In my other projects I'm doing things like "building an entire scripting environment" at compile time, then executing script at runtime!
are there any antipatters where we should not use constexpr??
You're asking the wrong person... :D
The main problem with constexpr is that you have to put more code in header files. If the code is already in a header file, then it should be constexpr!
@@cppweekly Thank you!!
Think there's a bug in your code: line 42 should be moved up by to (state = Numbers; always so you don't stay in startup and allow a minus within the literal)
Yeah sorry about that!
Хаха, совсем недавно на реддите был пост про constexpr, там все вспоминали тебя, что мол если произнести несколько раз перед зеркалом constexpr, то можешь появиться ты))
ахахахаах жесть
Lmao😂😂
As I see, you put the hardcoded literals to test your parser and constexpr. What if the number is a kind of random or simply unpredictable user input ofany kind and can't be known at compile time? Does constexpr matter then?
Yes it does. Undefined behavior is not allowed to occur at compile-time, so static_assert can be used in constexpr time to catch a wide variety of errors that a linter might otherwise be required for. I'm a huge fan of executing test suites at both runtime and compile-time for this reason.
@@keris3920 static_assert can only be used in very limited cases. Just because a function is constexpr it does not in any way guarantee it's UB free. Take for example a constexpr function that adds 2 signed numbers. Even if it's constexpr, it will be UB if the addition overflows, which can happen at runtime with unknown data.
This cannot be statically asserted (unless the 2 numbers are passed as NTTP).
@@carlosgalvez7464 I want you to try what you just claimed and report back. There are several things you just claimed that are not correct.
@@keris3920unfortunately I'm not able to share links to code illustrating my point. Can you elaborate on what claims are not true?
My point is that you cannot static_assert nor detect UB at compile time when calling a constexpr function with non-constant (runtime) data.
So yes, you can run your unit tests at compile time, on a set of static data. But that at runtime you can pass different inputs to the constexpr function and invoke UB there.
@@carlosgalvez7464 your claim that you'd need NTTP data in this scenario is false. You can certainly pass by function argument. But I agree with your clarification though.
I do not know why you are trying to dismiss the idea that compile-time testing catches a huge quantity of bugs. It's true that not all inputs will produce undefined behavior. But to me, the problem with that is really that you didn't enumerate all of the test cases at compile-time. And furthermore, if you don't mark as many of your functions as constexpr as possible, you effectively lock yourself out of being able to catch ANY undefined behavior with this method. Constexpr should always be applied where possible.
Can you generalise this?
Suppose you have 4 leading steps at compile time, 2 mid steps at run time, 5 trailing steps at compile time.
Can't you do 4 + 2 + 5 steps?
It wont work all the time but if the steps are independent of each other, it will.
I'm currently working on how to better present this, but my current idea/plan is to show how for your " + 5" part, maybe you can at least set up the "size and shape" of the problem at compile time, so the compiler has more hints for how to optimize it? If you come up with a good answer/conversation here, please message me from my website. articles.emptycrate.com/contact.html
Here's my take:
(1) if you know something at compile time, (A) write it as a constant. We don't use constexpr to ask the compiler to calculate how 1+1=2. Just write 2. Or (B) use constexpr to make new constants (2pi, 3pi, sqrt(2), ...). One thing I like is to convert all strings to constexpr string IDs.
(2) if you know something can be calculated at compile time based on a lot of data. E.g.: you have an array of N possibilities (N > 10) and you want to calculate combinations and arrangements (probability) or you want to use some Dynamic Programming to get a subset of that array that fits into some criteria.
(3) You don't know the data at compile time but you know the pipeline of instructions. Can you do something like Expressions Template? You know how matrices will multiply (in what order) but not the data itself. You know the string format but not the variables that will populate the interpolation parts.
(4) Everything else will probably be Runtime Information and should be as const as possible.
How can you have constexpr strings?
Can you please explain. I'm confused.
Sorry, but IMHO that's a silly example of a one-off program with fixed inputs.
We almost always need to process input. In my case I need to load a list of templates to work with and to work with user documents selected at runtime by the user.. None of this is known at compile time.
I agree that more of the work in certain situations should be done at compile time. However, where I disagree is with how to ensure that. In particular in this case, I just hate the keywords constexpr and consteval. I would've preferred that the const keyword was just recycled to accomplish the same thing and let the compiler figure out which fit correctly. I know it would've been slightly more difficult to implement as that's how I've defined const in my own language and it was a bear to work it out, and it's possible that it could break some old code, but the committee has done that anyway numerous times in updating the standard the past 26 years.