CppCon 2019: David Stone - Removing Metaprogramming From C++, Part 1 of N: constexpr Function Params
ฝัง
- เผยแพร่เมื่อ 19 พ.ย. 2024
- CppCon.org
-
Discussion & Comments: / cpp
-
Presentation Slides, PDFs, Source Code and other presenter materials are available at: github.com/Cpp...
-
C++ has, buried within it, no less than four "general-purpose" programming languages. We have regular run-time C++, constexpr, templates, and macros. This presentation will cover a new proposal for C++: constexpr Function Parameters. It aims to make C++ a much more powerful language by helping to merge constexpr programming into regular C++. This will allow writing code that is faster, is easier and more natural to use, is terser, and catches errors at compile time. This new language feature would provide a way to annotate a function parameter as constexpr, letting you do things like overload on whether something is a compile-time constant, or pass constants to things that cannot have template parameters (like constructors and operators).
This presentation will focus on the principles used in the design of C++ and in this feature. From those principles, we will go into the details of the proposal. This presentation will briefly cover what constexpr is used for as of C++20 (the version of C++ that is being finalized now and will be officially 'released' in 2020). The proposal for constexpr function parameters is targeted at C++23 ('released' in 2023). The presentation will briefly cover the standardization process and timeline.
Recommended background (none of these are necessary, but they are helpful):
No Shadow Worlds: probablydance....
Inventing on Principle: vimeo.com/3657...
constexpr: Introduction (as of C++11 and C++14) • CppCon 2015: Scott Sch...
The proposal paper can be found at github.com/dav...
-
David Stone
Uber
Software Engineer
Boulder, CO
David Stone works on autonomous vehicles at Uber in Louisville, Colorado. He is a member of the C++ standardization committee, where he chairs the Modules Study Group (SG2) and is the vice chair of the Evolution Working Group.
He has written an algorithm that solved the traveling salesman problem in constant time. He can square the circle and divide by zero. He can move his king into check. He once wrote an optimizing compiler that solved the halting problem, but doesn't need to use it because his code is already optimized.)
-
Videos Filmed & Edited by Bash Films: www.BashFilms.com
*-----*
Register Now For CppCon 2022: cppcon.org/reg...
*-----*
![Don't constexpr All the Things - David Sankel [CppNow 2021]](http://i.ytimg.com/vi/NNU6cbG96M4/mqdefault.jpg)
![กี่หมื่นฟ้า | Your Sky Series EP.1 [2/4]](http://i.ytimg.com/vi/qJbQs_nhjD4/mqdefault.jpg)
As of 2024, I'm tempted to say that pipelines of ranges and views are an additional "shadow world." They resemble an embeddable array-language within the context of C++.
Awesome talk, Next step towards 'simplicity'. which is one of the most needed feature for c++.
Who want a simple *vec.contains(stuff)* when we can have *std::find(vec.begin(), vec.end(), stuff) != vec.end()*
I mean why can't we have nice things ? Memeber functions don't even cause any overhead!
@@destiny_02 at least they added .contains for maps and sets in c++20
Loved when he asked who knows when to use type name and template. I fight with this every time - the answer is when I get a compile error and I can't work out why and adding type name or template makes it go away! This sounds great and I hope it gets accepted
Amazing talk, can't wait for this to get in
Excellent. I've needed ALL of the features he is talking about. I also have written something like his bounded_integer library, replicating VHDL's fixed point library in C++ where value bounds are compile time arguments.
I would also add non-static constexpr member variables to replace non-type templated classes, and a "constexpr for" like constexpr if or D's static for loop.
The only thing missing here is a statement that, if a function is `consteval`, then all of its parameters must be `constexpr/eval` as well. After all, that's what `consteval` on a function means: attempting to evaluate this function in a way that isn't a constant-expression context is a compile error. That means its parameters must themselves be from a constant-expression context.
Excellent use of Helvetica in the slides also very interesting talk.
the whole talk I was like "why introduce maybe_constexpr ? why don't we make constexpr variable 'contsteval' and use constexpr as 'maybe_constexpr' .. I hate inconsistency" .. then he proposed it, what a relief ! :)
Well, one reason why not to do that is that "eval" means "evaluation" (as in, what happens when you call a function), while "expr" means "expression", which suggests something much more static, like a variable. Applying `consteval` to a variable is sending the wrong message.
It would have made more sense back when the meaning of `consteval` was going to be spelled "constexpr!". Especially since we could add "constexpr?" as the maybe form, and eventually deprecate the unadorned form.
I really like the proposal. I think this is a very good example of how C++ can and should be simplified.
53:40 This sounds like a good cleanup. I hope that will be possible to change the meaning of constexpr on variables.
It would have been interesting to hear how constinit fits (/doesn't fit) into this. E.g. could constinit on variables with static storage be replaced by consteval? (reading up on this it looks like it cannot work as a constinit variable is not a constant expression itself, it only requires constant initialization)
57:25 - Wouldn't that be a bracket operator that's constexpr with a parameter that's consteval? For a tuple, the index parameter would have to be a compile time constant in order for the return type of the function to be known at compile time. And the operator itself would be constexpr because it could only be compile time constant if the implicit `this` was also compile time constant. Perhaps that means we need another decorator keyword at the end of member functions in addition to const, final, etc... in order to talk about the constexpr-ness of this.
I really hope this proposal goes through.
comp const int x, comp int x, const int x&, int x, int x&, int x&&.. In this order means less and less restrictions on a variable, i like the keyword comp more. It reflects that is directed at the compiler not the cpu and its as short as const. comp const is consteval in this regard. Also is_comp or is_const instead of is_constant_expression. Although is_constexpr might work too. Just my opinion. I like that proposal alot though. It makes totally sense to add this to the function signature and handle them normal parameters
Problem with the constexpr variable meaning change:
often people used constexpr to mark that some expensive computation is done at comile time ( constexpr auto x = expensive();) You break that insurance with this change. Code will continue to work, but if somebody messes up and makes expensive runtime function you do not get a compile error.
While yes, this *could* break old code, if this proposal was to go though, and you wanted to still ensure some variable ‘x’ was initialized at compile time, you could use “constinit”, “constinit const” or “consteval”
At 5:45, I think the expression `1/0` would be evaluated irrespective of the argument `b`... and that is because of en.wikipedia.org/wiki/Constant_folding .. if that is so, then the example doesn't make much sense.
Get it in please! :-)
We need more of this attitude: "the simpler we can make things without deteriorating usage, the better the language gets" -> collocating things instead of adding always newer and newer features.
Instead of just having parameterized types, why not parameterize all the things?
That's cool and all, but let us use types as if they were values..
That is Part 2, to be completed after this is further along in standardization.
Is this a war? I see a ton of talks on adding more meta programming to c++, now I see a talk on removing it.
Before anyone gets too excited, they should read how it works. It basically is syntax sugar for stamping out templates with a template parameters in the place of constexpr function arguments. The major win for consexpr functions was that they are more lightweight then templates, this will not be the case here.
You need to watch the video again. Its far more than syntactic sugar as you can write static_asserts or branch easily inside a function depending on the value. You write less code and prevent code duplication. Its more readible and more consistent with other concepts
@@ecicce6749 dude, "less code"? It's just template, and "branching inside code?" You can branch like it's a function parameter. Everything is nearly same, and now with the help of concepts, the possibilities increase a lot.
If it is syntactic sugar for templates, it's only because templates came first. This is just better syntax.
Genius!
Nice proposal. But please don't suggest to generate regex automata at compile time - it just ruins my compile times. (:
For me longer compile times means I used my time more efficiently by outsourcing coding to the compiler. So the longer it runs the more work I accomplished in less time :)
The way I look at it, my users don't care about compile time - they care about run time. My job is to make the users happy, so I'll take the compile time hit gladly.
@@superscatboy Agreed. I don't write code for its own sake and my convenience. The entire point is run-time.
This sounds more like an issue between developer and compiler. I expect -O3 to produce the fastest run-time code possible, compile-time be damned. If you want faster compilation, reduce the optimization level.