CppCon 2017: Vinnie Falco “Make Classes Great Again! (Using Concepts for Customization Points)”
Vložit
- čas přidán 28. 05. 2024
- CppCon.org
-
Presentation Slides, PDFs, Source Code and other presenter materials are available at: github.com/CppCon/CppCon2017
-
Learn new ways to think about class design, that you can apply to your own projects!
In this talk we'll start with a simple class that models an HTTP message. We’ll go over the limitations of the simple declaration, then walk through a series of guided improvements. We will explore ways to think about class models, create a concept as a customization point, perform type checking, and document a concept.
The example class we will explore is based on the message container found in the Boost.Beast library. You do not need to know anything (or care) about network protocols. This is about building better classes.
-
Vinnie Falco: Engineer, Self-Directed
I'm the author of BearShare, DSPFilters, and most importantly Boost.Beast - a C++ header only library that offers implementations for HTTP and WebSockets, located here: github.com/boostorg/beast/
-
Videos Filmed & Edited by Bash Films: www.BashFilms.com
*-----*
Register Now For CppCon 2022: cppcon.org/registration/
*-----*
28:49 I'm so glad we have concepts now. Writing this SFINAE stuff where we poke the compiler in weird ways is not something I'm gonna miss!
I made a huge mistake trying to watch this in background while I did some work. Now I have to watch it again in "foreground" because he was able to pack so much knowledge per slide that is impossible to just "skim over". I wish more presenters were like him!
Great Talk! I really enjoyed it (:
About 30:06 (the (void)0).
First of all, writting such traits, we must ensure that specialized template will be same as primary one.
Such decltype:
decltype(B::write(/*...*/))
would result as a type deduced from B::write call, which is its return type, which can be pretty much anything. To ensure that decltype will end up with void type (to satisfy the primary template) we can add the (void)0 'expression'.
decltype(B::write(/*...*/), (void)0)
Thanks to that, decltype will end up with type deduced from "B::write(/*...*/), (void)0" expression. Basically it's a binary operator expression, where operator is the comma, lhs is B:write and rhs is (void)0. Comma operator always returns the rhs. Thanks to that if B::write is valid, comma will 'return' (void)0's type (which is obviously void).
So (void)0 can be used to satisfy the primary template.
Getting back to your case. You have this:
template
struct is_body;
template
struct is_body; // (void)0 to ensure that specialization will match primary template. It is redundant because you're already 'inside' the void_t.
If you wouldn't need `typename B::value_type` check, you could omit void_t and write;
struct is_body;
TL;DR
(void)0 is redundant.
Live demo: wandbox.org/permlink/pGivS5jzN8wzW2nM
ummm....errmmm... I think you might be right about that :)
@@thevinn excellent talk, Vinnie!
This guy is a Beast! The best CppCon talk this year IMO.
Agree! Thoroughly enjoyed this and recommend everybody on my dev team watch this.
Thank you for the kind words
Talk was great, thanks for your content Vinnie, but the talk about the runtime polymorphism from Louis Dionne was my favourite. We should agree to disagree on the talk, but we can agree that this CppCon was pretty amazing!
That talk was also good!
Yes, very plain spoken and good practical C++ techniques.
He knows how to make a presentation great. I enjoyed this so much. I hope he'll be a speaker in the next CppCon again.
This year's presentation will be on Beast WebSocket and the Interactive Web.
I'd love to see an updated version of this talk using C++20 concepts
Well done Vinnie. A presentation packed with interesting and understandable content. Thank you.
This was a good talk not only content-wise, but also presentation-wise - clear, well paced, and understandable.
This is probably the very best talk I've seen so far. So thought through, structured and extremely(!) well spoken. Hats off to you sir, I enjoyed it a lot.
Too kind!
Good presentation and VERY clear slides! They can be read and digested in 20min, which is a great thing.
After 3 years, it's still educative to go back and rewatch Vinnie's speech!
Super informative for a hobbyist C++ guy like myself, it's nice to hear some solid advice that isn't just arcane grey beard knowledge with no explanation.
One of the areas I find lacking in modern C++ is the lack of straightforward information and tutorials for modern concepts. Most of the learning material is outdated or just of poor design. This gives me some hope that maybe the trend will shift, and more people can use this awesome and daunting language to solve real problems.
I found this to be a problem for myself as well. There are a lot of good books on C++, but almost none that try to explain templates with uses more complex than container of Ts. There are some good books for pre-C++11 TMP, but basically none that cover C++11/14/17...
Thanks! Yeah, I find that the "C++ books" are usually lacking. I'm at a point where just reading about language features isn't going to really help me very much - I can find that easily online. What I would love is a book which helps me be a better designer. The problem is that such books generally do not exist. Teaching design, in a way that is non trivial (i.e. goes beyond "use RAII"), is a difficult problem. My goal in this talk was to try to impart some design techniques to stimulate the imagination. I have ideas for other similar talks where real world problems are solved using novel approaches.
Amen. This was great.
Starting used Beast before it was in boost. Absolutely invaluable library.
This talk is amazing. Starts from a basic and talks a deep dive. The presenter does a very good job in getting us through his flow of mind
I'm just starting to learn C++, I have no idea what have I just watched :D
Join the club!
That is expected. While, as someone with experience with template meta-programming, I understand all of this completely, this complexity is not necessary. Since the C++ committee has decided to dump in a near endless amount of "features" to increase the potential for new combinations that add software engineering benefit, in doing so, they also increased the number of combinations of features that actively detract from software engineering benefit. This has lead to what you are seeing in this talk: tons of people in a room debating the most pedantically super awesome, new-age C++ solutions to problems of genericity that they really never had in the first place. We, as a community, have gotten to a point where we care more about the C++ used to solve problems than the problems that we are trying to solve with C++. Take this with a grain of salt.
Library writers need to know that stuff. App writers for business will know their specific needs and won't make it customizible. Rather, they will complain that the common libraries won't work for them because of the specific containers used.
CppCon is not for beginners
to Thor GodOfThunder:
And you right. Guy's motto - add layers of OOP and template mumbo-jumbo.
He will bury himself and any other kid who would believe in his nonsense.
Very solid content with thoughtful organization to make it very understandable. Thank you!
Vinnie, this is a great presentation. Although it is flavored by Beast, which gives it real-world credibility, you've succeeding in keeping the talk a tutorial on Concepts and Generic Programming with specific techniques driven by real-world requirements.
This is a valuable tool that I'll be recommending to any would-be C++ library designer.
I look forward to seeing more talks like this from you.
Thanks.
That is very kind of you to say, I am glad you enjoyed the talk!
Wow, what a fantastic talk. Great stuff.
I really liked this talk. I've watch several times during this year to refresh my memory.
I wish I could reason my way through my code the way Vinnie does here. He must not have many issues finding solutions quickly with the projects he comes up with. his JUCE add-ons are pretty awesome to study too.
Yeah...if only that were true, lol. Designing good interfaces and concepts is an extremely difficult problem. Usually it is far more difficult than writing the actual implementation (especially in the case of HTTP). It actually took close to a year of trying different ideas before I finally settled on the right combination of interfaces to make this work smoothly. I also had help, I always encourage stakeholders to weigh in on the designs by participating in the GitHub issues and there were a few people who contributed significantly to trying out the previous failed prototypes. You can read the discussion in the closed issue here: github.com/boostorg/beast/issues/154
That was a great talk! Gives me lots to think about in my code.
Glad to hear it, and I'm available for questions just mention me on GitHub using my username @vinniefalco
WoW, Vinnie is a BEAST! Don't know how I missed this talk last year. He should write a book!
Slow down there! If I'm going to be writing anything it will be more documentation and tutorials for Beast :)
That was great work! Thank you!
Thank you!
Great talk and it was very educational.
Really cool talk! Practical stuff! The Exemplar example is really interesting!! I hadn't heard of anything like that, but it's a great idea.
Thanks! Here's a "real world" exemplar (towards the bottom) www.boost.org/doc/libs/master/libs/beast/doc/html/beast/concepts/Body.html
This is my favourite talk from the conference this year.
Very well presented material.
This video is like a design bible for me)
Great talk, thank you!
Excellent stuff
brilliant fantastic great talk! A lot like about how to design a class in c++, thanks!
Excellent talk! I have learned many interesting ideas and concepts today :)
I love this guy.
Well done!
Thank you!
Couldn't have done it without you :)
great job vinnie -
Thanks!! I thought of you when I wrote the "valid expressions" hehe
This so great！Thank you!
Thank you too!
Great stuff, thanks!
We love Vinnie!
that's a hell of a talk
Great talk 👍👍👍
great talk I think c++20 concepts will make the code a lot more readable with consistent compiler errors
Great talker....is auto const valid c++ syntax? (Its shown in the for loop at 19:50) shouldnt it be const auto?
You make me like boost for the first time.
I don't know whether to cheer or cry lol
Very Impressive Lecture ....
Very great talk! But is there a good reason to read the file via the C instead of the C++ interface? (Slide 70)
There's a C++ way? I don't know it.
I really don't...most of my work has been with graphical user interfaces, I use streams very rarely. I guess some kind of basic_fstream but I would have to look it up on cppreference.com to really know. I also started in C with the K&R book in 1990 and then moved up to C++ a few years later.
On bigger files I would use:
#include
#include
void write(std::ostream& os, std::string const& path){
std::ifstream is(path);
std::copy(
std::istreambuf_iterator(is),
std::istreambuf_iterator(),
std::ostreambuf_iterator(os)
);
}
Small files can be copied by:
#include
void write(std::ostream& os, std::string const& path){
std::ifstream is(path);
os
Instead of true/false template parameter wouldn't it be better to use some tag structs?
I don't think so because it would just clutter up the namespace with more symbols. But it is definitely subjective.
why void_t is being templatized i dont understand that at 29:42
the entire point of void_t is to take in some template arguments and ignore them. when the compiler attempts to resolve a template function call with a certain set of template parameters, it will do repeated substitutions either until everything is fully resolved, or one of the substitutions is invalid. If invalid, the compiler will act as if the function is not declared and try to look for other suitable candidates. this is the SFINAE (Substitution Error Is Not An Error) that was referred to. An example of an invalid substitution would be something like `typename Body::value_type` where Body is some class say `MyBody` and `MyBody` has no `value_type` member. In this case there's no alternative overload so the compiler would simply error (a really awful unintuitive error!!) if the concept is not satisfied.
There's a much better way to all this stuff nowadays though, and that's with C++20's new `concept` and `requires` keyword that does all the stuff that the garbage SFINAE does but way cleaner and looks less like code someone would write after being induced into a frenzy by an eldritch horror.
Great talk! Without any doubt!
Although, I should ask: Adding reason methods to the Fields Class and deriving the class from Field doesn't break the SOLID principles? Like Single responsability and Liskov substitution?
Ask just for learn more.
Normally I would agree but I had to balance those guidelines against other needs. The use of derivation in `message` is not intended to show an "is-a" relationship but rather it is used to achieve more mechanical results. The `message` class, including the classes from which it is derived, should be thought of as a single monolithic interface. It is not intended for users to derive from `message` any more than it is intended for users to derive from `std::vector`. `message` is a vocabulary type which models a complete HTTP message, and has sufficient well defined customization points to make derivation unnecessary.
That is a great question Alexandre. I think one of the failures of "OOP" is that inheritance didn't quite work out the way that everyone thought it would. The inheritance used in the Fields and message types is used as a mechanical structuring to make them appear as a single object. It is not intended to communicate the typical "is-a" relationship used in class hierarchies. There is precedent for this. For example, deriving from std::shared_from_this does not imply that a class "is-a" shared_from_this.
Every interface is like a snowflake, it is unique and addresses its own particular domain-specific problems. When designing good interfaces we need to make very human judgements which are almost always subjective in terms of what is "better" or "good." SOLID, SRP, and LSP are useful tools but like all tools it is up to the artist to decide how to use them, if at all. And designing interfaces is very much a form of art.
@@thevinn thanks for showing your work and the reasoning behind it. Good talk.
Do you think that C++ will acquire a compile-time Interface construct similar (or different to) Java's, to deal with 'is-usable-as' in parallel to the class-inheritance 'is-derived-as'?
@@williamchamberlain2263 I strongly doubt it. Inheritance in C++ is pretty idiomatic and well-baked. I have not ever seen a proposal which changes it. I feel that the C++ inheritance model is fine the way it is, we just need to make sure that we are using it the right way and for the right purposes.
@@thevinn awwwww - but I wanna text-fiddler
: )
Why isn't there a C++ Inquisition dragging the presenter behind the curtains at the moment when he presented inheritance from the Body type? Isn't that inviting trouble?
Great talk, but it would be great if he used the names some of those techniques are known as: Visitor pattern, traits, curiously recurring pattern.
nice talk
I'll be honest - I'm from Java-land, so I'm not used to caring so much about 'zero cost'. At 9:25 I went "...wot?..." because I'd just set up the message member variables as interfaces, and instantiate them as classes.
So this is useful for me - to see how you can think about things in C++ with the minimum-cost principle in mind, but also to see how C++ people might think (or overthink) about a problem when they design libraries that I use or open source code that I try to learn from.
Great talk. However, I have to add my two cents here.
C++, instead of adding some sort of compile-time interfaces, force developers to do monstrosities shown in this video to display compile time errors which are hard to track down the source of and are still hard to understand, even with those monstrosities in place.
I suggest taking a look at the "metaclasses" proposal which aims to solve this exact problem.
Writing concept checking metafunctions is not easy these days especially if you are limited to C++11 (Beast requires only C++11). But it is steadily getting better!
I did like having Interface back in Java-land.
Great talk.But the struct message : private Body::value_type. If the Body::value_type is a constexpr string literal. It will compile failed.
Since we cant inherit from basic type, the body::value_type should have std::is_class guarantee.
Nice talk but nobody talked about the elephant in the room: multiple-inheritance !!! :(
His slides did not use multiple inheritance, but a cascade of generations in a single line. His ideas don't seem to affect MI, and in fact would work quite well with multiple base classes.
Why no one didn't asked about this strange choice to parameterize message with bool?
template
struct message;
It looks nonsense. When in some complex code you want to declare the response message, will you remember, you should specify true or false? Why not parameterize the message with some scoped enum?
enum struct message_type : uint8_t
{
Response,
Request
};
template
struct message;
// in some code...
message myResponseMessage{};
Ok, you can make typedefs at start so you as user don't need to remember what means true or false. But anyway it looks really bad because of its implicitness! Why they chose bool instead of such a dumb explicit and simple scoped enum? HTTP is a human-readable protocol, so why the library is not?
Writing concepts in C++ is such a pain, especially the requiremnts checking template code. Why not just create abstract classes Body and Field with some required methods, letting the user to subclass them and implement those methods? So much easier than inventing concepts in C++.
Well that's a great question. Two reasons: 1. C++ has the "zero-overhead abstraction" principle. Using virtual functions would incur a needless performance penalty. And 2. A virtual function cannot be templated or have a covariant return type. I agree that writing concept checks is a pain but that aspect of the language is being improved through the committee meeting process. The Body template interface is superior and gives benefits to users, so it is worth the trouble of writing those concept checkers (and they were quite a bit of work especially dealing with compiler bugs which inevitably pop up while writing such things).
>1. C++ has the "zero-overhead abstraction" principle. Using virtual functions would incur a needless performance penalty.
If virtual functions go against C++ principles then they shouldn't have been added to the language.
>2. A virtual function cannot be templated or have a covariant return type.
Alright, that's neat.
Virtual functions don't "go against C++ principles" they are useful when the type of an object is not known at compile-time. In this context, there is no penalty to their use. But when the type is known during compilation, the overhead of a virtual function dispatch is unnecessary. Furthermore, the virtual function interface acts as a firewall which can inhibit inlining. In short, the design of the Body concept described in the talk (and in Beast) uses the most appropriate and performant tool for the job. I agree that it is not necessarily the simplest.
It's the requirements
1) generic
2) as fast / low memory as possible
that cause it to be complex in order to be powerful. But I personally think that the C++ syntax is far less readable than it should be. I don't know how you'd _fix_ it, mind you, but I do think that there's a fixation on using the fewest characters possible for keywords that really hurts readability.
[Warning: heresy follows.] How'd you feel about disambiguating const int * const xyz (or whatever it is) as const_* const_int and let the preprocessor or compiler do a text-conversion step before compilation?
@@williamchamberlain2263 LOL That might be a step too far :) concepts are getting a makeover in C++20 so I think we will be seeing much more readable constructs going forward.
I thought for a solid 30 minutes that this talk was ironic. That he would come to a point where he would go: "and by now all of you should have noticed that this is a huge pile of shit and a horrible way to do things". Turns out he actually meant all of it. Well.
haha, I was thinking the exact same thing!
Why would he call his library beast?
Lol, he talks about documentation ... Boost has the worst documentation for the end user ever, because it reads like a specification for someone to reimplement it , not to use it.
The code snippets, if they are correct, are mostly missing the needed include fileenames, and the namespace names. The documentation of the date time library is especially bad.
It is thumb up and thumb down video.
Up for philosophical discussions of choices in code.
Down for making sth my 6 year kid cant use, and I advice against your code any 26th year old.
You making more problems than solving.
I know you cant any other way, just saying.
Beast is not intended for 6th grade use. However, it can be used as a building block to create something that is appropriate for 6th-graders! Perhaps you will be the trail-blazer here :)
Others use grpc.
but you can't get "rich" with grpc ;) as it doesn't do websocket. In other words the browser can't use those api
@@AfterDarknesthe solution is called grpcWeb 😉
This guy talks too fast. Great content, but slow down just a little.
With this much indirection you are not actually solving any real problems.
How so? All of the original stated problems with the first draft of the container were addressed. This solution is shipping in Beast, which many folks find useful for solving their real problems.
All of the problems were solved by delegating the implementation to the user via an unwieldy template interface. The user could have much more easily called write_header() and os.write() themselves. No need for string classes with internal allocators. And please tell me how does unifying the request and response into one class make anything clearer or easier? Request has user provided data so it doesn't need any allocators, and response is something the user at least has an idea of how large it should be so it's not unreasonable to expect the user to provide a fixed output buffer for it (in this one case providing an allocator via function parameters would be acceptable in my opinion but even that could just be a different function call, not a mess of templates).
If you can't trust the user to figure out how they can form a http request using a couple of functions, you definitely can't trust them to figure out an API like this one.
Request has user provided data but internally the request can be allocating additional memory because it might need to store or manipulate the user provided data before serializing it, and those operations can result in internal allocations.
Why would a user have an idea of how large a response can be? By definition, a response is not generated by the user, it's generated by the server and sent to the user. User has no idea how big it might be. Do you propose just overallocating a massive buffer, and then crossing your fingers that it's big enough? And what if it's not, do you return an error and ask the user to then supply an even bigger buffer?
Your solution would probably be fine if you're designing a library that nobody else is ever going to use except your very specific project, but that is exactly the opposite of what a general purpose library like boost needs to do.
It is important to recognize that "users" of such an API fall into two categories. There are your "regular" users, which just want to declare a message using one of the common body types. They won't need to worry about SFINAE, type traits, concepts, or implementation. Then there are the "advanced" users, who might want to author a Body type. It is to those users that the bulk of the presentation is addressed. It is certainly more complex to author a custom Body type, but far fewer people will need to do this. And once someone authors a Body type, everyone else can enjoy using it without having to understand how it works internally.
Sure, when your use cases are abstract the only suitable solution is also abstract. Please, try to imagine a real world situation where the user for example doesn't know the rough the magnitude of response they are going to get. You can provide a fixed buffer OR an allocator to a function without an API nightmare like this.
If your typical user is just going to use the default values (remember this is also likely the user who gets confused by complex documentation and template parameters) you can just provide a simple struct and a simple function for their needs. When they out grow that implementation, they can start to use the function with more arguments, and eventually they can copy your function and modify it as they see fit. I see no benefit in trying to fuse simple and complex implementations.