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
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.
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.
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!
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.
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.
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.
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.
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!
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?
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
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.
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.
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.
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 :)
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.
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.
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!
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.
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?
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.
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.
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.
