CppCon 2018: Bjarne Stroustrup “Concepts: The Future of Generic Programming (the future is here)”
Vložit
- čas přidán 24. 09. 2018
- CppCon.org
-
Presentation Slides, PDFs, Source Code and other presenter materials are available at: github.com/CppCon/CppCon2018
-
Concepts have arrived. They will change the way we think about programming. Implementations are available in GCC and Clang. Many fundamental concepts are in the standard committee’s working paper and the next generation of the STL depends critically on concepts.
After briefly introducing concepts, I consider their role in design. What makes a good/useful concept? How do you design good concepts and use them well?
From a language-technical point of view, concepts are a way of constraining template arguments. From a design perspective, they are a focus comparable to user-defined types (classes): The intent is for a concept to represent a fundamental concept in an applications domain (hence the name “concept”).
I will mention technical issues recently resolved or currently being resolved in the committee, but my primarily focus is not concepts as a language mechanism but as a support for the development of good software.
-
Bjarne Stroustrup
MD, MorganStanley
C++: history, design, use, standardization, future; performance, reliability; software developer education; | distributed systems | Bio: www.stroustrup.com/bio.html
-
Videos Filmed & Edited by Bash Films: www.BashFilms.com
*-----*
Register Now For CppCon 2022: cppcon.org/registration/
*-----*
67 years old, and handles it for almost 2 hours . What I ninja you are Stroustrup
Bernie Sanders at age 69 filibustered for 8 hours. www.washingtonpost.com/wp-dyn/content/article/2010/12/10/AR2010121005431.html
who has a higher aim?
@@c0xb0x bjarne and Bernie ftw
@@indubitably5986The purpose was to rectify his image of senescent endurance. You are the one highlighting the irrelevant part of the example.
The guy invented C++. What do you expect?
Hello from future, finally we DO have concepts in c++
15 mn into the video... One thing that has kept me with C++ since I started using it about 20 years ago is this... A constant critical look at the language by the users and creators and a wish to make it better. "Horrible error messages"... This shows a very sane and healthy stance that I believe will allow C++ to mature and progress for quite some time.
Yes, though the really astonishing thing is how they managed to do this without ever really breaking backwards compatibility. Mind, the developments have been slow. Concepts could have been here much earlier. Haskell has basically had them for 22 years now (called typeclasses).
I used to fucking hate c++ but now I love it. I love how it’s driven by engineering decisions and not perfection - it’s what has made c++ so widely adopted. This attitude is part of that.
B A especially with generics / templates
And 90% of problems/complaints about c++ can be removed by just letting go of backward compatibility...
@@destiny_02 then 90% of problems/complaints are stupid and made by inexperienced programmers who dont know what they are doing :)
Started thinking about concepts even before they arrived. I saw them in Haskell and found that found that it's absolute solution for problems we have with templates. Because I hate to involve inheritance.
Only 30 minutes in so far, but this talk has already clarified so much. Always love Bjarne talks.
That is the point where I clicked the thumbs up.
"The ability to add things is not a fundamental thing for a large group of things." One of my favourite quotes.
Wow I can't believe it's actually officially happening for real now... I'm so happy!
At my school we've been required to understand and re-implement enable_if. I'm traumatized for life. I'm considering running off to a hippie commune and programming Python.
I totally agree with Bjarne on concepts and the use of them, specifically the idea that we should encourage plug and play over constrain-ability.
could you advice some articles or whatever on plug and play approach?
@@mrpisarik "plug and play" is not a thing, it is an aspiration. If you watched the talk, Bjarne took a question that pointed out there are corner cases where certain constraints are impossible to enforce in the context of concepts. Bjarne's position (and mine) is that the presence of these corner cases is not reason to conclude that the design of concepts is lacking.
Appropriate application of concepts yields architectures that are both highly interoperable and type safe, and we should not let concerns over some specific edge case where a constraint can not be adequately imposed, diminish the enormous advantage of that interoperability and generally exceptionally high degree of type safety. We should favor features that improve type/algorithm interoperability when doing so requires that some specificity of constraint must be sacrificed.
What a great master, for a great language! ❤️
feels like Christmas ;)
I won't lie..... I teared up a bit. Pure Happiness from me!!!!
If only Christianity could do the same for atheists.
What an era we live in! All of these legends who'll live for thousands of coming years....
Can't come soon enough. I just pray all major platforms will adopt it quickly
What a wonderful talking, I love the abstract thought!
I can see more expressive functional programming styles in c++ enabled through this. Having a filter for how data/types are allowed to be transformed will make it easier to write code as data transformer, tied closely to the actual problem at hand.
I always find Bjarne's talks to be well worth the time. Although I haven't yet written any code using concepts I'm fully convinced of the benefit. I appreciated his point about not expecting to completely nail your concepts from the start. What matters at the start is that you create concepts that make sense and provide actual utility. By giving a name to a valid & useful concept you've made it something you can work on, and all users of the concept will get the benefit as you constrain it more precisely. I don't sympathize with any hand-wringing about concepts. It's a big step forward.
Yeah it even makes sense when throwing something together to come back to later.
bool Serialise(Serialisable*, Stream*); // where Serialisable and Stream are concepts
is clearer than
bool Serialise(T*, U*);
even if Serialisable and Stream are currently unconstrained concepts.
Can hack something together giving them those names then go in later to constrain the types as needed once you've figured out exactly how you want your stream class to work.
Great concepts! Great talk! Thanks
Cppcon 2018!
Noice
Oh my! It's happening, amazing!!!
What do we want?
THE FUTURE!
When do we want it?
NOW!
Bjarne you are a legend but this was too advanced for us mortals. Good progress on Concepts!
It was not
They messed up the audio pretty bad. There is quite a bit of feedback / phasing in the mic.
I had cheap pair ear plugs said their has to be better way Google play store has bass booster. It's baby equilizer. I highly recommend it.
The future is now, sparkly man.
My favorite lang is the C++, but this speech is not only about the futuristic C++, it is a motivation to modernise our thinking about the future of the computing in general. Thanks Bjarne for wonderful presentation.
Herb: "auto almost always". Bjarne here: "auto has been overused". Cards on the table - I like auto. If I'm having to flip to a header it's usually so that I can see which header to include, which is a language problem that has cursed us for decades. Is the use of auto subjective then? Who to believe?!
I think he meant that a concept name could be a better choice than the use of auto sometimes, so along with concepts comes the need to question the use of auto a bit more. So "auto almost always" might not be quite right anymore. But if you can honestly say to yourself "a concept won't help here", and there's no other valid reason not to use auto, by all means use auto. I'll continue to use it quite often myself. Usually when I use auto it's not even in a generic programming context, and I know for sure what the actual type will be.
Like most things it's a tradeoff between readability and flexibility.
vector v = Fn(); // reader can see what v is giving them a clue as to what might be done with it, but Fn() can't change return type.
auto v = Fn(); // reader must look at Fn() to see what v is, doesn't express any special intent.
Container v = Fn(); // reader knows v has some foo's in it. Actual container type doesn't matter.
"Who to believe?!"
Believe your own experience! Take advice with a grain of salt.
With respect, I see this argument all the time, and the problem with it is that it falls flat on its face the moment the function in question is named something sensible. E.g. GetVersion() had better return the type that is your API's version abstraction, and SetVersion() had better accept something of that type. IncrementPatchNumber() had also better accept something of that type. You don't need to know the concrete type in order to do this, or even to know what's going on. If that's not true for your code, then your API needs a second look.
Herb clarified that he meant during initialization where you get the type also on the right hand side.
2001's future, today. Amazing.
He is genius and also good speaker.
Concepts and ranges already work in GCC?
Good job thanks Bjarne
Great talk from Bjarne, certainly taking time to explain concepts and their relevance in evolution of generic programming. However didn't get much info on #include
I wish we could eradicate the intermediary steps of template metaprogramming and switch to concepts altogether. Use concepts as function arguments and such
Overloading, from sqrt 2 to sort list, is essentially DWIM is it not? Is that really a good underpinning for generic programming? Will this invite surprising cases or is it actually more ergonomic?
On slide 56, T1, T2 and T3 should be For, For2 and Out.
well, quick sort can be implemented with only forward iterator and comparable requirements...
46:20 having the accumulator defined as Number instead of an Addable is unfortunate. It means for example that you can't accumulate Vectors (which aren't numbers and can't be multiplied by a vector).
Isn't a list merge sortable without extra space? Shouldn't the standard library provide this?
Upload more videos!
No, I realised that it still would be nice to have more strict concepts that catch all errors in body, because it would allow to catch more errors and also compile concept function in binary by providing in function bunch of pointer to methods for parameter ... With less constrained concept it is harder to do
great man bjarne )
1:26:31, so true. It's kind of in our DNA to be pessimistic. Developers who assume things are going to work well don't stay developers long :-).
So we invented OOP to unite structure and behavior, then (among others) concepts to separate them again.
I think C++ is duplicating all its terms and tools because its type concept is flawed. It requires a type to include a definite data structure and even a structure for operations, i.e. behavior. Then it uses types to constrain algorithm parameters. But algorithms don't always require their parameter to have a specific structure. Now generics and concepts drop structural requirements altogether.
Just make types what they are actually used for: parameter constraints. Those can be structural (without necessarily being a specific structure) and they can be behavioral, and they can be any mixture of those. But in the end, they're still just (abstract) types.
More and more terms and tools to patch shortcomings of existing ones won't make a clunky syntax elegant, and it also won't make a complex philosophy simpler.
Add. Requirements, like concepts, may express relationships rather than properties. Types don't seem to have that capability. However, if two parameters have related types, most often they also have related values, and you are probably better of with a single parameter capturing the same information. Example: a single range parameter instead of two related iterators.
Nice explanation.I have doubt on iterator Why we need to provide specialization in iterator
template
void process(Iterator begin, Iterator end)
{
for (; itr != end; ++itr) {
process(*itr);
}
}
why i can't write
void process(Iterator begin, Iterator end)
{
for (; itr != end; ++itr) {
process(*itr);
}
}
please explain
Tarun Singh you can write this and it compiles
After having watched both this presentation and Herb's on meta-classes, I can't help but build a mental image of concepts as a form of specification, analog to abstract interfaces in the run-time world, with associated implementer meta-classes which would take a partial (or even empty if applicable) corresponding concept implementation and bring it to full completion. I know of a similar "abstract classes" model in Python, won't be surprised to discover such things in other languages too.
Minute 59 - the number concept would match matrix type as well.
Maybe because numbers (scalars) and matrices 1x1 are same, because a ring of 1×1 matrices over a field K is isomorphic to K
19 minutes in and I'm like "so... Go's interfaces then?"
Why is there a picture of LHC in the first slide?
It's an example of a C++ application.
The coffee machine in the canteen uses C++.
we meet again, David Hilbert
Does bjarne change his mind every year? I thought I have listened to a talk where he claimed "almost always use auto". But now it's a code smell?
28:28 there's no place in a constructor
to use an enable_if.
What? What about:
template class Pair {
// ...
template
Pair(const TT& const UU&);
};
Kinda surprised that he made that statement.
Enable ifs are horrible to look at and they are strains on the compiler. This could be replaced by concepts.
@@liangwang4089 when concepts become available. Until then, this is what we have, and it does work. I'm just saying that his statement was false, or maybe glossed over.
Can we literally calculate the types with the same grammar with which we calculate number and deal with std::vectors? And also print it into cout or something?
Anyway, concept and constrains are already good enough. STL is not very usable only because it's based on template. When I use anything from STL, the only hope is figuring out the correct code with pure guessing or find any example from internet. The error message literally equals nothing, even on my favorite VS 2019. That was painful. Also, when a function can receive a parameter as value and also as ref, it has to be decleared with template, but this solution is also so ugly. It literally forces people to check every template parameter to see if they are designed to receive a value or a ref or pointer or anything possible.
At last, thank Typescript for providing us a better c++.
can anyone tell me any standard concepts that will be available in c++20?
From the current working paper (more coming for algorithms):
17.3 Header synopsis [concepts.syn]
concept Same = see below ;
concept DerivedFrom = see below ;
concept ConvertibleTo = see below ;
concept CommonReference = see below ;
concept Common = see below ;
concept Integral = see below ;
concept SignedIntegral = see below ;
concept UnsignedIntegral = see below ;
concept Assignable = see below ;
concept Swappable = see below ;
concept SwappableWith = see below ;
concept Destructible = see below ;
concept Constructible = see below ;
concept DefaultConstructible = see below ;
concept MoveConstructible = see below ;
concept CopyConstructible = see below ;
concept Boolean = see below ;
concept EqualityComparable = see below ;
concept EqualityComparableWith = see below ;
concept StrictTotallyOrdered = see below ;
concept StrictTotallyOrderedWith = see below ;
concept Movable = see below ;
concept Copyable = see below ;
concept Semiregular = see below ;
concept Regular = see below ;
C++0x is here
28:00 These are unfortunate examples - I believe both of these are unproblematic even in plain c++03. Converting of the arguments of the constructor is handled by the language and applying a -> to a non-struct would bomb with a quite understandable error message.
Theres uh, a band...At CPP con.... are they lost??
Ali Kouhzadi wow I never knew that, I've watched a lot of cppcon videos but havent seen them before
Are consepts just interfaces?
No, they are much more powerful and also compile time
ok, so they are better interfaces, nice.
Sopel997 they're much broader than interfaces because you can use a contract to specify how two or more different types should interact. In addition, they're implemented very differently under the hood. An interface contains some virtual methods, and so types must inherit from it. But a concept merely specifies which methods or functionality must exist, and you don't need to derive from a concept (or even know it exists). An int primitive would satisfy the Number concept, even though int isn't even a clasd
compile time algebraic types meets interfaces sort of thing
Apart from the whole compile-time vs run-time thing, interfaces are intrusive where concepts aren't. So to implement an interface your class needs to explicitly say it is one of those things, but if it matches a concept it already is that.
Means you can express things as concepts without having to go through all your headers and explicitly add it to all the matching classes.
subtitle please, even only in plain english.. to help his voice clarification.. like you did before in cppcon 2017
You mean subtitles not translation.
Ah right .. I mean like that .. edited the comment
Closed captions (CC button) works pretty well on this video.
I think he is very clear despite the lisp.
thanks
The audio sounds like it is badly encoded. Well it does not affect the content by any mean. Bjarne's voice is heard loud and clear. It's just a little bit annoying.
i think its feedback in the recording. really annoying
void* is the code smell of lavendar
More like the smell of a lavatory...
Great haircut as always ; *
不错！
requires requires requires? requires.
What, Bjarne doesnt know what Duck typing is, and thinks it is something bad??? What.. Templates have no real type system without concepts, not duck-typing which is a type of type system.
1:15:55 lmao this guy and his pumpkins
This why mathematics is... ,
What he want said : go back a dig deep in mathematics concepts, algebras, logic , and something of topology.
1:08:25 4chan
Just make a new language Bjarne!
Yup C++ has become a swiss army knife
Barney Starsoup
keep it up, thanks😠😠😝😠
Rust already has these. C++ concepts = Rust traits. Is C++ going the direction of data driven design?
38:35 Concept in C++ is older than Rust. Concept already used witt ugly syntax like a lot of enable_if. One of benefits of this standardized Concept is make syntax more readeble.
concepts are completely different from Rust traits, Rust traits is more akin to abstract classes or interfaces
Rust traits are closer to templated interfaces, which is a lot like concepts IMO. You also have trait bounds and generic trait implementations, which are even more powerful. The big issue with Rust generics right now is that they're lacking const-generics (think template ).
@@FooBar89 No. Trait objects are similar to interfaces/abstract classes (because of late binding), but traits itself are similar to concepts in c++ (both of them are resolved at compile time and implemented with the help of monomorphisation).
so go use your rust then and wait for everyone to start using it...
I still wonder why c style code isn't deprecated yet.
Make the compiler spit out an error *by default* when you create a owning raw pointer or a c-style array ecc, with a suggestion in the error itself for a replacement. Adding then a compiler flag if you really need C compatibility.
A lot of this talk was about making code more meaningful, simpler and smaller. Having the compiler yelling at you to use std::array instead of name[] would make it easier for a beginner to start writing modern correct c++( the former has array *in the name*)
@Peterolen that's the point, a lot of people don't even know what clang-tidy and compiler options are. They just download VS2017 and start writing messy (probably) garbage code, and some of those habits may then persist in the future.
It should be there by default, then if you know what you're doing you can disable it
How would you define your own class that do e.g. a static vector that is a POD and .... You need the low level to build the high level. As other said, you would need to adapt some lint like tools as clang-tidy or request you compiler provider to provide this kind of features. But the language cannot forbid them because they are really useful and removing them would break a lot of code :(
because sometimes there is nothing wrong with c style code
This is the sort of thing you get when you turn on all the static analysis tools, I tried it recently in Visual Studio to see what suggestions it had. Sometimes there was things that could be improved, but lots of times it was flagging things that were far better or nearly impossible to change.
In particular if you're writing any of your own container classes or string manipulation functions or even your own kind of smart pointer, these things rely on the low level functionality.
If you're a shit programmer who thinks the newer style is better, compiler doesn't want to ruin the capability of the programmers who write C style code.
C/C++ is "AMAZING" language~~~
59:24 - That's a disaster. So this feature is yet another syntax sugar that does not add anything to the type system.
I believe it would be a nightmare to actually check that the concept requirements are sufficient for instantiation (however nice it would be. You could for example compile template code to machine language and call it, with any possible parameter type, with some boilerplate added).
Concepts are designed to work just like templates, which means you have to consider argument dependent lookup for instance, and that means you'd have to bind it early (which is a deviation from the norm in template code) if it wasn't specified in the concept.
That would shift C++ more to the purely functional languages where basically the type specification is as long as the program itself (but then, if it type-checks, it will likely work).
Haskell typechecks generic code, Rust too, as well as many other languages. Why would it be a nightmare to do so in C++? Also, you don't need "type specification which as long as the program itself" to write generic code in Rust or Haskell.
Yes, typecheck in generic code would be not compatible with "just templates", because they are basically untyped. But do we really need this compatibility?
Concepts in current form solve nothing - "compile-time duck typing" is still a thing. They only make it a bit less painful to do the work that compiler should do.
I was also disappointed by the lack of definition checking. From a C++ perspective, it still makes some sense, since it will *let* you be explicit about the requirements on the template parameters (though I would have preferred if it had forced you to do so). Easing the horror that is template instantiation error messages is probably worth its own syntax. However, from a Haskell/Rust/etc. perspective it looks more like templated unit tests than a tool for actually guaranteeing correctness... I.e. it only seems to make sense if you consider what it's supposed to replace, which I don't think is a good thing.
Sir Stroustrup~~~
He is one of the most remarkable genius in the world in our time.
Although, another genius, sir Ritchie has gone, He(Bjarne) is still with us(and Dennis is in our memory).
Praise him~~~
Praise sir Stroustrup~~~
Praise sir Ritchie~~~
The Godfather
he kind of thinks of concepts like java/c#’s interfaces
Wow, welcome to the past C++. D has been doing this since 2008?!
Just Code in C all this is bull shit that waste your time!