12:49 I would use "simplfy" for an in-place operation and "simplified" for one that returns a simplified copy. Consistent naming like that helps make APIs easier to figure out how to use IMO.
I really appreciate the insights for these moving from one standard to the next videos. There needs to be some kind of change to the way the sped up code changes are presented, though. If watching at 1x speed, you get the commentary and then risk blowing past a whole heap of changes before you can switch back to 0.25x speed so that you can actually see the code changes being done. It is terribly jarring.
If 'const' doesn't occur at least 5 times in a function signature, is it even C++? Jokes aside, some of these aren't keywords, they're attributes (which are subtly different) and the benefit of having lots of keywords everywhere is that - while yes, it's extremely verbose - it allows us to be extremely specific in our intentions, both to other developers (and our future selves) and the compiler(s) we use. I often think about Python and JavaScript libraries which feature functions that have intentions which are completely impossible to determine. Sure, "foo" is a method of the object, but all it takes is one dictionary (aka associative container) and I need the documentation (which might be out of date or just incorrect) to tell me what I can provide, what the side effects are (if any), if the inputs are modified by reference, what the output is supposed to contain, etc. meanwhile, all of that is completely discernable from just the function signature in C++ both as a programmer *and* as the compiler, meaning the compiler can point out bugs supplemental documentation never could. It also means that a lot of the time C++ can subsist without comments or documentation* since the code is verbose enough as to be self-documenting. *That being said, documentation is still warranted for system-level understanding and intention; something the compiler can't really be aware of.
I will wear the "C++ Weekly" hoodie at the ACCU 2024 conference in Bristol at the Marriott Hotel on 17th - 20th April I also have a C++ weekly t-shirt. I will wear that as well.
I'm still a c++98 guy who would like to improve, but I'm afraid that the comments and fast-forward edits are just too hard to follow. Is there a git repository showing before and after commits with a summary of the reasons for the changes made?
@@DominicDW8The "episode details" link just seems to go to an episode planning issue, and the cpp-best-practices/infiz repo doesn't show any commits relating to this video. Maybe I'm just looking in the wrong place, or changes haven't been pushed yet.
Not just a backwards compatibility thing but also just a general language default. For most languages ignoring returns isn't by default an error and you often can't even tag it to be an error. While yes nodiscard would probably be a better default, it does make sense why it isn't just looking at the general language landscape
@@FedericoPekinproper language versioning with feature deprecation. Say, C++ 20 may not be backwards compatible with C++ 17, 14, 11, 2003, etc. Or at very least, let’s stop pretending ABI compatibility is a thing. Everyone who wrote sufficiently complex systems know that either you go down to C or you go up to source level compatibility. As for good (rather better defaults), just take a look at Rust and Swift. It’s a shame how C++ is getting worse over time. 😢
@@FedericoPekin maybe I am or maybe not. In my domain we stopped using C++ for several years already because of all the problems it has. I just feel for it since that’s the language I was in love with for 15 years. But one thing is to love the language and another thing is being pragmatic and honest
![ลองสุ่มไอโฟน 990 โกงมั้ย? [ โกงมั้ยครับ ep.101 ] | DOM](http://i.ytimg.com/vi/bfsWe0j492k/mqdefault.jpg)
12:49 I would use "simplfy" for an in-place operation and "simplified" for one that returns a simplified copy. Consistent naming like that helps make APIs easier to figure out how to use IMO.
Thanks for the fuzzing example. Now I roughly know how to set it up and use it.
For more on fuzz testing, check out episode 352 - th-cam.com/video/Is1MurHeZvg/w-d-xo.html
Any reason you don't use std::ignore = evaluate(...) at around 16:30?
I really appreciate the insights for these moving from one standard to the next videos. There needs to be some kind of change to the way the sped up code changes are presented, though. If watching at 1x speed, you get the commentary and then risk blowing past a whole heap of changes before you can switch back to 0.25x speed so that you can actually see the code changes being done. It is terribly jarring.
Agreed. Those speed ups are actually too fast
Uhh, just pause the video before adjusting the playback speed?
@@sqw33k Sure. It'd be nicer if you didn't have to though
Thanks for sharing! Excellent video!
There's like 5+ keywords in every method signature 💀 cpp moment
If 'const' doesn't occur at least 5 times in a function signature, is it even C++?
Jokes aside, some of these aren't keywords, they're attributes (which are subtly different) and the benefit of having lots of keywords everywhere is that - while yes, it's extremely verbose - it allows us to be extremely specific in our intentions, both to other developers (and our future selves) and the compiler(s) we use. I often think about Python and JavaScript libraries which feature functions that have intentions which are completely impossible to determine. Sure, "foo" is a method of the object, but all it takes is one dictionary (aka associative container) and I need the documentation (which might be out of date or just incorrect) to tell me what I can provide, what the side effects are (if any), if the inputs are modified by reference, what the output is supposed to contain, etc. meanwhile, all of that is completely discernable from just the function signature in C++ both as a programmer *and* as the compiler, meaning the compiler can point out bugs supplemental documentation never could. It also means that a lot of the time C++ can subsist without comments or documentation* since the code is verbose enough as to be self-documenting.
*That being said, documentation is still warranted for system-level understanding and intention; something the compiler can't really be aware of.
Yes, the defaults are backward. Sorry, I didn't do it!
16:32 I would instead do an explicit cast to void for this.
I'm not a fan of that, personally
Hi. Has the C++ Weekly hoodies gone?
Never had hoodies, I don't think...?
@@cppweekly: You have. I know as I am wearing a "C++ Weekly" hoodie. But it is old , at least 3-5 years old and wearing out. It is all black.
I will wear the "C++ Weekly" hoodie at the ACCU 2024 conference in Bristol at the Marriott Hotel on 17th - 20th April
I also have a C++ weekly t-shirt. I will wear that as well.
I'm still a c++98 guy who would like to improve, but I'm afraid that the comments and fast-forward edits are just too hard to follow. Is there a git repository showing before and after commits with a summary of the reasons for the changes made?
There's a link to the discussion in the repo in the videos description 👍
@@DominicDW8The "episode details" link just seems to go to an episode planning issue, and the cpp-best-practices/infiz repo doesn't show any commits relating to this video. Maybe I'm just looking in the wrong place, or changes haven't been pushed yet.
@@duncangibson6277 you're right, sorry.
"If we ignore is that a bug?.." Hundred times in a row. What else do we need to prove that C++ has got all the defaults wrong? 😆
thanks for telling the obvious. If you want backward compatibility, what choice do you have?
Not just a backwards compatibility thing but also just a general language default. For most languages ignoring returns isn't by default an error and you often can't even tag it to be an error.
While yes nodiscard would probably be a better default, it does make sense why it isn't just looking at the general language landscape
@@FedericoPekinproper language versioning with feature deprecation. Say, C++ 20 may not be backwards compatible with C++ 17, 14, 11, 2003, etc. Or at very least, let’s stop pretending ABI compatibility is a thing. Everyone who wrote sufficiently complex systems know that either you go down to C or you go up to source level compatibility. As for good (rather better defaults), just take a look at Rust and Swift. It’s a shame how C++ is getting worse over time. 😢
@@alskidan I am pretty sure you are delusional
@@FedericoPekin maybe I am or maybe not. In my domain we stopped using C++ for several years already because of all the problems it has. I just feel for it since that’s the language I was in love with for 15 years. But one thing is to love the language and another thing is being pragmatic and honest