C++ Weekly - Ep 444 - GCC's Implicit constexpr
ฝัง
- เผยแพร่เมื่อ 24 ธ.ค. 2024
- ☟☟ Awesome T-Shirts! Sponsors! Books! ☟☟
Episode details: github.com/lef...
T-SHIRTS AVAILABLE!
► The best C++ T-Shirts anywhere! my-store-d16a2...
WANT MORE JASON?
► My Training Classes: emptycrate.com/...
► Follow me on twitter: / lefticus
SUPPORT THE CHANNEL
► Patreon: / lefticus
► Github Sponsors: github.com/spo...
► Paypal Donation: www.paypal.com...
GET INVOLVED
► Video Idea List: github.com/lef...
JASON'S BOOKS
► C++23 Best Practices
Amazon Paperback: amzn.to/47MEAhj
Leanpub Ebook: leanpub.com/cp...
► C++ Best Practices
Amazon Paperback: amzn.to/3wpAU3Z
Leanpub Ebook: leanpub.com/cp...
JASON'S PUZZLE BOOKS
► Object Lifetime Puzzlers Book 1
Amazon Paperback: amzn.to/3g6Ervj
Leanpub Ebook: leanpub.com/ob...
► Object Lifetime Puzzlers Book 2
Amazon Paperback: amzn.to/3whdUDU
Leanpub Ebook: leanpub.com/ob...
► Object Lifetime Puzzlers Book 3
Leanpub Ebook: leanpub.com/ob...
► Copy and Reference Puzzlers Book 1
Amazon Paperback: amzn.to/3g7ZVb9
Leanpub Ebook: leanpub.com/co...
► Copy and Reference Puzzlers Book 2
Amazon Paperback: amzn.to/3X1LOIx
Leanpub Ebook: leanpub.com/co...
► Copy and Reference Puzzlers Book 3
Leanpub Ebook: leanpub.com/co...
► OpCode Puzzlers Book 1
Amazon Paperback: amzn.to/3KCNJg6
Leanpub Ebook: leanpub.com/op...
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...
► C++ Best Practices Forkable Coding Standards - github.com/cpp...
O'Reilly VIDEOS
► Inheritance and Polymorphism in C++ - www.oreilly.co...
► Learning C++ Best Practices - www.oreilly.co...
Someone should submit a proposal to make all functions implicitly constexpr, if they can be. Lambdas already have this behavior so most implementations already know how to do it and it should be backwards compatible, so it doesn't sound like a bad idea.
I am saying this since the first moment that constexpr has appeared.
everything that is possible to compute at compile time should do so every time, and constexpr should express a requirement that an expression is computed at compile time, not just a possibility.
consteval is what constexpr should have been.
this follows the tradition of C++ of having all defaults wrong, (sometimes for historical reasons)
@@AlfredoCorrea like std::span and other containers becoming completely useless from memory safety/security point of view. Operations without range checks should have "unsafe" prefix (same as any function doing any kind of pointer math), so shoddy code can be found faster.
@@tlacmenAre you familar with Zig? It lets you slap “comptime” before any call to a pure function (code which doesn’t mess around with globals or does I/O) and that makes the expression “consteval” with C++ terms.
The advantage is that the user gets to decide whether the call should be made in runtime or compile time.
Zig also allows you to pass types in and out of functions which combined with “comptime” gives Zig generics and very powerful static reflection / metaprogramming.
I absolutely agree. The const* stuff are an abomination of the C++ standard.
The are constant contexts, and if you use there some expression that cannot be constant folded, emit an error.
No reason to sprinkle around const* around the code, that I am pretty sure will be changed later with the usual "sorry, we did it wrong before ..."
implicit constexpr goes against the C++ design rule of "let's make everything shitty by default, but terribly customizeable so that if you decorate your code with all kinds of warts you can produce pretty efficient and safe code"
May be useful for testing the net benefit of constexpring old code before doing all the work of manually altering the source code. Although even for such a test case if you still need to go through and "inline" everything first, so how much time are you really saving. Probably very case by case dependent.
Does this only happen in GCC? Could it happen to Clang when using GCC's standard library as well?
It's a compiler flag specific to GCC.
Wait...what ? Constexpr variables are automagically captured in the lambda? Didn't know about that. Disturbing...
Anyway, thanks for sharing Jason.
I wonder if this can break code. I guess one might have libraries that are not constexpr friendly and not compile. i am going to start testing my code (libraries) to see if it works in combination with this flag.
I definitely would not rely on this if you care about portable code...
@@cppweekly the idea is not to use, but ensure that a library I provide still works under this flag.
Might be interesting if there is an implicit inline or similar mechanism for Release builds with GCC, especially if the STL gets implicitly constexpr'd if possible, or if GCC has some additional constexpr extensions
Aren't all functions already implicitly inline? "inline" means "Compiler please make this function inline if it's suitable.", but the compiler can already inline any function it wants. The only functions that aren't implicitly inline are those that are explicitly not, like functions with __declspec(noinline) on MSVC.
When optimizing for speed the compiler will inline more functions (if it makes sense), so -O2 is already doing that.
I would love to have implicit const too... make it like rust where you use a keyword to make things mutable
Yeah, that'd be pretty great.
Does -O3 take this into consideration?
Maybe we can use this flag to get constexpr from 3rd party libraries sometimes?
seems like bots really love watching jason's video /s
They just love our littlw sisterhood!
I'll say it again even though no one will read this or agree if they did, but I think the language should've just defaulted to constexpr/consteval all the things and fall back to non-const if const wasn't possible. I also think that they should have enhanced the const keyword so that using it was a check on whether something could be constexpr/consteval'd and result in an error when it can not. Also, I'd really like to know if there's a platform that Clang runs on that GCC doesn't also run on, because I disagree with the advice about only targeting one compiler when that compiler is GCC because it runs nearly everywhere and has more cross compilers than you can shake a stick at. If you merely said don't always use MSVC, then of course I'd agree because it has a much more limited set of platforms that it runs on.
Too bad you have to give Microsoft both of your arms and a leg to get GCC working [natively] on Windows.
idk the version from winlibs works perfectly out of the box for me
What's so hard about installing msys2 + gcc (mingw) ?
Lol, how the hell is that Microsoft's fault!?
"Too bad you have to give Linux both of your arms and a leg to get MSVC working [natively] on Linux."
@@12affes the issue is that the only reason that GCC and Clang don't work out of box [on windows] is because Microsoft makes C++ dev as hard as possible so that you install Visual Studio and use CL where as in the opposite case there's no supported version of CL for Linux. The issue I have is that microsoft is making it hard to use 3rd party apps so that you use their [not free] first party app...
@@skeleton_craftGaming The problem boils down to different compilers not using the same name mangling algorithms. If they had standardized that for all C++ compilers years ago, and it would be really difficult unless you ignore a bunch of platforms, then they'd all interoperate with ease. I might be alone in this thinking, but if they had at the very least standardized that for hosted platforms, then it would have been better than nothing.
Honestly I don't see the point of constexpr, it only works if the values in the equation are known at compile time, in which case the compiler would be able to optimise (evaluate) the equation anyway.
You can literally see in this video that your assumption is false
@@kaosce No, it's literally not false, and the video shows why. The problem here is that the standard doesn't mandate that behavior, so the standard is clearly wrong here.
@@anon_y_mousse Exactly, which makes the OPs assumption false.
@@WilhelmDrake I think there may be a disconnect in your braln. The compiler can literally see it all and with optimizations turned on it does exactly what it should. The problem is again the standard not mandating that behavior by default because it's a really simple change and the code infrastructure in compilers is already there.
My points are;
1) constexpr only works if all the data is known at compile time, in which case an optimising compiler would do the calculation anyway, making this gcc flag pointless
2) the whole point of computer programs is to do calculations on data that isn't known at compile time, so what is the point of constexpr?