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.

@leftaroundabout

5 жыл бұрын

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).

@michaelthompson7217

4 жыл бұрын

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.

@michaelthompson7217

4 жыл бұрын

B A especially with generics / templates

@destiny_02

2 жыл бұрын

And 90% of problems/complaints about c++ can be removed by just letting go of backward compatibility...

@AlFredo-sx2yy

2 жыл бұрын

@@destiny_02 then 90% of problems/complaints are stupid and made by inexperienced programmers who dont know what they are doing :)

67 years old, and handles it for almost 2 hours . What I ninja you are Stroustrup

@c0xb0x

5 жыл бұрын

Bernie Sanders at age 69 filibustered for 8 hours. www.washingtonpost.com/wp-dyn/content/article/2010/12/10/AR2010121005431.html

@gongfei

5 жыл бұрын

who has a higher aim?

@Atameow

5 жыл бұрын

@@c0xb0x bjarne and Bernie ftw

@c0xb0x

5 жыл бұрын

@@indubitably5986The purpose was to rectify his image of senescent endurance. You are the one highlighting the irrelevant part of the example.

@prathamyadav3105

3 жыл бұрын

The guy invented C++. What do you expect?

Hello from future, finally we DO have concepts in c++

Only 30 minutes in so far, but this talk has already clarified so much. Always love Bjarne talks.

@CWHolemanII

5 жыл бұрын

That is the point where I clicked the thumbs up.

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.

"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.

Can't come soon enough. I just pray all major platforms will adopt it quickly

What an era we live in! All of these legends who'll live for thousands of coming years....

feels like Christmas ;)

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.

@mrpisarik

5 жыл бұрын

could you advice some articles or whatever on plug and play approach?

@homomorphic

5 жыл бұрын

@@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! ❤️

I won't lie..... I teared up a bit. Pure Happiness from me!!!!

@shadowagent3

5 жыл бұрын

If only Christianity could do the same for atheists.

What a wonderful talking, I love the abstract thought!

Great concepts! Great talk! Thanks

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.

What do we want? THE FUTURE! When do we want it? NOW!

Oh my! It's happening, amazing!!!

The future is now, sparkly man.

They messed up the audio pretty bad. There is quite a bit of feedback / phasing in the mic.

@joeyalfaro2323

3 жыл бұрын

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.

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.

@MSheepdog

5 жыл бұрын

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.

Cppcon 2018! Noice

Bjarne you are a legend but this was too advanced for us mortals. Good progress on Concepts!

@WoWManiak1696

5 жыл бұрын

It was not

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?!

@vonkruel

5 жыл бұрын

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.

@MSheepdog

5 жыл бұрын

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.

@johnappleseed8839

5 жыл бұрын

"Who to believe?!" Believe your own experience! Take advice with a grain of salt.

@MatthewChaplain

5 жыл бұрын

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.

@pooya130

5 жыл бұрын

Herb clarified that he meant during initialization where you get the type also on the right hand side.

He is genius and also good speaker.

Good job thanks Bjarne

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).

well, quick sort can be implemented with only forward iterator and comparable requirements...

Concepts and ranges already work in GCC?

On slide 56, T1, T2 and T3 should be For, For2 and Out.

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?

2001's future, today. Amazing.

I wish we could eradicate the intermediary steps of template metaprogramming and switch to concepts altogether. Use concepts as function arguments and such

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.

19 minutes in and I'm like "so... Go's interfaces then?"

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

Isn't a list merge sortable without extra space? Shouldn't the standard library provide this?

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

great man bjarne )

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

@avis9ditiu

5 жыл бұрын

Tarun Singh you can write this and it compiles

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?

Minute 59 - the number concept would match matrix type as well.

@miyurosewood3837

2 жыл бұрын

Maybe because numbers (scalars) and matrices 1x1 are same, because a ring of 1×1 matrices over a field K is isomorphic to K

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

Upload more videos!

we meet again, David Hilbert

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++.

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.

@liangwang4089

5 жыл бұрын

Enable ifs are horrible to look at and they are strains on the compiler. This could be replaced by concepts.

@JackAdrianZappa

5 жыл бұрын

@@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.

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.

Why is there a picture of LHC in the first slide?

@Kalumbatsch

5 жыл бұрын

It's an example of a C++ application.

@petermcarthur7450

4 жыл бұрын

The coffee machine in the canteen uses C++.

Theres uh, a band...At CPP con.... are they lost??

@noxabellus

5 жыл бұрын

Ali Kouhzadi wow I never knew that, I've watched a lot of cppcon videos but havent seen them before

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.

can anyone tell me any standard concepts that will be available in c++20?

@bjarnestroustrup7067

5 жыл бұрын

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 ;

subtitle please, even only in plain english.. to help his voice clarification.. like you did before in cppcon 2017

@llothar68

5 жыл бұрын

You mean subtitles not translation.

@ridwanhafidh9403

5 жыл бұрын

Ah right .. I mean like that .. edited the comment

@Broekmanium

5 жыл бұрын

Closed captions (CC button) works pretty well on this video.

@PaulSebastianM

5 жыл бұрын

I think he is very clear despite the lisp.

@ridwanhafidh9403

5 жыл бұрын

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.

@micaevski

5 жыл бұрын

i think its feedback in the recording. really annoying

不错！

Are consepts just interfaces?

@Sopel997

5 жыл бұрын

No, they are much more powerful and also compile time

@oj0024

5 жыл бұрын

ok, so they are better interfaces, nice.

@alectoperez1383

5 жыл бұрын

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

@FooBar89

5 жыл бұрын

compile time algebraic types meets interfaces sort of thing

@MSheepdog

5 жыл бұрын

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.

void* is the code smell of lavendar

@Evan490BC

5 жыл бұрын

More like the smell of a lavatory...

Great haircut as always ; *

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:08:25 4chan

requires requires requires? requires.

1:15:55 lmao this guy and his pumpkins

Just make a new language Bjarne!

@JamesJones-iu1ey

4 жыл бұрын

Yup C++ has become a swiss army knife

Rust already has these. C++ concepts = Rust traits. Is C++ going the direction of data driven design?

@JanuarAndaria

5 жыл бұрын

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.

@FooBar89

5 жыл бұрын

concepts are completely different from Rust traits, Rust traits is more akin to abstract classes or interfaces

@TheDucob

5 жыл бұрын

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 ).

@user-sz2hv7jx3k

5 жыл бұрын

@@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).

@Qizot

5 жыл бұрын

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*)

@cicciobombo7496

5 жыл бұрын

@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

@botetescribavicentej.2326

5 жыл бұрын

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 :(

@FooBar89

5 жыл бұрын

because sometimes there is nothing wrong with c style code

@MSheepdog

5 жыл бұрын

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.

@muamersmajlovic2437

5 жыл бұрын

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.

keep it up, thanks😠😠😝😠

Barney Starsoup

This why mathematics is... , What he want said : go back a dig deep in mathematics concepts, algebras, logic , and something of topology.

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.

@jpal00

5 жыл бұрын

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).

@sheldonhawke8868

5 жыл бұрын

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.

@nemetroid

5 жыл бұрын

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.

The Godfather

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~~~

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!