I've been having a bit of a binge-watch on Kate Gregory recently another addition to my rather short "hey! This speaker is actually good at delivering a talk" list.
Thank you Kate. I've been using and trying to learn C++ well since 1999! Recently, I'm doing a deep dive. I've watched two of your talks today and feel more knowledgeable and also more confident in my choice to spend time learning.
This talk was so good in the first 20 minutes I created a playlist of great talks and added it (along with a few others). First talk I've seen from Kate but I've queued up others
Hearing the recommendation to learn all the language I can’t help recalling when I learnt how to use auto_ptr, then learning the hard way how not to use it, and eventually welcoming its deprecation.
The point of programming is learning, this includes both the program domain and the tools. Both the tools and the problem domain change over time, hence the necessity to learn, continuously.
Holy s***.... This gives me an endless hope as I came here just to learn how to solve the partial differential equation for convection-dispersion problems!
38:13: "you label 'cachedValue' and 'cacheValid' as mutable and you are done." Well, if you want your class to be safe-thread (in a sense that any class of the standard library is thread-safe), you have to use either a lock around getting or setting mutable variables or use atomic in such a way that preserves consistency if two threads invoke that function concurrently, because when a function is declared as 'const', there is a general assumption that it is safe to invoke this function concurrently for the same object. In case of the C++ standard library, the C++ standard is explicitly guaranteed that it is safe for all its classes. As to C++ exceptions, the current situation with them is not very good to put it mildly. Fortunately, there is a proposal in the C++ committee (written by Herb Sutter) how to make exceptions efficient and deterministic: www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0709r0.pdf
atf300t if you’re using mutable for anything but simple purposes like function hit counters, you’re using the wrong architecture. A const function is making a promise. If you break that promise at all, it should only be for trivial items and any possible bad side effects should land in the lap of the function developer; nothing should leak out the interface.
What if the weekly process that needs the value needs to refer to the value in multiple places? Either the value is cached in the class to avoid multiple expensive calculations, or it is up to the process to store the result somewhere and pass it to the different parts that need it. The complexity in avoiding unnecessary work has to be put somewhere, and the class that generates the value seems like a good place to keep it.
Nice for pros not helping beginners. Not someone like me having to decide whether to recommend learning c++ or something else. How many semesters decent (meaning one who will finish its university studies in computer science) does Computer Science student needs to learn to program in C++? This is a simple question with one number as an answer. For those telling less then a 2 i will ask for exact literature. I am programming in C++ since 1989 and i am telling to those making language changes and guidelines. People who are proficient in something very often forget that there was a day in their life when they knew nothing about the thing they are good at. It is easy to read 2000 pages of text if you understand text not so easy when you are starting. My copy of Stroustrup book was 320 pages long.
1:45:00 look, last time i tried implementing tic-tac-toe, i ended up with conway's game of life being played on a minesweeper board, don't say it is simple!
Of course you should understand the language you're developing in. A more interesting discussion is whether or not the complexity of C++ serves the goal of creating software to solve problems reliably, accurately, on-time and on budget. If you're stuck developing in C++, you should understand it, and accept the years of your life that it will take to properly learn it. You should also reflect on all of the other things you could have done with your time and brainpower. Yes, computer software is complex and often requires complex solutions but it does not follow that the complexity of modern C++ is justified or reasonable.
There are some really bad points in there. 1:03:00: unnecessary cast, because somebody might not know the rules of the language? Really bad idea. There's a reason why some conversions are implicit and others aren't: the implicit ones are the ones where not much can go wrong. Derived class pointer to base class pointer? Nothing can go wrong, so it's implicit. Base class pointer to derived class pointer? That can go wrong, so it needs a cast. The problem with adding an unecessary static_cast is that you might some day change that code and make a mistake along the way that changes the type of the expression to something that cannot be implicitly converted to the target type. You really, really want the compiler to tell you about that, but it won't because of that cast. And when it comes to this particular example: why would you want a conversion in the first place? Just write what you really mean: return x % 2 == 1. 1:34:44: I can't count the number of times I've heard this nonsense: “If you're out of memory, anything you could do to handle that will require memory, so don't bother”. Yeah, except there is something you can do that doesn't require memory, and that is … *drumroll* … freeing memory. In fact, her example demonstrates how that just happens naturally without one even having to think about it. When you try to read a gazillion strings with that code, it's going to stick them into the vector until it runs out of memory. Then it'll throw std::bad_alloc and start unwinding the stack. res's destructor will be called, freeing all that memory we just allocated, and by the time we enter the hypothetical catch block, we have plenty of memory available to do whatever it is we need to do. 1:44:53: I hate it when people spread this idiotic meme of a nuclear reactor being something that will explode all the time unless you actively do something to stop it. You know what keeps reactors from exploding? Spoiler alert: it's not computer programs, it's physics. You can't even get a reactor licensed today unless it has a negative temperature coefficient of reactivity, meaning that when temperature goes up, reactivity goes down. And that's just one physics-based safety mechanism, there are many others. Just look at the passive safety designs of modern reactors like AP1000 or BWRX-300 or NuScale before engaging in anti-nuclear fearmongering. We really don't need any of that, particularly at this time when we need reliable, CO2-free energy more than ever before.
One thing I contemplate about is whether C++ is too broken to be useful. Over the past 30 yrs I've been watching C++, a lot has been learned on how we want a programming language to look like, and C++ has incorporated much of it. But the design decisions of backward compatibility and "we want absolute control" mean that it's complicated. Take a look at pointers for example. If raw pointers are bad, why is it that a program making was use of raw pointers is more concise and readable than a program that isn't? It's because of backward compatibility. And if exceptions are "mostly bad", why do I have to add "noexcept" to every function? why isn't it the default? backward compat. And when a program doesn't compile I get an obscure template error instead of "you passed the wrong parameter" - that's because we want control. So it ends up that you *can* write a good C++ program, but it has to be riddled with "warts" such as make_unique(), noexcept, std::move(), and such. And then they come to you saying "but you can avoid the std::move using IIFE!" REally? I have to learn a new idiom just to remove another wart? If I compare to Golang - I complete the golang tutorial in a day, then with the help of stack overflow and some blogs I immediately write idiomatic, readable, and quite efficient Go. In theory I don't have as much control, and there are some cases where C++ can produce better results, but I wonder whether the "simple and idiomatic C++" which is hard to learn as Kate confesses, yields more efficient code than Go. Problem with Go is that it dosn't integrate with legacy. What I'd like to see is a new language that uses C++ runtime (sort of like Kotlin simplifies Java)
Not any raw pointer, owning raw pointer -- a crucial detail that you missed. This applies to move as well: you cannot and you shouldn't eliminate it with something else -- these are all different instruments for different cases.
That does the job. I think there might be another way (not better, just different) based on the fact that we use digital computers with binary numbers. So an odd number should have 1 as the last bit.
I've been having a bit of a binge-watch on Kate Gregory recently another addition to my rather short "hey! This speaker is actually good at delivering a talk" list.
I always enjoy Kate's talks. Great as always.
Kate’s talks are always super interesting, and she consistently makes me think about things in ways I hadn’t before.
I did Kate's tutorials on Plurasight, since then she's pretty much a must watch If I ever see her in a video.
I'm actually proud when I can master this complicated language C++. Not everyone can do it. She made a good point here.
Thank you Kate. I've been using and trying to learn C++ well since 1999! Recently, I'm doing a deep dive. I've watched two of your talks today and feel more knowledgeable and also more confident in my choice to spend time learning.
This talk was so good in the first 20 minutes I created a playlist of great talks and added it (along with a few others).
First talk I've seen from Kate but I've queued up others
Hearing the recommendation to learn all the language I can’t help recalling when I learnt how to use auto_ptr, then learning the hard way how not to use it, and eventually welcoming its deprecation.
I really liked your talk. Really Amazing. Thank you so much .
What a phenomenal talk!!!!
Love her
Awesome talk.
Very good. Thanks for sharing. Funny, I've been coding c++ at work for nearly 20 years and I didn't know about mutable either :p.
I want to be Kate Gregory when I grow up.
That was really good!
awesome talk, really like it
She’s amazing !
"If it's easy, anybody can do it. If I'm doing it the easy way, am I the best one in the room anymore?" Every single time I choose python over C++.
The point of programming is learning, this includes both the program domain and the tools. Both the tools and the problem domain change over time, hence the necessity to learn, continuously.
Well put together! People, who left when templates were added, missed this point completely. One have to adapt continuously.
This was a fun one. I've got a list of some C++ acronyms to look up now... and a Slack to join (:
Kate++
Steve Sperandeo kate--
Holy s***....
This gives me an endless hope as I came here just to learn how to solve the partial differential equation for convection-dispersion problems!
38:13: "you label 'cachedValue' and 'cacheValid' as mutable and you are done."
Well, if you want your class to be safe-thread (in a sense that any class of the standard library is thread-safe), you have to use either a lock around getting or setting mutable variables or use atomic in such a way that preserves consistency if two threads invoke that function concurrently, because when a function is declared as 'const', there is a general assumption that it is safe to invoke this function concurrently for the same object. In case of the C++ standard library, the C++ standard is explicitly guaranteed that it is safe for all its classes.
As to C++ exceptions, the current situation with them is not very good to put it mildly. Fortunately, there is a proposal in the C++ committee (written by Herb Sutter) how to make exceptions efficient and deterministic: www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0709r0.pdf
atf300t if you’re using mutable for anything but simple purposes like function hit counters, you’re using the wrong architecture. A const function is making a promise. If you break that promise at all, it should only be for trivial items and any possible bad side effects should land in the lap of the function developer; nothing should leak out the interface.
I guess you are in that Slack group
Fantastic example of why RAII is a good idea
"...how it's able to do it; through the magic of slideware" :)
Why cache the value if it's only ever read right after calculating it and only being read once a week ?
What if the weekly process that needs the value needs to refer to the value in multiple places? Either the value is cached in the class to avoid multiple expensive calculations, or it is up to the process to store the result somewhere and pass it to the different parts that need it. The complexity in avoiding unnecessary work has to be put somewhere, and the class that generates the value seems like a good place to keep it.
27:45 that is something often overlooked
Nice for pros not helping beginners. Not someone like me having to decide whether to recommend learning c++ or something else.
How many semesters decent (meaning one who will finish its university studies in computer science) does Computer Science student needs to learn to program in C++? This is a simple question with one number as an answer. For those telling less then a 2 i will ask for exact literature.
I am programming in C++ since 1989 and i am telling to those making language changes and guidelines. People who are proficient in something very often forget that there was a day in their life when they knew nothing about the thing they are good at.
It is easy to read 2000 pages of text if you understand text not so easy when you are starting.
My copy of Stroustrup book was 320 pages long.
1:45:00 look, last time i tried implementing tic-tac-toe, i ended up with conway's game of life being played on a minesweeper board, don't say it is simple!
2:42 Old people ?
I actually said "that mutable thing is PRETTY PRETTY cool" right before she says it haha
Of course you should understand the language you're developing in. A more interesting discussion is whether or not the complexity of C++ serves the goal of creating software to solve problems reliably, accurately, on-time and on budget. If you're stuck developing in C++, you should understand it, and accept the years of your life that it will take to properly learn it. You should also reflect on all of the other things you could have done with your time and brainpower. Yes, computer software is complex and often requires complex solutions but it does not follow that the complexity of modern C++ is justified or reasonable.
isOdd(int a) should be abs(a%2) or (a%2)!=1, if i remember correctly (-3)%2=(-1)
-1 is still convertable to true, so it works fine
brilliant, absolutely!
01:13:16 ❤❤
01:41:13 lol =)
if the reason you want to learn is to be part of a crowd, any crowd, then maybe you should get that checked first
Yes! So much yes!
I found this video when i searched "why only C++ programmers use the term 'undefined behavior' "?
🍁🍁🍁
"That mutable thing" has another name: logical const vs. bitwise const. isocpp.org/wiki/faq/const-correctness#logical-vs-physical-state
There are some really bad points in there.
1:03:00: unnecessary cast, because somebody might not know the rules of the language? Really bad idea. There's a reason why some conversions are implicit and others aren't: the implicit ones are the ones where not much can go wrong. Derived class pointer to base class pointer? Nothing can go wrong, so it's implicit. Base class pointer to derived class pointer? That can go wrong, so it needs a cast. The problem with adding an unecessary static_cast is that you might some day change that code and make a mistake along the way that changes the type of the expression to something that cannot be implicitly converted to the target type. You really, really want the compiler to tell you about that, but it won't because of that cast. And when it comes to this particular example: why would you want a conversion in the first place? Just write what you really mean: return x % 2 == 1.
1:34:44: I can't count the number of times I've heard this nonsense: “If you're out of memory, anything you could do to handle that will require memory, so don't bother”. Yeah, except there is something you can do that doesn't require memory, and that is … *drumroll* … freeing memory. In fact, her example demonstrates how that just happens naturally without one even having to think about it. When you try to read a gazillion strings with that code, it's going to stick them into the vector until it runs out of memory. Then it'll throw std::bad_alloc and start unwinding the stack. res's destructor will be called, freeing all that memory we just allocated, and by the time we enter the hypothetical catch block, we have plenty of memory available to do whatever it is we need to do.
1:44:53: I hate it when people spread this idiotic meme of a nuclear reactor being something that will explode all the time unless you actively do something to stop it. You know what keeps reactors from exploding? Spoiler alert: it's not computer programs, it's physics. You can't even get a reactor licensed today unless it has a negative temperature coefficient of reactivity, meaning that when temperature goes up, reactivity goes down. And that's just one physics-based safety mechanism, there are many others. Just look at the passive safety designs of modern reactors like AP1000 or BWRX-300 or NuScale before engaging in anti-nuclear fearmongering. We really don't need any of that, particularly at this time when we need reliable, CO2-free energy more than ever before.
1:21:56 well, it ok, i can write... bubblesort in 5 minutes... it's fiiine
One thing I contemplate about is whether C++ is too broken to be useful. Over the past 30 yrs I've been watching C++, a lot has been learned on how we want a programming language to look like, and C++ has incorporated much of it. But the design decisions of backward compatibility and "we want absolute control" mean that it's complicated. Take a look at pointers for example. If raw pointers are bad, why is it that a program making was use of raw pointers is more concise and readable than a program that isn't? It's because of backward compatibility. And if exceptions are "mostly bad", why do I have to add "noexcept" to every function? why isn't it the default? backward compat. And when a program doesn't compile I get an obscure template error instead of "you passed the wrong parameter" - that's because we want control.
So it ends up that you *can* write a good C++ program, but it has to be riddled with "warts" such as make_unique(), noexcept, std::move(), and such. And then they come to you saying "but you can avoid the std::move using IIFE!" REally? I have to learn a new idiom just to remove another wart?
If I compare to Golang - I complete the golang tutorial in a day, then with the help of stack overflow and some blogs I immediately write idiomatic, readable, and quite efficient Go. In theory I don't have as much control, and there are some cases where C++ can produce better results, but I wonder whether the "simple and idiomatic C++" which is hard to learn as Kate confesses, yields more efficient code than Go. Problem with Go is that it dosn't integrate with legacy. What I'd like to see is a new language that uses C++ runtime (sort of like Kotlin simplifies Java)
Not any raw pointer, owning raw pointer -- a crucial detail that you missed. This applies to move as well: you cannot and you shouldn't eliminate it with something else -- these are all different instruments for different cases.
Smart looking people seriously talking about both using exceptions and not checking all corner cases app level code???????
I thought I was wasting to much time theory than on practice. I guess I'm wrong
bool IsOdd(int x) { return x%2 == 1; }
x = -1 is even?
D'oh!
Fixed it
bool IsOdd(int x) { return x%2 != 0; }
That does the job. I think there might be another way (not better, just different) based on the fact that we use digital computers with binary numbers. So an odd number should have 1 as the last bit.
I think that would be less clear, but yeah
static_cast(x % 2)? is that a joke? how about return x % 2 == 1; you're being explicit without any stupid casts, implicit or explicit
c++ 11,14,17,20 .......... aka (bjarne and his gang needed that bit of extra $$ from books and lectures)