CppCon 2014: Herb Sutter "Back to the Basics! Essentials of Modern C++ Style" 

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

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 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 RU-vid 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.

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.

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.

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.

yes

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

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

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.

Please refer to my other comment below this video.

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.

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.

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.

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

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)

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.

yes: CPP Core Guidelines

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

He's just pronouncing ptr as "putter." Like he says "stud" for std.

But why?

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.

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.

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

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.

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.

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.

" 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

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

I just tried it and it is const char*.

The complexity of the language comes with the great power it gives. Those people you talk about and envy probably don't even know what a pointer is and what it's used for. If you're watching this video I suppose you enjoy the benefits C++ gives to developers. Well, that is the other face of the coin...

@lot Rust or Go are pretty powerful as well and they're nowhere near as complex as C++. C++ just sucks as a language. It's obviously designed by a committee and not by someone with a coherent vision for the language. Every member of the committee gets in every feature they want. And it's a total mess overall without any good design.

Not really , mike works on AAA titles where he actually has to live within the 13ms limit which is THE time for people to over optimize and use every micro optimization to run things faster , so its justified in his case

Nvm, look like i'm gonna try Clang instead. Seems to be a somewhat related version in my repo.