CppCon 2018: Herb Sutter “Thoughts on a more powerful and simpler C++ (5 of N)”
Vložit
- čas přidán 8. 06. 2024
- CppCon.org
-
Presentation Slides, PDFs, Source Code and other presenter materials are available at: github.com/CppCon/CppCon2018
-
Perhaps the most important thing we can do for C++ at this point in its evolution is to make sure we preserve its core strengths while also directing its evolution in ways that make it simpler to use. That is my own opinion at least, so this talk starts with a perspective question: What “is C++,” really? The language continues to evolve and change; as it does so, how can we be sure we’re picking C++ evolutionary improvements that not only don’t lose its “C++-ic” qualities, but make it a better C++ than ever?
At recent CppCons, I’ve spoken about several of my own personal C++ evolution efforts and experiments, and why I think they’re potentially important directions to explore for making C++ both more powerful and also simpler to use. The bulk of the talk is updates on two of these:
1. Lifetime and dangling: At CppCon 2015, Bjarne Stroustrup and I launched The C++ Core Guidelines in our plenary talks. In my part starting at 29:06, I gave an early look at my work on the Guidelines “Lifetime” profile, an approach for diagnosing many common cases of pointer/iterator dangling at compile time, with demos in an early MSVC-based prototype. For this year’s CppCon, I’ll cover what’s new, including:
• use-after-move diagnoses
• better support for the standard library out of the box without annotation
• more complete implementations in two compilers: in MSVC as a static analysis extension, and in a Clang-based implementation that is efficient enough to run during normal compilation
• the complete 1.0 Lifetime specification being released on the Guidelines’ GitHub repo this month
I’ll summarize the highlights but focus on what’s new, so I recommend rewatching that talk video as a refresher for background for this year’s session.
2. Metaclasses: In my CppCon 2017 talk, I gave an early look at my “metaclasses” proposal to use compile-time reflection and compile-time generation to make authoring classes both more powerful and also simpler. In this case, “simpler” means not only eliminating a lot of tedious boilerplate, but also eliminating many common sources of errors and bugs. For this year, we’ll cover what’s new, including:
• an update on the Clang-based implementation, which now supports more use cases including function parameter lists
• new examples, including from domains like concurrency
• an updated P0707 paper, with more links to working examples live on Godbolt, being posted in the next few weeks for the pre-San Diego committee mailing
-
Herb Sutter
Microsoft
Author, and chair of the ISO C++ committee.
-
Videos Filmed & Edited by Bash Films: www.BashFilms.com
*-----*
Register Now For CppCon 2022: cppcon.org/registration/
*-----*
I bet Herb has a huge walk-in closet to display his impressive Hawaiian shirt collection.
Yeah, C++ will do that to ya.
Impressive talk, in my opinion he is the one with a greater vision in the committee, looking forward for the metaclasses
Great talk Herb!, I've seen Herbs talk about Metaclasses from last year and I really want to see this in C++.
Imagine not having reflection in 2021... a feature that should have been here for the last 10 years.
Maybe because it's not a zero overhead abstraction?
Very excited about metaclasses. I think it's the most powerful language feature introduced since templates.
yes, very impressive feature, can't wait to see what ppl come up with using them.
C++ metaclass is going to be a killer feature. I think we probably will have it in the language by 2022-2024. I doubt other (mainstream) languages have this capability.
smalltalk-80 has it. And that's an old language. Hahahahaha
I'm still waiting for a new episode from CppCon 2018. Please upload a new one.
Because metaclasses are tightly coupled to reflection and codegen, I'll just just say it. If the restrict(amp) compatible (aka. "static C++") statements of a function could be traversed via reflection, one could implement not just MOC-like tools, but C++AMP/SYCL-like compilers as ISO C++ libraries. Herb having designed C++AMP as well, that would be one less language extension to do again, something that would enable GPGPU within C++ as a library feature. I was told that the current reflection TS does not allow traversing private members either. Adding these two would solve most of the headaches HPC is suffering from, portability of code, vendor lock-in, API support, etc.
The presentations are great as always. I just wish they wouldn't include that weird noisy music at the beginning.
I really like how C++ has evolved to such powerful language, but metaclasses syntax looks kind of weird to me
It will be hard first but it can be easier for us all...
He really did a disservice to his argument by showing the child's play C# class declaration, and then the C++ attempt to emulate part of it partially with refrefs and angle brackets abound.
very cool
So Herb came last year with a good syntax for metaclasses that could be improved and the C++ Commity walks in and made the syntax uglier, less readable and overly complex instead of making it better! Nice Job commity!
I think the new one is better. More explicit and easier to read. Also I find it more intuitive to be imperative (functions). Because of that it may also be easier to extend in the future, when a need may arise for something that couldn't be specified nicely in a declarative manner (class body) (I think it was already stretched).
Agreed. Especially frustrating to hear that they will *never* accept properties being built right into the language - and then they poison the metaclasses with yet more esoteric syntax.
The "definition" of metaclass as not ugly as hell, it someway more cleaner that it compiletime code transformation function. So, I can accept it someway.
But "instantiation" - meh, no, I hope there will be smth cleaner.Just as Herb said - make me way to directly tell my intent.
class(cmth) - not a great, class (some BS) for properties - total mess.
how is it ugly
Spotted an error at the 1h mark - the lock_guard should be using {}'s rather than ()'s to capture a lock to data1, otherwise it's a function call def and not what was wanted.
You're wrong, 'data1' is not a type and therefore it wouldn't be a valid function declaration.
I have to say, last year Herb's syntax was so much more beautiful and straightforward. Current committee's syntax proposal sux, sorry.
I googled "defun defun 3" like suggested actually and it came up with nothing. I am guessing the idea is that it replaces the defun macro with a function that returns the constant 3?
emacs.stackexchange.com/questions/375/symbols-value-as-a-variable-is-void-defun-when-reloading-emacs seems to suggest differently
You can shoot yourself in the foot in any language, but if the goal is to not add more ways to do it to a language, you shouldn't try to copy features that add them.
Herb, I don't know why you seem to need to explain why adding features makes the code simpler. Functions are like words that you add to the language. Imagine if every time you wanted to reference a coffee cup, you had to say "a small bucket made with an insulated material to prevent burning of the holder by the contents, which is expected to be hot, and probably is coffee." It's much quicker to just say "coffee cup", which does imply that the listener has some knowledge about what material the bucket would be composed, and it's size, but it's far more convient for the speaker, and I'd say the listener gets the benefit of parcing and processing the sentence much more quickly.
Your analogy is good and I kinda agree, but the problem is that a lot of books and people use the verbose way of describing a coffee cup, so until they migrate to your new word the language will be larger. Hopefully people and education catches on and we can forget about the various verbose versions.
I like meta classes, image possibility to have meta class that can transform C++ class to object that is compatible with Python, PHP or Node engines.
What IDE is being used here (other van vStudio)?
cppx.godbolt.org ?
Compiler checks dangling pointers and null pointer. It must be a dream. Where is the paper of how this is implemented?
It's linked in here: herbsutter.com/2018/09/20/lifetime-profile-v1-0-posted/
That's why compile time is the future. Everything in compile time, nothing in run-time. This means the compiler can check everything.
WORD OF POWER! Is Herb a DnD nerd?
Removing macros means making debugging harder, if no new language feature is added, that allows writing assert. I thought about a new type of parameter passing; pass by expression. The parameter is never evaluated until you use it in the function body. There should also be a way to get the source code of an expression-parameter to be used in a message.
I am using $ as a symbol for expressions, you evaluate it with $, as you dereference a pointer with *:
void assert(bool$ expr) {
if constexpr(DEBUG) {
if(!$expr) {
assertion_failed(expr.source, expr.file, expr.line);
}
}
}
assert(42 == 20+20+2);
An expression has a $ operator to be evaluated, the members source, file and line to contain debug information. As expressions are statically included in binary, the function needs to be inlined always, as you expect it with lambdas:
template
void assert_f(T expr_func) {
if constexpr(DEBUG) {
if(!expr_func()) {
...
}
}
}
assert_f([]{ return 42 == 20+20+2; });
Contracts ( www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0542r5.html ) is the thing that replaces assert().
@@dominiccasts The problem with the contracts is, that it might be compiler dependent, which information is outputted. When you are able to define a macro (or a function with the expression parameters as mentioned in my previous comment) you have full control about the behavior. Sometimes you want to enable or disable checks for a specific part of the code.
In my optinion the contracts-proposal may even improve debugging, but I think there will be programmers, who want to write the assert-macro/-function by themselves in a more classical way. Expression values are more useful for just only an assert-macro and lazy evaluation. It can be a big step for metaprogramming. I hope there will be a feature like the expression values in the future. It could fully replace the need for macros in C++.
I strongly oppose the syntax of writing "__" before something. Doing the "$" in PHP for variables is bad enough. The original one, was so nice.
But else, great talk as always. Didn't understand the Compress->Encrypt->Stuff though.
I believe that denotes placeholder syntax.
@@7thfleetOne I hope so. This is such a strong feature, it should be very well readable
Yes it looks like a hack for the Compiler Explorer so that it can define non-standard keywords. Sort of like putting some __PREFIX on predefined macros.
They usually indicate predefined compiler macros... so that __ gives them that distinction that they arent your typical keywords or variables.
C++ will never have named function parameters because there is too much conflict with lax legacy design. this seems to me to be representative of a general problem, too much baggage from the C days.
yeah, would love to see a brand new c++
It looks like metaclasses (or metafunctions?) would allow a nice way to implement the named parameter idiom without much boilerplate. Maybe this is beside your point, though.
if you have to add lots of weird extra syntax to accomplish a simple goal like a syntax of
computearea(height:2, width:3), then the issue is the baggage in the core language.
The start part is really scary
3.5 years later, and what is result?
Why just metaclasses? Why not metaeverything? You could make some general code factory syntax with the same effort.
Isn't that how you end up with Lisp?
@@DemHoNMomentz C++ is a multi-paradigm. It would be great if both ideas from Smalltalk & Lisp are in C++ without a garbage collector. And also creating a choice between deterministic & performant algorithms. Because sometimes you want deterministic code, and sometimes performant. Depends on the use case. That would be the ultimate language for me.
Active object is create, I've created library to make easier working with it github.com/redradist/Inter-Component-Communication and created even simpler abstraction based on common bus that is called in my implementation locales, take a look at example github.com/redradist/Inter-Component-Communication/blob/develop/examples/ForeCast/main.cpp
I really don't understand why some programmers just don't get it: look how complicated the universe is - the laws of physics, biology, math - their "Standard" has WAY more pages than all of the books on science combined. And yet we wake up, live our day and go to sleep - as simple as that. The more complicated a specification is, if it's done the right way, it can make life as beautiful as can be.
Nope. *simplicity is the ultimate sophistication*
Psst
1) Go to the CppCon main youtube page
2) Go to the “videos” tab
3) Change the sort field from “date added” to “most popular”
4) At the top should be a vid with a guy wearing a red shirt. Enjoy.
shevegen Yeah... You're right. Except there are two bits that machines understand -- zero and one. Still less than four DNA components, yet somehow something more sophisticated can be built on top of it. Exactly as in the DNA case. My point is that your reasoning is invalid since you've taken something of arbitrary complexity, i.e., DNA components, without justifying such a choice in the first place. Why not protons/electrons/neutrons?
On the other hand, I somewhat agree with what you trying to say. Although, I cannot agree with the reasoning. Peace! ;)
@Ernest Rutherford Mike Acton haven't said, that he doesn't use templates because of code bloat. The only concrete fault of templates he mentioned was compile time.
Make interface keyword FFS
Hmmm... Sounds like a more complicated Rust to me.
@Ernest Rutherford www.rust-lang.org/en-US/friends.html
Ernest Rutherford, immature in the sense that there aren't enough libraries for all needs (although that changes rather quickly). But the core language is stable and very mature. The excellent FFI makes it rather simple to build pure idiomatic Rust abstractions with zero (or at least close to zero) overhead.
Nobody said they should stop using C++, but Rust is a viable alternative; especially when memory safety is of concern.
shevegen, if you are familiar with the concepts of ownership (which is not an invention of Rust), interfaces, lifetime and generics / templates, I don't think it is any more complicated than C++. And please look at how complicated and unwieldy C++ has become.
and we see no gafa in this list
...and also unsafe
It's too narrow, blah blah blah. We like general features, blah, blah blah. This is the exact reason why in 2019 I still don't have a standard tool to parse a phuckin json in c++. Goddammit!
Parsing a json should not be a standard tool. It should be a library. Because it's a program on itself. And improvements can be made trough time.
typedef reflects the way the typing system works in C++. People are lazy and usually don't learn it, and then they are puzzled by why a pointer to a function looks like this. It's simple: type description is a set of all these *, &, [], etc, you have to apply to get the value. With making typedef a secondary citizen, I am afraid even less people will learn how types are formed in C++.
IMHO, C++ is moving towards the Chinese language in terms of simplicity: hieroglyphs are also simple for the Chinese people, some hieroglyphs are rarely used and there is a historic logic behind every piece of it. But the raise of Rust, Go and LLVM-based languages shows that there is another approach for simple English-speaking people..
At least it could be worse; it could be Russian. ;-)
The more i look at c++, the more it looks like a hacky language. Random if else statements in a basic loop just not to crash, what the hell is that? Complete garbage.
Yes the syntax is terrible when you get into templates. And it will get worse with concepts. They are just to close minded to invent a good syntax at least for the parts that dont need backward compatibility. Concepts are not C++ no to mess this up too.
Which example are you talking about? Erasing an element when iterating or something else? You have to do checks in other languages too in the same situation to avoid problems, so I really don't see your point here...
41 minute, v.erase();
I mean, come on.
Are you suppose to write garbage like this when you want to delete an element from a collection?
if (*i * 2) {
v.erase(i)
} else {
i++
}
If this is how C++ development is done, i am glad i never did any.
@@user-ov5nd1fb7s I think you might misunderstand why that if check is there... the if check is not there to make sure that the program doesn't crash, it's just a simple condition to check if we want to erase the object or not. In this case, we apparently want to erase the integer only if its value is 2. You would need to do the same check in other languages as well.
I was talking about the else, needing to increment the index inside the loop body.
You shouldn't need to do that.
The first example should work properly, where the index is incremented inside the loop definition.
It should be smart enough not go outside of the vector bounds, without you needing to have ugly checks all over the place.
For basic operations, you shouldn't need to do any checks like that.
It should be clean code without these hacks.
c++ has ugly syntax, it is made by people who prefer to spend their time writting stuff, rather than writting solid and usable code