Can C++ be 10x Simpler & Safer? - Herb Sutter - CppCon 2022
HTML-код
- Опубликовано: 19 окт 2024
- cppcon.org/
github.com/Cpp...
---
Can C++ be 10x Simpler & Safer? (Simplifying C++ #9 of N) - Herb Sutter - CppCon 2022
Since CppCon 2015, all of Herb’s talks have been about ways to evolve C++ to make it simpler, safer, and more toolable. Every release of ISO C++ has already been making regular incremental “10%” improvements in these areas. But what are the fundamental factors that limit our rate of improvement, and what would it take to make greater progress? Like every year, Herb’s talk will explore selected current pain points and describe experimental ideas to address them that might someday contribute toward C++’s long-term evolution.
---
Herb Sutter
Herb is an author, designer of several Standard C++ features, and chair of the ISO C++ committee and the Standard C++ Foundation. His current interest is simplifying C++.
---
Videos Filmed & Edited by Bash Films: www.BashFilms.com
RUclips Channel Managed by Digital Medium Ltd events.digital...
#cppcon #programming #coding
Matt Godbolt is such a legend, adding support for cpp2 to compiler explorer during the talk.
1:43:38
Having such simple compiling instructions definitely helped, imagine if it had a bunch of dependencies, that wouldn't have been possible.
Dijkstra and Wirth spoke negatively about C++. Stroustrup lobbied C++ at that time. At fact I agree with some dudes claiming Stroustroup is far from good designer.
@@josephlagrange9531 i have been thinking about dijkstra’s comments regarding complex languages. I use cpp because it makes things easier like generic programming and abstracting away lots of complexity to clearly express your ideas without loosing performance, but he obviously was onto something when he was in for simpler languages, and I think everyone would prefer a magical simple language like scheme but expressive as hell. Maybe we are too far away from that, hopefully not by hundreds of years.
@@josephlagrange9531so you're a good designer huh
I have literally dreamed of this exact idea. I'm so amped at the prospect of this becoming real. 🤞
Herb Sutter, as always, proves that he deserves our respect.
If you know the C++ Comittee you know it will not become real before it's too late. It's 2022 and we still have no UTF-8 charset conversion handling.
Funny how he does everything the C. Muratori/J. Blow crowd is advocating, even to the point where he didn't add classes in his transpiler yet. But watch how they still sh!t all over cpp2 no matter what...
@@llothar68 unless I'm misunderstanding what you're saying, we have? Since c++11 we've had std::codecvt specialisations that convert to and from UTF-8 explicitly, and we also have the null terminated multibyte stings library which while not explicitly UTF-8 is effectively always going to be because that's just the most common multibyte encoding in use
@@llothar68 Dijkstra and Wirth spoke negatively about C++. Stroustrup lobbied C++ at that time. At fact I agree with some dudes claiming Stroustroup is far from good designer.
@@josephlagrange9531 Why copy-paste your comment all over?
This is soooo much more promising than Carbon IMO!
It's more opinionated (by one person) and farther along, and it does speaks to me. But carbon could become good too, we just don't know yet afaik.
These initiatives do illustrate that ppl want something breaking from C++ if 2 such similar (popular) initiatives exist (and probably others like Circle).
Carbon did the important task of breaking from the crowd and saying, yes, it is time for a new language to supplant C++
and it needs to come out of the C++ community itself so that the concerns that the community cares about in a language are addressed
I think Carbon borrows some good concepts from Go, while throwing away the garbage.
@@frydac dont forget, its made by google. They might kill it at any time if it does not seem profitable.
@@frydac Well, Carbon makes it easier to highlight (or just find by eye) symbol declarations. Herb promises that he can write a context-free grammar, but it's fragile and any future change has to be careful not to make the parsing more complex. With keyword-first principle, we guarantee the grammar will be (and stay) simple in this respect.
This is the first "alternative" I've wanted to learn. Thank you for the dream of a better, way less complicated future.
Glad you like it!
Ever since I saw that one talk by Herb on an actual good way of passing arguments, that talk never left me as I thought about it again and again, and now I can't describe how happy I am to see Herb still keep actively pushing C++ towards this direction of simplifying it. I even shed a tear at some point watching the talk and I believe it means a lot to the whole C++ community as it does to me, so I just wanna say thank you a million to Herb for doing this fascinating job of actively and sincerely trying to make our world better
Link to talk?
Which is the talk about a good way of passing arguments?
@kodirovsshik Thank you for the kind words, I'm glad you find it a promising direction!
@@domenicocipriani604 @loarto You can find the parameter passing (arguments) in the second half of my CppCon 2020 talk... the links are here: github.com/hsutter/cppfront#2020-parameter-passing
@@loarto ruclips.net/video/6lurOCdaj0Y/видео.html
Finally, after YEARS of warmup, Herb Sutter finally says it: if C++ is so good, why isn't there a C++ 2?
Dijkstra and Wirth spoke negatively about C++. Stroustrup lobbied C++ at that time. At fact I agree with some dudes claiming Stroustroup is far from good designer.
@@josephlagrange9531so you're a good designer huh
@@josephlagrange9531 It's a language that is designed by starting with a practical but very limiting in design terms premise - take C and make it more expressive and more useful while keeping it seamless. But it's also exactly what allowed it become so successful. You can't blame the designer for doing what had to be done.
For competition there was ObjC but the performance was not great, turns out gluing Smalltalk to C you get the drawbacks of both. C++ manages to be more than the sum of parts, which is not so trivial, and the better designed languages heavily lean on hindsight experience of C++.
Wirth designed languages, where are they now? They've never been flawless either.
The language grew unwieldy at the stage when it was already being designed by committee, so blaming it on one guy is a little silly. Something as important as C++ emerges, you simply don't get to keep dictatorship over it.
@@ryleitdept i would be inclined to believe that a random stranger on the internet could design a better language than c++
@@ryleitdept No, he doesn't have to be. You don't have to be a good film creator to be able to tell if a movie is good or bad.
This is exactly what we need in the world. I started learning Rust because of the amount of work I'd need to do to go from "my code compiles" through to "and now it's not a pending lawsuit". Rust is not for everyone, so I'm really happy to see C++ moving towards a world where it catches up to (and hopefully exceeds!) Rust's ergonomics and safety.
Why programming on c++ gives you a lawsuit?
Rust is a moronic language.
If you're thing is safety, WHY THE HELL WOULD ALLOW SOMETHING LIKE THE UNSAFE COMMAND?
All the problems (and benefits) of C++ is how many features there are and how there's always a way around their restrictions.
Why move from a language that allows anything to a language that allows anything.................with far less libraries.
Rust hasn't solved anything.
Also ergonomics is super relative.
@@robrick9361The whole point of unsafe is to isolate essential but uncheckable low level operations to compartmentalized blocks that can be more easily reasoned about and verified by hand (functions, modules). Good C++ design already follows the same principle (References/Smart pointers vs pointers, Range for vs raw for, collections vs raw new/delete). The only difference is that Rust has stronger compile time checking to enforce this compartmentalization.
As for ergonomics, while it is true that it is partially determined by preference/experience, there are objectively more ergonomic ways of programming, otherwise we would all still be using assembly. Rust does have features that make it easier to express your intent than C++, such as sum types with pattern matching.
And as for solving no issues, you should go ask Google, who have observed a staggering reduction in memory safety violations in the parts of Android that have been written in Rust, or Microsoft, who are investing heavily in Rust support for Windows, or Mozilla, who's multi-threaded CSS renderer project failed multiple times before they successfully reimplemented it in Rust, that "Rust solves nothing". I'm sure they will find it very amusing.
@@robrick9361 Because rust got it's start on LLVM which needs interop with C. Even then, you have to explictly go out of your way to make "unsafe" Rust code. You're so hyperfocused on a "GOTCHA" that you missed the fact Rust has a way better toolchain than cpp. Better package manager, better syntax, Composition over inheritance, the list goes on.
@@robrick9361 better a 10-line unsafe code block than a 10,000-line unsafe codebase
Very nicely done, Herb! This approach not only bypasses the backwards-compatible limitations baked into C++ while still allowing mixing code, but keeps the language feeling like a refreshed C++ instead of something completely new. I think this compromise will be a appealing to many C++ developers. I think Rust is an excellent alternative to C++ (and is available today) but comes at the cost of learning a different way of thinking about memory safety and interoperability headaches with C++. Carbon is another experimental language trying to overcome these issues with a new language that prioritizes compatibility but is not familiar to those coming from C++. I suspect cppfront will be an easier sell to those currently heavily-invested in C++ but want more simplicity and safety guarantees.
This really is quite good! I've been waiting years for someone to reduce complexity in C++!
Even a luminary like Scott Meyers had lost hope years ago. In his last few public talks back in 2017 (that are available on his website), it's very clear that he had enough. In one of his talks (at Dconf), he said that he was still taking engagement talks as long as it wasn't about C++, and that the C++ design committee didn't really care about the creeping complexity. I think that one is a bit harsh but it speaks volume as what he thought about the evolution of the language. Herb's experiment is a stroke of genius, as it is both the disruption that is needed and the continuity and back compatibility that is a requirement.
With committee that is so focused on backward compatibility, there won't be any progress in C++. It needs a serious redesign. Like a dozen or so new keywords and removal of non-intuitive bits like initializer lists. Templates need a serious redesign to be more readable. And so on. It needs a massive purge to be a better language.
This is not just a fascinating idea/experiment, but may even fall into the "essential for continued language evolution" category! I really hope it succeeds
I think C++ is on life support. Hardware is at the point where you can create GUI apps (yes, I know C++ is a systems programming language) much more rapidly in other languages and still have acceptable performance, than you ever could with C++. That it's still difficult for beginners to the language to install and link to GUI frameworks/libraries in C++, is a real hindrance.
@@atlantic_loveyou realize that game development is still C++ most of the time? Rich client apps are on the way out, games are here to stay.
@@mx2000 Rich client apps are not on the way out. Only the ones which require no computational power.
That's a good chunk of them, but certainly not all.
What I like about that is that you can install Linux on someone's computer and he won't be able to tell the difference if he's a office / web user.
@@atlantic_love C++ is a mess, programming language without any idea expressed with good design, see the list of wishes from Stroustrop books where Stroustroup listed some items for himself about what the language needs to be like.
@@atlantic_love Yes but when you have large data sets you have a good C++ optimization and memory control. Performance is still king and never fast enough.
Wow, I didn't realize there would be cameras on the mic stands! Super glad I was able to twist Matt's arm into hacking support into Compiler Explorer before the talk was over - your reaction was priceless 😄. Thanks for a great closing keynote as always.
In addition to his technical skills, Herb is an excellent presenter and leader.
It's great that Herb is doing this. I am designing a way to do this in C, but once it's done, no one will know or care about it except for me. When Herb is done, it has a good chance of actually going somewhere. Even if not in the standard, there's no way it doesn't get a community behind it after this talk...
This is super exciting. I'm a Rust engineer & I love Rust, but I would also love to see C++ become modern & safe so that we can all build better software with less headaches.
I love this. It definately took a rust-like approach to compiler warnings / errors, which is great. Not only are the messages clear and they tell you how you can fix your mistake, but it also helps keep safety within c++ programs. I also enjoy some of the "syntactic sugar" resembilng some of the newer programming languages. I also never knew about the whole NSA ordeal with type unsafety and them advising against c & c++. Thousand Thanks to Herb Sutter And cppcon
Amazing work Herb. I now again have hope for C++'s future. Also, very good point in the end about naming the syntax cpp2 explicitly. Human nature is one of the reasons there is still so much confusion about the language.
I've always believed this style of syntax versioning to be the correct way forward. Count me in!
I cannot describe how much I loved every single part of it, only then to be crushed how literal perfection is gonna be stained by (1:24:55) the confusion that is gonna be caused by an empty return in the function that is supposed to return certain values (though, to be fair, it’s gonna be so freaking convenient at avoiding the little annoyance of repeating the structure shape, that I’m gonna use it anyway. Just like I use the ternary operator where it completely screws the code readability)
This could be a gamechanger in terms of reducing complexity. Hyped to see this come forward!
I'm amazed that Herb Sutter after so many years is still going strong, still is thinking cogently, and even looking much younger than his years. Kudos.
This is literally like a dream come true. More than once I've written fake cpp code in an empty editor just to imagine what a unified function syntax would be like, what a unified paramter passing paradigm would be like without all the const ref crap. There is an echo in my soul that this just makes so much sense, and I beleive it is a common feeling among many cpp coders. Yet cpp toolchain always felt like a behemonth that's too big and too complicated for a lone developer to tackle on. So a great many lone developers are left to just imagine what's possible. It really need someone like Sutter to push this venture. Please make this happen. Sutter is like jesus reborn for cpp.
Really amazing what he was able to accomplish with basic principles. I really look forward to a CPP future like the one he displayed in this talk.
I have been wanting cpp2 for a long time. It is much better than I imagined. Would love to see it succeed.
Promising evolution, this transformation became inevitable, good luck Dear Herb ✌
That's just a fantastic idea! As Herb said, he wants to teach people more about how to program instead of the details of C++. So and I want to program more instead of learning about quirks of particular syntax/semantics of C++. Herb, you have full support of the random dude from the internet!
Fantastic, I don't need backwards compatibly for my green fields programs. And I may not need to learn TS, if this can run in the browser with decent screen IO. :) Thanks to Herb for his long term efforts.
so modest. i've got a feeling this is going to be a historical talk.
Much respect, Mr. Sutter. I will keep an eye on this; amazing work.
Much appreciated!
Herb is such a BOSS! I hope this experiment leads somewhere - it'd make me get back to being a C++ developer again.
learnt alot of c++ by just watching this video... kudos Herb for the effort and all the best with this very worthy experiment
It is very surprising how much can be improved while being tethered to syntax1 code generation. Fantastic work.
I love it. I can't wait to start using it.
The safety idea of showing errors and giving exact solutions for standard recommendations is really good.
I have been ranting for years why C style arrays and pointer decay kills the consistent value semantics of C++
This idea of doing away with pointer arithmetic is absolutely the best thing.
Also uniform syntax!!!
Even if it doesn´t succeed, you have created an awesome new language!
It's been a long time I've done c++, but that got my attention back. I could imagine something like this being the default and you can enter "unsafe mode" like in other languages for the "old" c++ style.
I find the idea of the gargantuan and ugly monster that is C++ continuing to evolve for another thirty years terrifying.
I've been avoiding C++ in projects because of all the complexity and the chances to fail miserably. But this looks pretty good!
I have one important question though: Why not `const` as the default for everything everywhere? I am a firm believer in "the laziest solution should be the best", so adding sth like an explicit `mut` instead of `const` would fit that paradigm.
I guess Herb simply didn't implement it yet.
I agree, many people have the sentiment that mutable by default was a mis step, but to correct it now would break the world. However with cpp2 that isn't a concern anymore. It could even be a flag if there was any strong pushback against it.
@@Firestar-rm8df A flag would mean you can't look at the code in isolation and figure out the meaning. Flags shouldn't be able to change semantics like that, I'd say.
@@Adowrath There are already plenty of compiler flags that can change behavior. and preprocessor macros. That's why flags and build scripts are often checked into your repo with the source code as it is a part of your code, just at a higher level of abstraction. -fno-strict-aliasing for example. I'm not saying this is a good thing, I'm saying this is how it is and we wouldn't be any worse off, and having the flag you can set is better than requiring everything to be mutable by default. Also, I imagine you would likely get a compile error if you toggled the flag for a code base erroneously as const-incorrectness simply doesn't compile, which is the beauty of const.
@@indiesigi7807 do you know anything about clean code? You should const everything, and having it as the default is even better. An optimal program would be completely made up of constexpr statements, so that only the I/O is not const
Thanks for providing this talk! He already had me at nodiscard is a default. I think this experiment will decide about the future of C++. It has reached a level of complexity with a bunch of optional but actually essential rules to follow, that makes it unappealing to work with. Especially if you compare it to younger languages with all these features baked into the language standard. I hope this will bring C++ to a state of the art level.
Amazing work! Hope this will get a future!
This is a gold mine of explicit ideas for doing a C-2.
I'm amazed. Really hope this project works out.
Onece I'm finished my thesis, I'm going to start working on LSP and treesitter for this (with Neovim support in mind). If this reaches escape velocity, it's going to be huge. A transpiler isn't as exciting as something like Carbon, but I think this is the right increment to move forward.
I wouldn't call that mess of Carbon exciting... Carbon was the main reason why it took me so long to view this video and take it seriously.
Carbon from where I stand seems more like a disease while such project finally feels like a benefit to both C++ and programming in general.
I'd love to see your transpiler in action but please don't ever implement yet-another-useless-new-language-that-should-stay-in-the-lab-and-instead-extend-C++-with-its-one-trick-pony-feature.
@@DerDoMeN Thanks for your comment. Just for clarity, when I was mentioning a “transpiler”, I meant Herb's. It seems to me that `cppfront` is (right now) a transpiler from Herb's Syntax 2 to ISO C++ and STL + cpp2.
I was only talking about implementing some tools (a language server and treesitter support) for it.
How about cppfront being a compiler flag for GCC or clang or MSVC, similar to "-std=c++XX" ? Then potentially it would feel like a built-in part of the language. And since parsers are generated anyways, we could easily go from [Cpp2->Cpp->IL] to [Cpp2->IL].
The solution cannot possibly be to kill C++ by creating a new language, as that does not solve any existing problems but potentially creates several new ones.
And C++ is too complicated for practicality in the future.
Anyone who would do the same research that Herb Sutter has done, would likely arrive at the same conclusion (or a very similar one).
@@007LvB think the other way around, that's exactly cpp2. With cppfront, you can either write in pure cpp2 or mixed cpp1 and cpp2 and as time goes by, there def would be support for more things
I' m so touched by this talk, thank you Sutter!
I love the syntax of cpp2. And loving the all the features of herb trying to make, light weight exception, static reflection, metaclass, gc support. It will kill C++ dialects like UE C++ and QT C++ which is amazing. But something I miss is that some kind of ambition that make people thrills. I really wish that circle, carbon, val and cpp2 get marry somehow. We need better mechanics for meta programming. We need better approach that make evolution process faster. We need compile-time memory safety built-in to the language. We, C++ programmers need some features that make us claim proudly that we are at front of PL rather than C++ won't die because of backward compatibility.
There was something completely missing, and not even mentionned in the evolutions: templates. I wonder what thoughts he has.
It is not going to kill UE C++, the reason UE CPP exists is because it is tightly integrated to UE's Blueprint system. It does more than just making CPP safer. That being said, It would go a long way on making UE CPP simpler. So end result would be something like UE CPP2 where you still have Blueprint extensions but built on top of CPP2 instead
@@lolilollolilol7773 I thought ‘_’ for the type made it a template. Relatively early in the talk - it was quick.
@@lolilollolilol7773 templates are first line on his todo-list, right before support for classes!
@@russianbotfarm3036 That lacks a bit of functionality though, for example: f(_: x, _:y) -> _(what type is this?)
I really liked this talk and the direction it's going in, I want to see C/C++ become a more secure programming language.
Another amazing talk by Herb!
1:04:00 If it works on anything with a subscript that has an integral value supplied and has a size(), it fails on std::map.
36:30 Calling free functions with object syntax is very good, too. C# extension methods. This is very good not only from the toolability perspective, this is also good to better follow single responsibility principle: we shouldn't define draw and save functions inside the classes, but ability to call object.draw() is very nice.
I have been on a "Rewrite it in Rust" path for the past few years, and am down to one last rather large C++ project that I was wondering if I should rewrite as well. Recently I decided to finally take the plunge, but this talk made me rethink it. I'll leave it C++ for now and see how cppfront develops.
The cppfront code is surprisingly small, considering what it can do -- Herb managed do a lot with relatively little code. I'm cautiously optimistic!
This is a revolutionary approach and I loved it :)
When Herb put C# handle allocation into a dialect of C++ (gc_arena, 2016), I thought "what a waste" . Making gc.new available is the appropriate place, the C++ place, to put this kind of compatibility. You can still have full cpp2-like syntax whether you must run in CLR or not. I saw gc_arena on an early slide and wondered how much time was going to be wasted there. Answer: NONE! As soon as he talked about allocating memory on the stack, on the heap, wherever, I realized that he'd arrived at an answer to this that anyone, even a curmudgeon like me, could be delighted at. Good Job, Herb.
I've also been bounds-check resistant because -- well, short answer is, the last time this was a flaming conversation for me was in the 90s, before Moore's Law had done most of what it could to processor speed. I saw code-bloat and exec time grind-down in that direction. Having cpp2 do it naturally, natively like that (post-[size]Moore, too) is DEFINITELY a step in the right direction.
And even from outside the US, we have to take "Wherever possible, do not use memory-unsafe languages" really, really, seriously. This is a way to do that. I want to be HAPPY to write C++ for a long time yet and cpp2 may be the best way forward. (see 40'00 - 45'00)
okay, I'm a full-on C#/.NET hater.Hate on me for it. I think I have valid reasons but I acknowledge that there is lots of good code -- e.g. Zachtronics -- written in C#. This is not the place for those reasons.
Herb has one of those beautiful brains that thinks incredible things and also has enough horsepower left over to explain it in a digestible way. I loved this idea so much. The semantics looks very simiar to object pascal, without the ugly verbosity. I wonder what anders hejlsberg would think about it.
I worked for a company that built a front for a second language, and used Prolog to write this. Prolog was very powerful for this purpose (perhaps not that fast, though).
Herb, you have outdone yourself this time!
I suggest that instead of cpp2, we call it sage. Because sage is an herb, and Herb's wisdom is sage
Hits so hard. Imho this seems to be the path forward to keep our hands on the full power of C++ while getting more compiler-driven safety with least friction.
Great talk. It gives sad and promising feelings at the same time. However, I believe, it's for sure better than some other X languages as "c++ replacers or killers"
I didn't run of to a different language, I came in as a compiled language newcommer and chose rust, partly because C++ just appeared bloated, with a lot of "Yes, this is the most straight-forward way, but it's unsafe and we don't do that anymore", and no consensus as to what current best practice even is. I wish this project the best of luck :)
implying rust isn't bloated
I love programming in straight C. Maybe this is what I needed to jump into C++.
I'd like to add to the "this is just an experiment, it might fall" idea - even if it fails, it can generate value, bring something new or expand our knowledge - I think this is valuable either way. Then it would be probably of even more value if the decisions that were made were documented, so that someone could build on top of it. But that would probably pile up the work required
This is great! Shouldn't be unlisted.
I've always wanted to see this, leading C++ people stop patching, draw conclusions and start over from scratch.
I read an article recently encouraging people to leave C++ for "safer" languages like Rust or C# but this talk shows C++ has the potential to reinvent itself to be a safe language. I'm excited for the eventual reincarnation of CPP2 to become a part of standard C++ in the future.
Reminds me on the notorious xkcd picture on several standards.😏
I wonder what’s left for memory safety after getting rid of nulls and pointer arithmetic? Ie, with those out of the way, why isn’t it 100% memory-safe?
@@russianbotfarm3036 References lifetime i.e. dangling references due to lack of lifetime annotations in C++.
I bet the majority of C++ programmers already had this kind of dream for so long already. Yes, carbon seems to be promising, but imagine C++ moving towards the direction of this talk!
The way I solved this problem with Script2 (Serial Chinese Room Interprocess and Telemetry Script) was I didn't use the std library and I instead wrote everything by hand using contiguous Automaton SCII data types that auto-grow from stack to heap. I use a single translation unit that can compile all the code in seconds. You really don't need to use multiple translation units until you're trying to complete many huge libraries in parallel using one translation unit per library.
I'm very impressed for the modern cppfront idea! Actually, the cpp1 is huge currently.
I'm lovin it!
Nice approach.
Glad to hear it!
I love rust grammar. Don't get me wrong.
However instead of transpiling, why we can't simply deprecate all those dangerous sharp edges (malloc, allocating new, union, unboundchecked accesses) that now c++ already has safer alternatives then just remove or internalise/classical-mode them.
If the *actual* problem is today people still *keep* using them as before. Why won't c++ just stop them from using those?
Great talk, Herb ! As usual
cpp2 -> cpp1 -> c -> assembly
Sounds like a great idea, 10 years down the line,
cpp3 -> cpp2
The problem is maintaining back compatibility and it's always going to f@ck things up. Always, rust works so well because it is not designed to interop with c, yes it can but that's additional, not the core part.
When you mentioned the intellisense, I know this is destined to succeed.
Cpp is so special that cpp programmers are not physically possible to remember all the tools they have to use, simply because the tools are too many. The only possible way for cpp or any high performance container language to work is to utilize the auto completion to the extreme.
Also, 2 details I would like to mention. I think I mentioned them in carbon's discussion page.
1, since you already made the rich ast to iso cpp code translation, I think it should not be too hard for you to make rich ast to cpp2 translation. When a break update happens, people can use this feature to get code on new version. Then, no tech debt any more.
2, macro is still something necessary in even cpp23. If a tool needs some init function for all the classes even for user defined classes, the only way maybe a customized parse tool, and the dev have to tell people to include some weird header in their cpp file. The parser generates the placeholder header. After all these work, it's time to compile.
say,
class A{...}
initializes with a init(...) function. But if you don't want the users to write this for all the new classes, this trick kicks in.
The result looks like:
#include "some auto generated header.h"
class A{...}
I don't how to solve this, maybe meta programming.
"don't pay for what you don't use" and "bounds checking by default" seem mutually exclusive
That "by default" is important... you can turn it off and then you don't pay for it.
been playing with this, most promising thing I have seen in a while, Carbon is ugly and not C++, but cpp2 is C++ and is beautiful so far
When it comes to cppcon, Herb Sutter is my second favorite speaker (after bjourne stroustrup)
Only c++ devs could look you in the face and say they like the status of c++ package management
finally a somewhat realistic approach to this, instead of "let's just dump existing codebases and create a new *perfect* language"
Long overdue, may the force be with you...
The parameter passing syntax looks like it would be non-trivial to learn and therefore may impede the adoption of cpp2 if it is implemented as shown in this talk. GC, if added, will probably lead to fatal fragmentation of the community, as it did with D, because half of the community will just switch it off. This whole proposal in general is great as an improvement to teaching, learning and safely using of C++. One other problem I see is that it is not a huge immediate improvement in most C++ use cases, so bottom-up adoption may be slow.
I don't think it's that complicated to teach primarily because the default (in) is the right answer 75% of the time, and when it's not it's obviously not, and inout is the answer.
The presented system of parameter passing is far easier than what we have today.
C++++ sounds like an interesting concept!
Thank you,
This helps understand this statement Bjarne S. had which i always wondered what it referred to, but yes i understood this means there are some keys inside C++ to provide simple language, which is kind of how i do program.
After learning through all the keynotes and conferences what this might be i started programming that way since about 2+years more intensively, never experienced a major leak or issue yet, but i stick structures which can't have those issues.
String, vector, locals, many techniques i learn for good experience shared.
So thanks again and by the way i tried compile cfront a while ago, as i wanted really write in C++ for some environments which don't support it, but cpp2 is kind of what i looks for as well, i believe there is a small community of people who will use and work with it, that's very very likely.
For example if i want something critical (or not) done, i might do the cpp2 version of it to learn more of the best practices, even if the main project is in cpp sources.
Jean-François
Liked most of it.
Not sure why everyone wants “name: type” syntax in all these newer languages. I frankly find it less readable than what we currently do,especially for any kind of chained logic like assigning from a function return. Also, having lots more keywords and punctuation would make the resulting c++2 MORE legible and simple, not less. Just imagine using the functional keywords “pack()” and “unpack()” instead of all the magic “…” for packs of types, fold expressions, etc.
Notice that the best improvements come when Herb introduces a few keywords and all sorts of old BS goes away: “in”, “out”, “inout”, “is”, “as”, etc. Others I’d propose are:
move: Have a keyword to do moves, demand move semantics (e.g. a specialization of “in”). No more && junk.
pack(), unpack(), type, types: Replace all the BS with ellipsis to handle list of types, packs of types, decltype, etc. Would transparently add support for having named sets of types in general contexts.
Reflect(), reify(): reflection with a readable syntax.
One thing I’d argue strongly against is making supposedly “unnecessary” punctuation optional. There’s a reason human language evolved in the OPPOSITE direction. Down that road is things like Python where you end up with pathologies like whitespaces determining scope.
Yes - programs are WRITTEN AND READ BY HUMANS. A "std::reflect( ).getMembers()" is a lot easier to understand, read and write than " meta = ^[...[::]...]".
keywords are not out enemies - esoteric operators and the reliance on templates is.
I also think "int x" is easier to both read and write than "x: int". And that was one of the first things that bothered me. I'm sure H.S. has some good arguments about that, though.
But we will see. There are as many different features in C++ as there are differences in what C++ programmers prefer.
This feels like the right initiative to pursue for the community, but most of it will probably be some sort of democratic mess anyways.
First time watching one of his talks. Didn't know John Cena gave C++ talks!
I don't understand why people rave about this presentation. The problems described don't require new (ugly) syntax or compiler to be solved, we just need to improve current compilers. The real problem in cpp is that with every new feature it forces you to go templates which really hard to debug
Templates can be arcane, that's true. But a lot of the problems with C++ are around things like defaults, where we have to teach people to overcome language defaults that are often wrong, and it's not possible to change defaults because any change would be a massive break. For example, we teach people to be careful about the compiler-generated special class functions that are generated silently by default and that are dangerous for many classes, and to remember to suppress those when they're often wrong... but we can't change the language to not generate them because that would break all the classes that rely on them, we can only do that if we have a second syntax that is not in use today. Another set of problem is around where the language just has multiple divergent ways to do the same thing in different places, and we can't really fix that without unifying those ways. I have one suggestion: Would you please check out slide 95 at 1:39:00 and see if that list might be more persuasive regarding the amount of arcana we have to deal with in today's C++? If we can remove that 'accidental complexity' that isn't core to the language's value, I think we should try. $0.02!
@@herbsutter4340 You don't need another compiler or syntaxes. You just need additional flags and checks for current compilers. Then it is the same: if you want it - you use it.
@@fareloz I'd love that to be true. It needs more than assertion that it's possible though... a lot of smart language experts and tool developers have been trying that path for years. But perhaps you're right that there's something they've missed -- I welcome the detailed proposal and the working tool or prototype to try out, that demonstrates how it can be achieved in an adoptable way (tools for today's syntax that are efficient and noise-free enough for everyone to be able to turn on at build time) and also achieve the same goal (at least of reducing what we have to know/teach by 90%, and reduce CVEs by 98%... it can't make C++ 10% the cost to write tools for but I'd be happy just to get the first two if it's practically possible despite experience so far).
@@herbsutter4340 There are many caveats which compilers warning about already: usage if initialized variable or dereferencing of null pointer, usage of moved object and many other. You can always force this warnings to be an error. [[nodiscard]] can be added implicitly too by the compiler. Maybe I miss something from the talk (or just simply don't understand), but I don't why I need another layer for this.
It's a different programming language that interoperates well with C++. Herb keeps saying "it is C++" but I don't know what that means.
I think he means that it's built using the same underlying concepts and features, as proven by the fact that it compiles down to C++
@@piotrarturklos C++ compiles down to assembly, but it doesn't make it assembly.
Very interesting and thought-provoking talk, love the experiment proposed here
OMG this is amazing, way better than carbon
Superb talk. Question regarding pointers; what happens when you have pointers that don't point to objects? I.e. registers or memory mapped devices, for example? Is this still possible in cpp2 pure?
I see the value of this for C++ programmers, but I wonder what the experience (say 5 years from now if this is stable) for people who don't understand the generated code? Will the semantics stand on their own without contextualization with existing cpp jargon? Very interesting indeed.
Well, maybe - hopefully! - it’ll be fully implemented into compilers and won’t _be_ a ‘-front’ anymore.
I haven't programmed in C++ in nearly 20 years and can't really read the modern version.
@@BryonLape That is probably one of H.S.'s largest motivators? C++ should be a syntactically and semantically simple language that is easier to teach and learn. Bjarne Stroustrup seems to share this sentiment.
This really reminds me of how refreshing it is using the Burst compiler in Unity. Small bubble of "new c#" that is isolated and allows you to really claw back the performance where it matters.
I don't think it's a matter of improvement, it's a matter of survival. When there is a guideline telling you to stop using C++ then it's not up to you anymore. When your company says that we have to change language because otherwise our software will be labelled as 'unsafe' because C++ is in a list of unsafe languages what will you do?
It's called learning to code, which is quite a bit different from building programs with copy/paste.
It's almost adorable to hear Herb talk about context-free grammar. The JS language community has been using transpilers to prototype language evolutions for 10+ years now. And while the result isn't throwing out context-free grammar let's just say a certain amount of hacking happens at the lexical stage, and we don't always fully validate the AST when building it at initial parse time. Everyone loves context-free grammar until their favorite time-saving syntax extension violates it, then it becomes a tedious game of how can I hack the lexical scanner to look forward and insert special tokens, can I move some syntactic validation to after parsing ends, etc.
This looks great.
How about local variables being const by default?
Herb Sutter is a dang hunk!
So if we really do need a successor, having looked at all the contenders, I can get behind Herbs cpp2.
I love the new function syntax. Zig is working on a very similar refactor to their functions syntax.
I'm not convinced a systems level language should force smart pointers or particular trendy abstractions. For example, pointer manipulation is essential. There's too much handwaving in the answer to that question that was asked at the end. Maybe this is the direction of evolution of C++, but then it won't be C++ anymore. For me, C++ is the language I go to for maximum computing efficiency.
This seems to be an example of the age-old tension in language design: Some people want a safe, productive language that is nice to use, but many want a useful language that can get out of their way when they program at a low level. Personally, I think that the safety features should be left to tools, and the language should be kept as simple and as unlimited/expressive as possible.
From a point of security, it actually makes a lot of sense for a systems language to enforce pointer safety. You gain more by having an extra indirection (which is not always used, as in the case where shared_ptr is passed as const&), than by risking a lot of security vulnerabilities. Our processors are quite a bit more powerful today than they were 20 years ago, and this question is less important today. The only place where this has some merit is in strict realtime applications, and even there we don't always want to manage everything.
In my own opinion, safety is more important than speed. But we can test for safety and then disable those tests later with some compiler optimizations and flags.
Besides, we also need to educate programmers as better programming practices evolve. Just as we did with goto, now it is happening with the preprocessor.
This is what we need, not smth like carbon. GREAT TALK!!!
Well that was an epic rendition of "C++ considered toxic"!