CppCon 2018: Arthur O'Dwyer “Concepts As She Is Spoke”
Vložit
- čas přidán 31. 05. 2024
- CppCon.org
-
Presentation Slides, PDFs, Source Code and other presenter materials are available at: github.com/CppCon/CppCon2018
-
The last time the keyword `concept` appeared in the C++ Standard's working draft was July 2009, two years before the release of C++11. Now, in September 2018, two years before the expected release of C++20, the working draft once again contains something called "Concepts" - something very different from what was there before, and - so far - much more conservative than the Concepts TS (formerly known as "Concepts Lite").
What should the forward-looking C++ programmer do and know about Concepts in C++2a? Arthur will attempt to puzzle it all out. What is a "Concept" and why should we care? What is the current syntax for defining and using concepts? What compilers support C++2a concepts syntax today, and how do I enable it? How does it affect name-mangling? What are "atomic constraints," "disjunctive clauses," and "subsumption"? What good are value concepts and template concepts? What is the difference between a "requires clause" and a "Requires element"? What is this "terse syntax" we've been hearing about, and why is it controversial? What is "Giraffe_case" and should I use it? Can I use the "requires" keyword without Concepts?
This material will be presented from an outsider's perspective, which means you can expect Arthur to say at least a few wrong things; and the shelf life of this material will be short, as C++2a Concepts are very much in flux right now. Still, if you want to get caught up on (or in) the Concepts discussion, this might be the place for you.
-
Arthur O'Dwyer
Arthur O'Dwyer started his career writing pre-C++11 compilers for Green Hills Software; he currently writes C++14 for Akamai Technologies. Arthur is the author of "Colossal Cave: The Board Game," "Mastering the C++17 STL" (the book), and "The STL From Scratch" (the training course). He is occasionally active on the C++ Standards Committee and has a blog mostly about C++.
-
Videos Filmed & Edited by Bash Films: www.BashFilms.com
*-----*
Register Now For CppCon 2022: cppcon.org/registration/
*-----*
The thing about C++ generic programming is that it is as sophisticated as an undertaking as that of writing a compiler - only a rarified relative few will spend the time to master it's shear complexity - the folks that maintain the template libraries. Rank and file C++ programmers won't typically be able to spend the time to go as deep as necessary to have reasonable competence.
C++ generic programming has probably always been an activity best done by an anointed priesthood while most everyone else just consumes what the priesthood provides. With advent of C++11 and now Concepts in C++20, generic programming has become very much more powerful for that priesthood, but at the same time even more remote from possibility of the rank and file. One could try to dabble in it but there is a just a vast surface area to learn in order to do it well.
This is the thing about the C++ language - it is too complex for rank and file developers to master the full language - they have to settle for a working subset of the language in which they can get their day-to-day work accomplished.
I was enamored with advent of C++11 for a while but am now moving on to Rust to see if is possible for rank and file developers to come close to mastering full capabilities of that language. So far am encouraged as it does much better job of nailing down ownership (move semantics), borrowing (references, slices), mutability control, and lifetimes than Modern C++. I've yet to dive that deeply into its generic programming to see how well that goes, though. And it retains a more sophisticated macro capability that is intended for use. And has some functional ideas - enums and pattern matching are rather interesting.
Modern C++ is excelling with ideas such as constexpr for accomplishing at compile-time what otherwise has usually been computed at runtime - here it is definitely exceeding the thinking in the Rust community as an avenue for garnering more efficiency. And fact that Nividia has targeted C++ memory model with its latest generation GPUs and have adopted and maintain a variant of Modern C++ for programming those GPUs definitely keeps C++ language front and center in that very important arena.
In the http_request example at 8:00, don't we already get a compile time error if the template object doesn't implement body::read/write? And what do we gain from using a concept if the compile error is already being thrown?
Try it. Write that, use a bad template parameter, and look at the error you get. See if you can easily figure out what you need to change to fix it.
Now imagine that, instead of that error message about no such member function "write" or whatever -- which isn't even complete, mind you -- you got "Type argument [...] does not match concept Body". Now you just look up `concept Body`, and you instantly know what you need to implement to make it work.
@@UCH6H9FiXnPsuMhyIKDOlsZA Do you really instantly know what you need to do to make it work? I could imagine scenarios where a concept has some arcane and confusing details that make the requirement to 'match concept body' be actually very difficult. If the error message was more direct, like 'Type argument [...] must implement [X] in order to match concept Body', then you would instantly know what you needed to implement to make it work, which is exactly what the compiler already tells you when it says 'type argument has no member function 'write' or whatever'.
@@UCH6H9FiXnPsuMhyIKDOlsZA Concepts sounded amazing to me while watching Bjarne's keynote. But after looking at this talk and understanding more about the capabilities of existing generic programming I'm just questioning the actual benefit.
I definitely agree with your point that meaningful error messages is very important. And I also see that programming syntax that more clearly conveys our intent with some kind of generic template interface polymorphism as a concept is also very important.
@@loomismeister You bring up a fair point there, about complex concepts. But while they don't _solve_ that problem, they do _alleviate_ it -- imagine those complex concept requirements not being described anywhere. With a concept, even if it's difficult to read, you still have something that spells out _exactly_ what you need; with things as they are, you... don't, really. Or at least, in much harder-to-read syntax. This is especially important if you need multiple member functions, not just the one; implementing each as you get errors from the method is slower and more annoying than having a concept upfront to work from, and can also help you avoid potential design pitfalls.
Concepts also allow for future expansion a little easier, though this benefit is somewhat iffier. In short, you can define a concept with _more_ than you currently need from a type, to enable future optimizations or functionality without calling code needing to change.
IIRC there are also some neat compiler optimizations (as in, optimizations to the compiler itself, not optimizations to output code) and code cleanliness/static analysis things that can be implemented only with concepts. I don't know very much about compiler design or static analyzers, though, so I can't say for sure.
With all that said, no, concepts aren't a silver bullet. That much is obvious, and I'm sure you're not claiming they have to be. Ultimately, it's a matter of opinion on whether or not their relatively minor benefits are worth it. In my experience, they are. In yours, they might not be, especially if your tools have good documentation. But personally, I'd rather have a single obvious blueprint for what I need to write, even if that blueprint is hard to read, rather than having to dig through template pseudo-concepts or, worse, the calling code itself. I've had to deal with some... very complex code before, and it's not fun.
1:00:27 - I think the answer to this question is contracts.
For all oaf you wheo do talks, keynoteis aned liectures, thouse of you who speaek to an auadience ion generael: Do you knoaw how tirinig it is to listen to soemeone go uuuhm and aah befoire every sentenoce? Makes it imapossible to paey atteantion to anythinyg you say. Doesan't matater how valuabale it is, it's like reading text with random vowels inserted.