I don't agree. He's good in style, but his slides are TERRIBLE. He doesn't follow any recommendation on slide style I've read. He adds lots of text he doesn't read to the audience, who's trying to listen and read at the same time. He adds "taboo" colors, like light green, yellow and such. He uses different styles on each slide. Seriously, to be there in person, I'd never understand half of it, if you are not an expert.
@@darksidegirl good presentation style dictates you should not read what's on the slide directly. Slides supplement your talk. i would rather a talk by key note speakers be information dense even if I have to go back and watch it on RUclips again.
A passionate, humble, learned man giving an engaging talk. This feels like reading K&R felt. Such clarity and simplicity in that which seemed so complicated when learning it in other contexts.
K&R book is such a masterpiece. It's probably still the best book on the subject ever written. No other book comer close to its simplicity and compreensiveness.
I feel like the people who are still saying (even today) that cppcon is just an echo chamber of experts talking to each other, with little of value for an average developer might have had a point at some time in the past, but that certainly by the point of this talk it was not true. There have been countless great Back-To-The-Basics talks and others that show that they are very actively trying to increase the circle of C++ competency, and are not at all obsessed with hyper-expertise that could only be understood by a group of people that fits in an auditorium, much less an elevator. Great stuff.
Brilliant work that still feels relevant 8 years later. re: auto type deduction - I think my fear of it comes from ending up with std header compilation errors later in the maintenance cycle. Working with C++ and watching videos like this one is making me smarter all the time, but I think I'm maybe just not quite smart enough yet. But this definitely convinces me to try using it more. re: C++ developers care a lot about performance - Well, the only time it really makes sense to use C++ is if performance is a higher priority than time to market.
Yeah especially 56:00 and forward. He even draws attention specifically to the importance of watching the screen right then. Whoever put this together doesn't care. He's just mesmerized by Herb I guess.
slides available here github.com/CppCon/CppCon2014/blob/master/Presentations/Back%20to%20the%20Basics!%20Essentials%20of%20Modern%20C%2B%2B%20Style/Back%20to%20the%20Basics!%20Essentials%20of%20Modern%20C%2B%2B%20Style%20-%20Herb%20Sutter%20-%20CppCon%202014.pdf
1:33:00 You can do it with structured binding in C++17: _std::set< int > digits = { 1, 2, 3, 5, 6 ,7, 8, 9, 0 }; // missed 4_ _for( int i = 0; i < 10; ++i )_ _{_ _auto const& [it, result] = digits.insert( i );_ _if( result )_ _{_ _std::cout
When it comes to option 4 for set_name, Herb, the confident guy in the audience and the guy expressing his surprise about its performance advantage in the end curiously all messed it up at some point. Herb firstly messed it up, because compilation of the code on his slide will fail as soon as used with a string argument because of the exclamation mark. Without it, compilation will still fail as soon as used with a char* argument, as during his benchmark. Herb is simply wrong with his "Write it right", instead do not constrain the template unless the function is overloaded. So the confident guy in the audience is right saying Herb constrained the template wrong. But it is even more wrong than he apparently expected. Because of the erroneous exclamation mark, the function will indeed accept a string literal. Finally the guy expressing his surprise about the performance advantage of option 4 appears to have a valid point at first sight because without the exclamation mark the template should generate at compile time the exact code of option two. But it only does so if used with a string argument. A char* argument causes compilation to fail as mentioned before. If the entire constraint had been correctly left out, then there would be no reason for surprise either because the generation of a char* template instantiation enabling the usage of string::operator=(const char*) clearly accounts for the performance advantage. Despite Herb's attempts to shift responsibility onto Howard, I think, Howard is the only one involved who has got everything right. He was dealing with an overloaded function in a different context like a constructor overloaded with copy and move constructors. His function being overloaded with a function taking some type X, in order to prevent the forwarding reference from matching X too, he had to write an template constraint to exclude X from the template, hence the exclamation mark. Herb just blindly copied Herb's code from a different context, fiddled with the data types according to his faulty understanding of the purpose of the constraint, and ended up with something which is wrong for multiple reasons.
No. The main difference is that the copy-and-swap idiom is not about avoiding unnecessary work, but about providing stricter guarantees, in particular regarding exception safety. If you want to have the strong exception safety guarantee, you must pay the price and create a new temporary object, for that you cannot leverage the memory that your current object holds.
This is a good point. In most projects I've worked on, the first one is by far the most common (maybe because it's older) but very easily recognizable as "oh, that's an STL object iterator!". The other thing to look at here is how readable it is to new developers of C++. In my opinion, it makes more sense and is more readable because you are saying: "I'll start the beginning, until I reach the end, and advance one object per iteration" pretty explicitly.
There is a mistake on this slide: i.imgur.com/1nqH4Ct.png Actually, here you can see that mistake is in PDF presentation, but not on the screen behind Herb: ruclips.net/video/xnqTKD8uD64/видео.html
Like Herb mentioned: "It reflects bias to code against implementations, not interfaces". Good code design should focus on "what" the code does, and not "how" it does it. This is particularly important if you are creating libraries for other people to use.
This is all very interesting, but it would also make sense IMHO to, at some point in the life of the C++ standardization process, spend some time to ensure that the C++ standard library is usable with Unicode text. I mean, usable as in Python 3, for instance.
35:09 "why deduce correctness" IMO weak argument to go to auto, because if you change something so significant that you starting modifying, when you haven't before, it's not small change, and have need to look at code more careful (because now types are different) is just a plus.
About prefering auto for declaring local variables: The auto keyword makes code harder to read (type deduction) or document. It makes it worse even, because if you change a return type you don't want undesirable side effects that pass undetected. The compile time error is your friend when refactoring a code base. Much better than having run-time erros and it also gives the opportunity to review the code and detect problems ahead of time.
You're kind of missing a big piece of what he is saying. If you're coding to an interface then you can use his "tracking" auto declaration but if you are coding to an implementation then you need to use his "stick" or "commit" style which is 'auto x = type { foo() };'. This is better b/c it conveys that your intention is to code to a specific type and not an interface. It is more expressive.
"This is better b/c it conveys that your intention is to code to a specific type and not an interface. It is more expressive." No, it's literally just more typing.
@@isodoublet you're still not understanding the distinction between "interface" and "implementation". You shouldn't need to know the exact type in most situations if you're relying on the interface instead of the implementation. If you were in the business of using or extending 3rd-party libraries you would understand why this distinction is important.
He didn't quite convince me that mass auto is the right way to go. In some cases, when a change in one place tracks to all the other variables, I'd be afraid of it silently resulting in the wrong behavior. Of course, auto is needed for quickly writing templates too (and his initial example was template-looking code!). I also like auto when it takes away huge types that provide no real information for sure such as vector::size_type. I'm also all right with it reducing redundant type information as he showed. However, I like types! They document what kind of operations might follow next as a type restricts what might be done using that variable. I wonder what Bjarne Stroustrup's modern C++ guide recommends. They're also essential for forwarding references and for writing the output of a function in terms of the arguments. The rest of the talk was great information. It can be hard to maintain interest for close to 2 hours about programming, but he pulled it off.
17:15 I would have thought that the function could be participating in the ownership if it's potentially keeping the object alive just by holding the shared_ptr. It's not only participating in the ownership if it's stashing the shared_ptr in some global registry or something.
I remember folks making the same doom-and-gloom arguments against var when it was added to C#, but they were quickly proven wrong and now everyone uses it to great effect on readability and refactorability. C++ introduced auto only a few years later, and people are still debating it. Is the C++ community just reflexively contrarian?
The concept of clear simple code is not so clear. In one of my teams people didn't know range-for loop, it wasn't clear for them. “Clear” code for the developers in that team was the code that the least knowledgeable C++ developer could understand, practically C style. Otherwise they used to say it's difficult to follow. Also less function calls was more clear for them. A thousand lines of code in one function was better then 10 function calls, because they said otherwise they have to search and check each function code to follow. But what if the function name is very clear I used to argue? Doesn't matter. No amount of arguments you might hear from Herb, or Bob, or Kelvin, or Sean could help. They opposed even auto. Ah, and no templates. What I am saying is it might be quite challenging to serve that ~3M community of C++ developers. Sometimes I think we have to revert C++ back to C to make code “clear” for them. They program --C++.
The main problem is that they are reluctant to accept change like many "experienced" guys. But any C++ programmer who cannot understant a range-for loop is dumb or (more likely) in bad faith.
They can understand it. It's just not what they consider as clean code. What I am trying to say is that if we try to serve 3M community of C++ developers, we must admit that we have to forget about clean code in Herb's sense. Most of these 3M developers program to implementation, not to interface, and don't want to learn anything new.
At roughly 23:00 he is nearing his statement about dropping a reference count and what to do about it. 23:23 is perhaps the closest point to start, but before is better.
I want so much to become a professional C++ programmer , i know simples things for now i do computer science . But where I live there is not any possibility of chance to get any job or oportunity...
To become a professional C++ programmer, you have to become a professional in algorithms and data structures first. Along with a lot of practical experience, not only in programming. Knowing a programming language well doesn't make you a professional.
Conenion i study graphs , binary trees , algorithm complexity , all kind of sorting algorithms and arrays structures ,pop push etc , every kind of things in the university I don't know everything but I can handle
If we're no longer encouraged to pass-by-value on setter functions, does this mean we should also discourage copy-and-swap assignment operators, which suffer from the same problems?
Except that in many cases RVO doesn't apply, and it's impossible for an average developer to reason about when it does apply and when it doesn't due to so many edge cases :/
IMO for (e : c) makes coding "easier" but not "simpler" than for (auto& e : c). Conceptually, both are the same thing, with the latter actually be clearer that e is a reference to an element in c. But implementation wise, the former requires less typing.
10 лет назад+1
1:15 the concept of "unteachable" perfectly illustrated
1:15:00 What's problematic regarding noexcept isn't the function itself. What's problematic is C++'s automatic implicit copying that can happen basically anywhere without the programmer noticing.
imagine a variable x and y. If you create variable x, it exists on memory. If you are copying x to y, x is still alive. But if you move it, you move the complete variable and x is no longer alive.
@@kim15742 can you explain why the type must be trivially destructible? shared_ptr is non trivially destructible and can be moved (it can just be moved). I think that the best example is vector. If you copy the original one remains untouched, but you need to allocate memory for the internal buffer of the second one and you need to execute the copy constructors of every Item (they may be trivially copied, but you need to copy them). If you move a vector it is left to the implementation of the move constructor to decide what to do; the move constructor can leave the original vector in an invalid state, what it must do is make the new one valid. A naive implementation of a vector can be a raw pointer to Foo and two size_t to store the current size of the vector and the current buffer size. In this case the move constructor can just copy the raw pointer and the two sizes in the new vector and set the raw pointer in the old one to nullptr, which makes it invalid. The non trivial distructor can just check for this state (is the raw pointer nullptr) and do nothing.
@ 30:05 Can someone explain to me what it means to make a type _track_ or _stick_? Beyond deducing the type or explicitly declaring the type I do not understand what these terms mean, nor have I heard them outside of this talk. Thank you.
It just means that auto "tracks" the type itself. For example if you have to classes class Tool; class Hammer : Tool; If you now have an object of the type "Hammer" but you want it for any reason to be sure it should be stored as a Tool and not a hammer, you should stick it.
Can anyone explain me what the NOT-operator (!) is doing in the perfect forwarding example? From what I see the author wants to restrict the templatisation to the type std::string. I'm referring to this line: template::value>> I don't understand why the NOT operator is there. In my opinion it results exactly in the opposite of what shall be achieved.
At 1:17:00 setName function is marked as noexcept and takes an rvalue parameter and perfectly forwards it. But if setName is passed an lvalue, it might cause an allocation inside the function as it would be an assignment? In that case it cant be marked noexcept?
True. The expression inside the noexcept qualifier make the function noexcept if and only if the String type can be assigned to std::string without throwing. Otherwise it is not noexcpet qualified.
Sure, it would work. However it would be slower for longer strings (short strings are actually copied and moved at the same speed). Long things short : without move -> allocation and memcpy ; with move -> copy of a pointer. When not using move, you are calling the copy assignment operator that 1. resize the buffer of the name_ string (allocation) 2. copy the content of the buffer of name into the buffer of name_ 3. delete the buffer of name at function return. When using move, you are calling the move assignment operator that 1. delete the current buffer of name_ 2. bind the buffer pointer of name_ to the buffer pointer of name 2. set the buffer pointer of name to nullptr (or equivalent)
9:30 - answer is, the top one is easier to parse visually by someone coming to the code who hasn't written it. In fact it would be even clearer without the 'auto' as the type would be immediately visible.
You've got Stockholm syndrome from C if you think the standard for loop is "easier to parse visually" than a range-based for. To even be able to understand the top code, you already have to know about iterators and whatnot, and once you know that stuff the second code is much clearer because it provides the exact same information in a condensed form, without all this extra visual noise. There is literally nobody on the planet who would be able to understand the top without being able understand the bottom, so why not just use the bottom code? Why should a developer have to waste their time writing out boilerplate when they could just write out exactly what's relevant and nothing more?
I had to shake my head a few times so far. Using smart-pointers is always messy, it promotes not thinking about the lifetime of objects at an architectural level. It creates multiple ways to do call chains that are fixed, while requirements might change at a deeper level. Better is to avoid the heap concept as much as possible, even if under the hood a heap is used, the stack model is the natural model for C++.
" it promotes not thinking about the lifetime of objects at an architectural level" Exactly. They undoubtedly have their uses, but this point needs to be made.
Watch his Cpp2016 talk "Leak-Freedom in C++" where he shows how to write simple, fast and leak-free code. And yes, he says that most of the time you should use stack and not heap.
For the performance to be like that, you need your char* to be an rvalue in the first place. set_name("John"); //OK char* name = "John"; set_name(name) //Not OK Now, your temporary char* is passed to the templated set_name. The compiler then specializes the template with T = char*&& (rvalue reference). Then, the reference collapsing rules apply and make 'char* && &&' become 'char* &&'. However, the parameter name is an lvalue, just as any reference (rvalue or lvalue ref). Thus, it must be "converted back" to an rvalue before being sent to the assignment operator of string. This is what std::forward is made for. Finnaly, string::operator=(char*&&) is called. This causes the char* to be used by the string directly as its buffer (no copy, no assignment). In the end : 1 allocation to create the char*, no conversion, no copy. The other approaches involve at least one more allocation for the conversion from char* to string followed by deletions.
@@gabrielb.2886 string::operator=(char*&&) there is no such an operator. The difference is because with const& + && you first call string(char*) with likely frequent allocation, then call a move constructor vs with option 4 you call string::operator=(char*) which with high probabilty incurs no memory allocation
Is there any room to change the spec for a simpler solution to the shared_ptr dereferencing problem at 23:48? Ideally, the library specification should have been that dereferencing operations on std::shared_ptr<T> should all return a std::shared_ptr_deref<T> object that ups the refcount during its lifetime and which has an implicit conversion to T&. This way the reference will always be held while the object is being used. I hope that can be changed in upcoming c++ versions
What about the overhead of such solution ? Ref counting is thread safe in case you forgot, which makes it very expensive in a context of repeated pointer dereferencing. Here, you have to take care of yourself in these quite rare cornercases. Otherwise, it's as fast as it can get.
This is all nice and clean; but in that case, I'd like to get that `auto` be renamed to `let` or `var` for variable declarations. and something similar to function declaration (instead of `auto f(int x) -> int;` something like `func f(int x) -> int;` but then again, the next issue is parameter declaration lists, which are still right-to-left. :)
Thankfully the types are visible to debugging tools. What people fear the most is having a type you didn't intend to have, IMO in that case do use explicit type or the auto syntax he showed.
Even during this talk, I feel Herb himself is a victim of what he is trying to teach against. The simple mention of "does this every time you are iterating through all elements" instead of "any time you iterate" means that you have to have two variations depending on whether you iterate through some or all. Isn't this "non-default" in itself?
It is default. More than 70% of my for loops are range-for loops. Other loops are either reverse iterations or index based iterations because I need the index value.
How often do you actually write a for-loop that doesn't interact with the whole collection in order? It's rare, most of the counterexamples are just doing the whole collection in reverse order, or index-based for-loops when the author needed the index for some reason. Don't think of range-based for as a rule, it's just a design pattern. It's a simple way to make the old iterator-based syntax more brief and clear.
at 9:02 Herb Sutter encourages to prefer range loops over conventional counting loops. I cannot see any advantage in this whatsoever, if you don't count the additional array border safety. And i don't ! No developer in his right mind will produce an array border violation after 1 year of experience. Try this to judge for yourself : #include using namespace std; #using using namespace System; const unsigned int Size = 60000; void main() { char Numbers[Size]; DateTime EndTime = DateTime::Now; DateTime StartTime = DateTime::Now; TimeSpan elapsed; // Counting Loop: for (unsigned int i = 0; i < Size; i++) // forward iteration //for (unsigned int i = Size-1; i > 0; i--) // backward iteration { Numbers[i] = i; } EndTime = DateTime::Now; elapsed = EndTime - StartTime; cout
Thank you - must have happened when i inserted that line along with other alternative comments. Very astute ! Well done! But what really went wrong there was that accidentially (maybe because i was working on a project where i used this one) i chose the "wrong" implementation of the range loop - in fact, this code partially is "Managed C++" instead of C++11, which means i used a for each loop from .NET including the "System.dll". The proper loop header schould be: "for( char& ri : Numbers )" which is c++11 and not "for each (char& ri in Numbers)" which is managed c++. In MFC there also is a "for_each" range loop (Note the underscore). But that one would need iterators, which a primitive type char array does not have. This is the cause why they introduced an "Array" class in C++11 which exposes iterators even for primitive types.
Look, the "conventional" for-loop with this manual counter is just cumbersome. Most of us just wish to loop through an array in a comfortable way, like in Java or JavaScript. For your special cases, you can do your traditional for-loop, but it is not the rule.
Can you please do the same with a structure without random access iterators such as a list ? Can you also give me one good reason to continue using c style arrays on the heap when std::vector has almost zero runtime overhead while providing everything you need for both forward and backward iteration ? And finally, why should I bother with a counter if everything I do is "for each element, do something, regardless of its actual index" ? The only reasons I can think of to use a counter is when you actually need the index and when you are iterating over several containers simultaneously.
If without auto, how to resolve the parameter and local variable? void foo(int x) { auto x = 10; } // ok void foo(int x) { x = 10; } // ok void foo(int& x) { auto x = 10; } // ok void foo(int& x) { x = 10; } // wtf?
@@varphonewong4068 your recreating the variable x. void foo(int x) { auto x = 10; } // your creating x as an int in the parameter and then your creating it again as an int ("auto") in the body, does this even compile?
I also don't buy Herb's arguments for auto. I never liked it because it covers up types and makes code much less expressive. Everyone wants his code to be "self documenting" but with auto you take exactly this away. So when I try to read code from another code base I would be faster to interpret what it is doing even if the initialization spans a whole line and doesn't look pretty... I think behind the scenes most of the bias towards auto anyway stems from the fact that "it looks nicer" and you can line up your equal signs better - which really shouldn't be a valid argument for a programming language or should it? That's rediculous.
Dude, have you ever tried initializing a nested container in C++? Nobody wants to type six right angle brackets and the same type name three times just to instantiate a 3d array, and they especially don't want to type out some of these 3rd-party library type names that span a whole line. Most of the time, the unabridged type name is just noise that makes it more difficult to see the logic. It's important for code to be clear about *intent.* It is not important for code to be clear about the exact implementation of every type you're using. Imagine if you couldn't use the "int" type name anymore, and had to specify the exact width of every int you used. It would get tiresome quickly, and in the vast majority of situations the exact width of the int isn't relevant. Only in a few situations does it make sense to say, specifically, "this is a uint8_t" or "this is an int16_t", almost always when you want to do some kind of fixed-point arithmetic or when you want to use an overflowing int for some purpose. It's sort of the same idea with "auto". Most of the time you don't need to see every single template parameter in detail, you just need to know broadly what type of object you're dealing with. In the situations where every minor detail of the object is relevant to the logic of the code, don't use auto. We shouldn't get rid of auto entirely just because it's better not to use it in certain situations. I propose that if you want to see all the details, you can still use "auto". Write a function that takes the relevant template parameters as its arguments, and then use "auto" when instantiating the object to keep the code uncluttered. That way you get code that looks like this: ```auto arr = ndarray(k = 3, T = float);``` Instead of like this: ```std::vector arr = std::vector();``` The first code is obviously better for clarity, and if you need to see the exact details that you can see in the second code, you can always go read the ndarray() function. There's no reason why your code should be cluttered up by all of the text that doesn't convey anything. You only need to know that it's a 3d array of floats, so why should you have to write all this extra noise? The code is there for the benefit of you and your fellow man. Source code isn't a set of instructions for the computer, it's a tool for communicating with other humans. The computer only understands assembly. If you really think that having a "pretty" language isn't important then I would challenge you to write literally any major program in assembly. I have a feeling you will never take me up on the challenge. Having code that looks nice and is easy to read is much more important than having optimized code in the majority of situations. Processor time is free these days, there's no reason to waste brain time doing what the computer can do at compile time. The developers' time is far and away the most expensive resource that goes into writing software.
isn't there also a risk that auto will fuck up my shit? For example: double vec[2]={2, 5.3}; auto dummy=0; dummy=vec[1]; Now fummy will be just "5" because i missed to type "0.0" if i just had used double it would be no problem.
Whether or not you agree with what he says, nobody can disagree that this guy is a brilliant public speaker.
I don't agree. He's good in style, but his slides are TERRIBLE. He doesn't follow any recommendation on slide style I've read. He adds lots of text he doesn't read to the audience, who's trying to listen and read at the same time. He adds "taboo" colors, like light green, yellow and such. He uses different styles on each slide. Seriously, to be there in person, I'd never understand half of it, if you are not an expert.
@@darksidegirl good presentation style dictates you should not read what's on the slide directly. Slides supplement your talk.
i would rather a talk by key note speakers be information dense even if I have to go back and watch it on RUclips again.
He's C++ guru
He literally designs the new features along with other people in the Committee
He's a brilliant bookist as well. I have several of his books on C++ and they are awesomesauce.
A passionate, humble, learned man giving an engaging talk. This feels like reading K&R felt. Such clarity and simplicity in that which seemed so complicated when learning it in other contexts.
K&R book is such a masterpiece. It's probably still the best book on the subject ever written. No other book comer close to its simplicity and compreensiveness.
I feel like the people who are still saying (even today) that cppcon is just an echo chamber of experts talking to each other, with little of value for an average developer might have had a point at some time in the past, but that certainly by the point of this talk it was not true. There have been countless great Back-To-The-Basics talks and others that show that they are very actively trying to increase the circle of C++ competency, and are not at all obsessed with hyper-expertise that could only be understood by a group of people that fits in an auditorium, much less an elevator. Great stuff.
Note: 47:30 (auto x = type{init}) making a temporary+move: this has been fixed in C++17 by copy elision. Type does not even have to be moveable.
It's ironic how Herb come into realization C++ defaults are beyond repair and begun cppfront initiative in 2016.
Brilliant work that still feels relevant 8 years later.
re: auto type deduction - I think my fear of it comes from ending up with std header compilation errors later in the maintenance cycle. Working with C++ and watching videos like this one is making me smarter all the time, but I think I'm maybe just not quite smart enough yet. But this definitely convinces me to try using it more.
re: C++ developers care a lot about performance - Well, the only time it really makes sense to use C++ is if performance is a higher priority than time to market.
I agree with the philosophy here. The day I gave up on typing perfectly optimal code is the day I became 100x more productive
go write in php or java then.
@@ViolentFury1 Very nice answer.
@@ViolentFury1 you know java can be faster than c++. I will give you a hint it rhymes with git
@@ViolentFury1 those don't let you "open the hood when you need to" as Herb described. Just.. Don't open the hood every time.
It drives me crazy that so many of this video shows Herb instead of his code!
Go and grab the slides, and have Herb and his code at the same time! :)
Yeah especially 56:00 and forward.
He even draws attention specifically to the importance of watching the screen right then.
Whoever put this together doesn't care. He's just mesmerized by Herb I guess.
MrSnowman Yeah seriously. It is like they swapped to a fresh camera guy that wanted to get more action.
slides available here github.com/CppCon/CppCon2014/blob/master/Presentations/Back%20to%20the%20Basics!%20Essentials%20of%20Modern%20C%2B%2B%20Style/Back%20to%20the%20Basics!%20Essentials%20of%20Modern%20C%2B%2B%20Style%20-%20Herb%20Sutter%20-%20CppCon%202014.pdf
Herb is by far my favorite speaker from these conferences
Chandler and Herb are my favorites! Many thanks guys!
the content is great but the cut's are horrible, there are so many times the slides would be helpful but only the speaker is visable
This is the hardest "Back to the Basics!" talk that I ever watch.
This is extremely useful, especially the parameter passing.
such a simple and honest guy
1:33:00 You can do it with structured binding in C++17:
_std::set< int > digits = { 1, 2, 3, 5, 6 ,7, 8, 9, 0 }; // missed 4_
_for( int i = 0; i < 10; ++i )_
_{_
_auto const& [it, result] = digits.insert( i );_
_if( result )_
_{_
_std::cout
why is the camera mostly on him rather than the slides?
41:10 been thinking about this for a while. Nice to see it being covered here
It is 2022 and this presentation is still extraordinary and the speaker is fenomenal!
By far the best c++ presentation I have ever attended!
"C++ is evolving man, we're going faster."
2
When it comes to option 4 for set_name, Herb, the confident guy in the audience and the guy expressing his surprise about its performance advantage in the end curiously all messed it up at some point.
Herb firstly messed it up, because compilation of the code on his slide will fail as soon as used with a string argument because of the exclamation mark. Without it, compilation will still fail as soon as used with a char* argument, as during his benchmark. Herb is simply wrong with his "Write it right", instead do not constrain the template unless the function is overloaded.
So the confident guy in the audience is right saying Herb constrained the template wrong. But it is even more wrong than he apparently expected. Because of the erroneous exclamation mark, the function will indeed accept a string literal.
Finally the guy expressing his surprise about the performance advantage of option 4 appears to have a valid point at first sight because without the exclamation mark the template should generate at compile time the exact code of option two. But it only does so if used with a string argument. A char* argument causes compilation to fail as mentioned before. If the entire constraint had been correctly left out, then there would be no reason for surprise either because the generation of a char* template instantiation enabling the usage of string::operator=(const char*) clearly accounts for the performance advantage.
Despite Herb's attempts to shift responsibility onto Howard, I think, Howard is the only one involved who has got everything right. He was dealing with an overloaded function in a different context like a constructor overloaded with copy and move constructors. His function being overloaded with a function taking some type X, in order to prevent the forwarding reference from matching X too, he had to write an template constraint to exclude X from the template, hence the exclamation mark. Herb just blindly copied Herb's code from a different context, fiddled with the data types according to his faulty understanding of the purpose of the constraint, and ended up with something which is wrong for multiple reasons.
You have, without intending to, demonstrated everything that is wrong with C++.
@@adaai2384 well, it was exactly the Herb's point - Howard is one of 5 people in the world who can write it right
Thanks for the clear explanation. Even Herb, who's lecturing this, make such near absurd mistake. It should serve as an alert.
No. The main difference is that the copy-and-swap idiom is not about avoiding unnecessary work, but about providing stricter guarantees, in particular regarding exception safety. If you want to have the strong exception safety guarantee, you must pay the price and create a new temporary object, for that you cannot leverage the memory that your current object holds.
This is a good point. In most projects I've worked on, the first one is by far the most common (maybe because it's older) but very easily recognizable as "oh, that's an STL object iterator!". The other thing to look at here is how readable it is to new developers of C++. In my opinion, it makes more sense and is more readable because you are saying: "I'll start the beginning, until I reach the end, and advance one object per iteration" pretty explicitly.
Does it make python an obfuscated language ?
You have it exactly backwards. You're just used to the old way of doing it, but for a novice it is the opposite.
There is a mistake on this slide: i.imgur.com/1nqH4Ct.png
Actually, here you can see that mistake is in PDF presentation, but not on the screen behind Herb: ruclips.net/video/xnqTKD8uD64/видео.html
And, I found that it's easier to line up all those equal signs (tabularize them) with auto
Like Herb mentioned:
"It reflects bias to code against implementations, not interfaces".
Good code design should focus on "what" the code does, and not "how" it does it.
This is particularly important if you are creating libraries for other people to use.
This is all very interesting, but it would also make sense IMHO to, at some point in the life of the C++ standardization process, spend some time to ensure that the C++ standard library is usable with Unicode text. I mean, usable as in Python 3, for instance.
didn't know languages that aren't Turing complete were fully usable
@@natewind Couldn't agree more! The only thing you actually care about is byte length of a string. Everything else is way too complex and specialized
35:09 "why deduce correctness" IMO weak argument to go to auto, because if you change something so significant that you starting modifying, when you haven't before, it's not small change, and have need to look at code more careful (because now types are different) is just a plus.
a small advice for the video maker, you need to focus the camera a little more on the slide.... we need time to read that.... thank you
About prefering auto for declaring local variables:
The auto keyword makes code harder to read (type deduction) or document. It makes it worse even, because if you change a return type you don't want undesirable side effects that pass undetected. The compile time error is your friend when refactoring a code base. Much better than having run-time erros and it also gives the opportunity to review the code and detect problems ahead of time.
You're kind of missing a big piece of what he is saying. If you're coding to an interface then you can use his "tracking" auto declaration but if you are coding to an implementation then you need to use his "stick" or "commit" style which is 'auto x = type { foo() };'. This is better b/c it conveys that your intention is to code to a specific type and not an interface. It is more expressive.
"This is better b/c it conveys that your intention is to code to a specific type and not an interface. It is more expressive."
No, it's literally just more typing.
@@isodoublet you're still not understanding the distinction between "interface" and "implementation". You shouldn't need to know the exact type in most situations if you're relying on the interface instead of the implementation. If you were in the business of using or extending 3rd-party libraries you would understand why this distinction is important.
He didn't quite convince me that mass auto is the right way to go. In some cases, when a change in one place tracks to all the other variables, I'd be afraid of it silently resulting in the wrong behavior. Of course, auto is needed for quickly writing templates too (and his initial example was template-looking code!). I also like auto when it takes away huge types that provide no real information for sure such as vector::size_type. I'm also all right with it reducing redundant type information as he showed. However, I like types! They document what kind of operations might follow next as a type restricts what might be done using that variable. I wonder what Bjarne Stroustrup's modern C++ guide recommends. They're also essential for forwarding references and for writing the output of a function in terms of the arguments.
The rest of the talk was great information. It can be hard to maintain interest for close to 2 hours about programming, but he pulled it off.
17:15 I would have thought that the function could be participating in the ownership if it's potentially keeping the object alive just by holding the shared_ptr. It's not only participating in the ownership if it's stashing the shared_ptr in some global registry or something.
I remember folks making the same doom-and-gloom arguments against var when it was added to C#, but they were quickly proven wrong and now everyone uses it to great effect on readability and refactorability. C++ introduced auto only a few years later, and people are still debating it. Is the C++ community just reflexively contrarian?
As usual, great stuff Herb!
What does he mean "range-for doesn't support early break" ? I see it does.
The concept of clear simple code is not so clear. In one of my teams people didn't know range-for loop, it wasn't clear for them. “Clear” code for the developers in that team was the code that the least knowledgeable C++ developer could understand, practically C style. Otherwise they used to say it's difficult to follow. Also less function calls was more clear for them. A thousand lines of code in one function was better then 10 function calls, because they said otherwise they have to search and check each function code to follow. But what if the function name is very clear I used to argue? Doesn't matter. No amount of arguments you might hear from Herb, or Bob, or Kelvin, or Sean could help. They opposed even auto. Ah, and no templates.
What I am saying is it might be quite challenging to serve that ~3M community of C++ developers. Sometimes I think we have to revert C++ back to C to make code “clear” for them. They program --C++.
The main problem is that they are reluctant to accept change like many "experienced" guys. But any C++ programmer who cannot understant a range-for loop is dumb or (more likely) in bad faith.
They can understand it. It's just not what they consider as clean code. What I am trying to say is that if we try to serve 3M community of C++ developers, we must admit that we have to forget about clean code in Herb's sense. Most of these 3M developers program to implementation, not to interface, and don't want to learn anything new.
At roughly 23:00 he is nearing his statement about dropping a reference count and what to do about it. 23:23 is perhaps the closest point to start, but before is better.
did the video have the audio gaps before?
I want so much to become a professional C++ programmer , i know simples things for now i do computer science . But where I live there is not any possibility of chance to get any job or oportunity...
aww poor you, go cry some more
To become a professional C++ programmer, you have to become a professional in algorithms and data structures first. Along with a lot of practical experience, not only in programming. Knowing a programming language well doesn't make you a professional.
Conenion i study graphs , binary trees , algorithm complexity , all kind of sorting algorithms and arrays structures ,pop push etc , every kind of things in the university I don't know everything but I can handle
If we're no longer encouraged to pass-by-value on setter functions, does this mean we should also discourage copy-and-swap assignment operators, which suffer from the same problems?
With mandatory RVO in C++17, it should now always be ok to return by value no matter the size of the created object.
NRVO is not mandatory though.
Except that in many cases RVO doesn't apply, and it's impossible for an average developer to reason about when it does apply and when it doesn't due to so many edge cases :/
Perhaps he means that range-for doesn't let you write a break condition that depends on the iterator. You only see the values behind the iterator.
Thank you very much Dr Herb Sutter
for (e : c) does not work as of Visual Studio Preview 16.11.
IMO for (e : c) makes coding "easier" but not "simpler" than for (auto& e : c). Conceptually, both are the same thing, with the latter actually be clearer that e is a reference to an element in c. But implementation wise, the former requires less typing.
1:15 the concept of "unteachable" perfectly illustrated
The mindblowing thing is that by Sep 2014 they still didn't decide on the name for Type&&
I rewound to the 42:00 "but wait there's more", I find that quite funny
I really need to watch this on a pc
1:15:00 What's problematic regarding noexcept isn't the function itself. What's problematic is C++'s automatic implicit copying that can happen basically anywhere without the programmer noticing.
I used to really love Herb's talks until I realized the talk was usually the only thing to come out of them :( maybe a prototype on godbolt.
Hmm nothing but critics in the comment section, but 1k likes/30 dislikes... Do CPP programmers just like to complain?
yes
Correction, Herbie. The type of "Hello" is not const char*. It's char[6]; 40:56
I just tried it and it is const char*.
1:24:10 "...when you copy you also have to get rid of the previous state; when you move you don't"
He mean't the exact oposite, right?
No, he is right
imagine a variable x and y. If you create variable x, it exists on memory. If you are copying x to y, x is still alive. But if you move it, you move the complete variable and x is no longer alive.
@@gcanary562 Only true if it is trivially destructible
@@kim15742 can you explain why the type must be trivially destructible?
shared_ptr is non trivially destructible and can be moved (it can just be moved).
I think that the best example is vector. If you copy the original one remains untouched, but you need to allocate memory for the internal buffer of the second one and you need to execute the copy constructors of every Item (they may be trivially copied, but you need to copy them). If you move a vector it is left to the implementation of the move constructor to decide what to do; the move constructor can leave the original vector in an invalid state, what it must do is make the new one valid.
A naive implementation of a vector can be a raw pointer to Foo and two size_t to store the current size of the vector and the current buffer size. In this case the move constructor can just copy the raw pointer and the two sizes in the new vector and set the raw pointer in the old one to nullptr, which makes it invalid. The non trivial distructor can just check for this state (is the raw pointer nullptr) and do nothing.
@@CarloBernaschina the destructor might as well avoid the check as deleting a nullptr is defined behavior and results in a no-op.
@ 30:05 Can someone explain to me what it means to make a type _track_ or _stick_? Beyond deducing the type or explicitly declaring the type I do not understand what these terms mean, nor have I heard them outside of this talk. Thank you.
It just means that auto "tracks" the type itself.
For example if you have to classes
class Tool;
class Hammer : Tool;
If you now have an object of the type "Hammer" but you want it for any reason to be sure it should be stored as a Tool and not a hammer, you should stick it.
Wow ! So great. You help me a lots.
Can anyone explain me what the NOT-operator (!) is doing in the perfect forwarding example? From what I see the author wants to restrict the templatisation to the type std::string. I'm referring to this line:
template::value>>
I don't understand why the NOT operator is there. In my opinion it results exactly in the opposite of what shall be achieved.
Please refer to my other comment below this video.
The auto keyword is evaluated at compile-time.
'at least i thought he was a friend' let me get some popcorn, this is gonna be good
At 1:17:00 setName function is marked as noexcept and takes an rvalue parameter and perfectly forwards it. But if setName is passed an lvalue, it might cause an allocation inside the function as it would be an assignment? In that case it cant be marked noexcept?
True. The expression inside the noexcept qualifier make the function noexcept if and only if the String type can be assigned to std::string without throwing. Otherwise it is not noexcpet qualified.
Question for the slide "pass by value" (1:12:00) : Would the code work also without the std::move? Is it used only for performance?
Sure, it would work. However it would be slower for longer strings (short strings are actually copied and moved at the same speed).
Long things short : without move -> allocation and memcpy ; with move -> copy of a pointer.
When not using move, you are calling the copy assignment operator that 1. resize the buffer of the name_ string (allocation) 2. copy the content of the buffer of name into the buffer of name_ 3. delete the buffer of name at function return.
When using move, you are calling the move assignment operator that 1. delete the current buffer of name_ 2. bind the buffer pointer of name_ to the buffer pointer of name 2. set the buffer pointer of name to nullptr (or equivalent)
"ptr"
Is there a cheat sheet for all this? (especially the unique_ptr and pass by ref vs pass by pointer etc)
yes: CPP Core Guidelines
9:30 - answer is, the top one is easier to parse visually by someone coming to the code who hasn't written it. In fact it would be even clearer without the 'auto' as the type would be immediately visible.
You've got Stockholm syndrome from C if you think the standard for loop is "easier to parse visually" than a range-based for. To even be able to understand the top code, you already have to know about iterators and whatnot, and once you know that stuff the second code is much clearer because it provides the exact same information in a condensed form, without all this extra visual noise. There is literally nobody on the planet who would be able to understand the top without being able understand the bottom, so why not just use the bottom code? Why should a developer have to waste their time writing out boilerplate when they could just write out exactly what's relevant and nothing more?
Yeah, auto really does hide useful information.
I had to shake my head a few times so far.
Using smart-pointers is always messy, it promotes not thinking about the lifetime of objects at an architectural level.
It creates multiple ways to do call chains that are fixed, while requirements might change at a deeper level.
Better is to avoid the heap concept as much as possible, even if under the hood a heap is used, the stack model is the natural model for C++.
" it promotes not thinking about the lifetime of objects at an architectural level"
Exactly. They undoubtedly have their uses, but this point needs to be made.
Watch his Cpp2016 talk "Leak-Freedom in C++" where he shows how to write simple, fast and leak-free code. And yes, he says that most of the time you should use stack and not heap.
@@Ashamaalidon't agree - using unique_ptr you always immediately know the lifetime
So, why the fourth bar is so small in the last benchmark (the on the right)?
For the performance to be like that, you need your char* to be an rvalue in the first place.
set_name("John"); //OK
char* name = "John"; set_name(name) //Not OK
Now, your temporary char* is passed to the templated set_name. The compiler then specializes the template with T = char*&& (rvalue reference).
Then, the reference collapsing rules apply and make 'char* && &&' become 'char* &&'.
However, the parameter name is an lvalue, just as any reference (rvalue or lvalue ref). Thus, it must be "converted back" to an rvalue before being sent to the assignment operator of string. This is what std::forward is made for.
Finnaly, string::operator=(char*&&) is called. This causes the char* to be used by the string directly as its buffer (no copy, no assignment).
In the end : 1 allocation to create the char*, no conversion, no copy. The other approaches involve at least one more allocation for the conversion from char* to string followed by deletions.
@@gabrielb.2886 string::operator=(char*&&) there is no such an operator. The difference is because with const& + && you first call string(char*) with likely frequent allocation, then call a move constructor vs with option 4 you call string::operator=(char*) which with high probabilty incurs no memory allocation
Why wouldn't you be able to use it? You just call "get" and get the raw pointer.
Quite worthwhile.
Is there any room to change the spec for a simpler solution to the shared_ptr dereferencing problem at 23:48?
Ideally, the library specification should have been that dereferencing operations on std::shared_ptr<T> should all return a std::shared_ptr_deref<T> object that ups the refcount during its lifetime and which has an implicit conversion to T&. This way the reference will always be held while the object is being used.
I hope that can be changed in upcoming c++ versions
you can just copy the shared_ptr to increment the refcount, no?
What about the overhead of such solution ? Ref counting is thread safe in case you forgot, which makes it very expensive in a context of repeated pointer dereferencing.
Here, you have to take care of yourself in these quite rare cornercases. Otherwise, it's as fast as it can get.
47:12
_auto m = std::mutex();_
_auto lg = std::lock_guard( m );_
is perfectly legal thanx to copy/move elision in C++17
THANKS for the upload!!!
Well, allright lets make c++ more powerful even though I don´t believe that every change will be successfully adapted :)
This is quite a weird beast "template", I guess I am visiting too few TMP hackathons!
can somebody please explain why this is a good thing?
@@mikevasiljevs412 PM me and we can discuss it - I am not sure ai will convince you though
This is all nice and clean; but in that case, I'd like to get that `auto` be renamed to `let` or `var` for variable declarations. and something similar to function declaration (instead of `auto f(int x) -> int;` something like `func f(int x) -> int;` but then again, the next issue is parameter declaration lists, which are still right-to-left. :)
ah, i need this
Did someone handpick that thumbnail clip? :P
Auto... what a debugging nightmare it would be if the types of objects were hidden like that.
Thankfully the types are visible to debugging tools. What people fear the most is having a type you didn't intend to have, IMO in that case do use explicit type or the auto syntax he showed.
40:07 "try sticking it to the right, it will feel weird the first couple of times" lol
Why is he saying "share putter" and not "shared pointer" ?
He's just pronouncing ptr as "putter." Like he says "stud" for std.
But why?
Even during this talk, I feel Herb himself is a victim of what he is trying to teach against. The simple mention of "does this every time you are iterating through all elements" instead of "any time you iterate" means that you have to have two variations depending on whether you iterate through some or all. Isn't this "non-default" in itself?
It is default. More than 70% of my for loops are range-for loops. Other loops are either reverse iterations or index based iterations because I need the index value.
How often do you actually write a for-loop that doesn't interact with the whole collection in order? It's rare, most of the counterexamples are just doing the whole collection in reverse order, or index-based for-loops when the author needed the index for some reason.
Don't think of range-based for as a rule, it's just a design pattern. It's a simple way to make the old iterator-based syntax more brief and clear.
I iove c++
no subtitile?
If i want to get my hands on gcc 7 where do i go?
Nvm, look like i'm gonna try Clang instead. Seems to be a somewhat related version in my repo.
cool beans
Hi I'm Jon and I'm CA :D
at 9:02 Herb Sutter encourages to prefer range loops over conventional counting loops.
I cannot see any advantage in this whatsoever, if you don't count the additional array border safety. And i don't !
No developer in his right mind will produce an array border violation after 1 year of experience.
Try this to judge for yourself :
#include
using namespace std;
#using
using namespace System;
const unsigned int Size = 60000;
void main()
{
char Numbers[Size];
DateTime EndTime = DateTime::Now;
DateTime StartTime = DateTime::Now;
TimeSpan elapsed;
// Counting Loop:
for (unsigned int i = 0; i < Size; i++) // forward iteration
//for (unsigned int i = Size-1; i > 0; i--) // backward iteration
{
Numbers[i] = i;
}
EndTime = DateTime::Now;
elapsed = EndTime - StartTime;
cout
Apparently they are more concerned with Array Boundary Violation Safety than you.
Thank you - must have happened when i inserted that line along with other alternative comments. Very astute ! Well done!
But what really went wrong there was that accidentially (maybe because i was working on a project where i used this one) i chose the "wrong" implementation of the range loop - in fact, this code partially is "Managed C++" instead of C++11, which means i used a for each loop from .NET including the "System.dll".
The proper loop header schould be:
"for( char& ri : Numbers )" which is c++11 and not
"for each (char& ri in Numbers)" which is managed c++. In MFC there also is a "for_each" range loop (Note the underscore).
But that one would need iterators, which a primitive type char array does not have. This is the cause why they introduced an "Array" class in C++11 which exposes iterators even for primitive types.
You do see the irony in bragging about why not to do something when at the same time making a mistake showing exactly why to use something...
Look, the "conventional" for-loop with this manual counter is just cumbersome. Most of us just wish to loop through an array in a comfortable way, like in Java or JavaScript. For your special cases, you can do your traditional for-loop, but it is not the rule.
Can you please do the same with a structure without random access iterators such as a list ? Can you also give me one good reason to continue using c style arrays on the heap when std::vector has almost zero runtime overhead while providing everything you need for both forward and backward iteration ?
And finally, why should I bother with a counter if everything I do is "for each element, do something, regardless of its actual index" ?
The only reasons I can think of to use a counter is when you actually need the index and when you are iterating over several containers simultaneously.
A lot of food for thought.
There must be hundreds of boilerplate writers (obfuscation engineers) at Dinkumware.
Hi with the Herbs.
Who came up with the idea of unique and shared pointer language construct. It is ugly, confusing. Why was C++ simply not extended with new keywords?
"This is the slide ..."
@ 58m25s
auto x = 10;
Why not remove it all together and just write
x = 10;
Because that becomes an assignment statement not an initialiser statement
If without auto, how to resolve the parameter and local variable?
void foo(int x) { auto x = 10; } // ok
void foo(int x) { x = 10; } // ok
void foo(int& x) { auto x = 10; } // ok
void foo(int& x) { x = 10; } // wtf?
@@varphonewong4068 your recreating the variable x.
void foo(int x) { auto x = 10; } // your creating x as an int in the parameter and then your creating it again as an int ("auto") in the body, does this even compile?
@@varphonewong4068 nope! ,
error: declaration of ‘auto x’ shadows a parameter
That Mike Acton guy needs to watch this
call me old fashioned, i still prefer procedural style
36:00
20:00
I also don't buy Herb's arguments for auto. I never liked it because it covers up types and makes code much less expressive. Everyone wants his code to be "self documenting" but with auto you take exactly this away. So when I try to read code from another code base I would be faster to interpret what it is doing even if the initialization spans a whole line and doesn't look pretty... I think behind the scenes most of the bias towards auto anyway stems from the fact that "it looks nicer" and you can line up your equal signs better - which really shouldn't be a valid argument for a programming language or should it? That's rediculous.
Dude, have you ever tried initializing a nested container in C++? Nobody wants to type six right angle brackets and the same type name three times just to instantiate a 3d array, and they especially don't want to type out some of these 3rd-party library type names that span a whole line.
Most of the time, the unabridged type name is just noise that makes it more difficult to see the logic. It's important for code to be clear about *intent.* It is not important for code to be clear about the exact implementation of every type you're using.
Imagine if you couldn't use the "int" type name anymore, and had to specify the exact width of every int you used. It would get tiresome quickly, and in the vast majority of situations the exact width of the int isn't relevant. Only in a few situations does it make sense to say, specifically, "this is a uint8_t" or "this is an int16_t", almost always when you want to do some kind of fixed-point arithmetic or when you want to use an overflowing int for some purpose. It's sort of the same idea with "auto". Most of the time you don't need to see every single template parameter in detail, you just need to know broadly what type of object you're dealing with. In the situations where every minor detail of the object is relevant to the logic of the code, don't use auto. We shouldn't get rid of auto entirely just because it's better not to use it in certain situations.
I propose that if you want to see all the details, you can still use "auto". Write a function that takes the relevant template parameters as its arguments, and then use "auto" when instantiating the object to keep the code uncluttered. That way you get code that looks like this:
```auto arr = ndarray(k = 3, T = float);```
Instead of like this:
```std::vector arr = std::vector();```
The first code is obviously better for clarity, and if you need to see the exact details that you can see in the second code, you can always go read the ndarray() function. There's no reason why your code should be cluttered up by all of the text that doesn't convey anything. You only need to know that it's a 3d array of floats, so why should you have to write all this extra noise? The code is there for the benefit of you and your fellow man. Source code isn't a set of instructions for the computer, it's a tool for communicating with other humans. The computer only understands assembly. If you really think that having a "pretty" language isn't important then I would challenge you to write literally any major program in assembly. I have a feeling you will never take me up on the challenge.
Having code that looks nice and is easy to read is much more important than having optimized code in the majority of situations. Processor time is free these days, there's no reason to waste brain time doing what the computer can do at compile time. The developers' time is far and away the most expensive resource that goes into writing software.
If you a whole line just for type information auto is just hiding the problem.
C++ has become a mess ...
the irony of a c++ programmer advocating "simplicity" is palpable...
c2com interface the code 2015
isn't there also a risk that auto will fuck up my shit? For example:
double vec[2]={2, 5.3};
auto dummy=0;
dummy=vec[1];
Now fummy will be just "5" because i missed to type "0.0" if i just had used double it would be no problem.
That has nothing to do with "auto" and everything with you doing an implicit type conversion at the "dummy=vec[1];" assignment.