CppCon 2018: Jason Turner “Applied Best Practices”
Vložit
- čas přidán 12. 11. 2018
- CppCon.org
-
Presentation Slides, PDFs, Source Code and other presenter materials are available at: github.com/CppCon/CppCon2018
-
What happens when we start a project from scratch and try to apply all of the best practices? How well do constexpr, noexcept, [[nodiscard]] and other features interact with each other? Is it possible to apply all of the best practices at once, or will they conflict with each other? We will explore current best practices and examine their impact on compile time, runtime and testing. We'll also see some of the unexpected effects that result when best practices are applied to a new project.
-
Jason Turner, Developer, Trainer, Speaker
Host of C++Weekly / jasonturner-lefticus , Co-host of CppCast cppcast.com, Co-creator and maintainer of the embedded scripting language for C++, ChaiScript chaiscript.com, and author and curator of the forkable coding standards document cppbestpractices.com.
I'm available for contracting and onsite training.
-
Videos Filmed & Edited by Bash Films: www.BashFilms.com *-----*
Register Now For CppCon 2022: cppcon.org/registration/
*-----*
Jason is really a great communicator, and C++ expert. I must catch one of these talks live soon.
"What feature to remove from C++ if you could? Implicit conversions!" Finally! Good to see I'm not alone with this observation.
I usually work down in the embedded C world, and even *_WE_* would love see languages enforce strong typing. For example, typedef enum should NEVER have been allowed to implicitly convert to a uint8_t. That's bad news all day long.
I know GCC has something like that as a compiler flag, though I'm not sure when it'll be available in most MCU libraries.
I mean there's so many good choices though?
Implicit pass by value and Implicit mutability are also bad defaults.
love how he engages with the audience!
"portability is the best practice" Amen. I just wish more developers heeded this. The best code is portable. Period.
Yes, portable Windows applications are tight, I agree with what he's saying in general, but if you're writing code for a specific platform, there is no reason to not use the tools that are provided by that specific platform... [And there is some cases where that is unavoidable]
17:00 if readability is an issue, instead of trailing return types, you can break before function name. It's a style available in clang-format also. eg
[[nodiscard]] constexpr int
myGettter() const noexcept;
But still I would put return type before the name just to stick to the legacy code and when the return type is long say like std::pair then making it trailing return type is much more readable to me
@Ziggi Mon Exactly. I truly hate splitting function declarations onto multiple lines. The biggest problem I have working in C* is figuring out where implementations live. Being able to grep for a function by name and return type is absolutely critical.
@John Smith I can see the advantage to that. Assuming the split-line is only used at the implementation, and assuming the code is sanely indented, the only place the function name will appear at the start of a line is at the implementation. I don't know why I hadn't thought of using the start-of-text regex before, but I think that will help. The only remaining issue would be if the same function name is used in different namespaces, returning different types. Not something I'd expect in a well behaved project, but something I've encountered more often than I'd like. Also, won't that fail in c++ inside namespaces where the function declarations are indented?
When you're trying to learn a new code base, being able to find a list of functions that return a particular type is handy. Searching for typename on a line not ending with ; usually gives you a pretty good shortlist. If the codebase puts the { at the end of the line instead of on its own line, you can also look for that, and get an even better shortlist.
@John Smith Wow, I dropped from 8-column tabs to 4 about 10 years ago. Lots of the time these days I'm running at 2-column tabs. If you're only using a single namespace per file, not indenting the namespace block probably doesn't make much difference. If the return type is the only thing on the line, that would probably work. Lots of the time I see the other tag-soup stuff included on the same line as the return type. I suppose you could look for return_type$ . In C, where functions are often prefixed by something to reduce the symbol collisions (projectname_function1 et cetera), I often grep for (return_type projectname_).
It's not the end of the world to put grep into multiline mode; I just never thought about the advantage to splitting the function name to its own line. I suspect I'll still default to keeping it on one line out of habit, but I'll probably be less annoyed the next time the project of the day uses that style.
As for why I run into this often enough to care, I usually have to familiarize myself with a new codebase about every other week. Being able to track return types quickly and easily makes a big difference in how long it takes to get the 1000' view of the whole project.
Let's hope the implicit constexpr proposal makes it through.
Skip to 3:00
Even to 5:00
He loves that self promotion
Very entertaining. It's really interesting/annoying, that not everything is constexpr yet. A constexpr vector would be really nice.
If my employer would use C++, I would advise to book you. Even if it's just for fun.
If you've not already seen it, take a look to the Louis Dionne talk about "Compile-time programming and reflection in C++20 and beyond"
Thanks a lot for considering the non-local audience when doing audience polls.
There's nothing more aggravating than watching a talk where the presenter skips over something because the locals grok it when it can be key to a remote person's understanding.
note 26:50: You can't actually declare a lambda to be nodiscard.
may a lamda be invoked in a way that discards the result 🤔
@@GeorgeTsiros, of course, why not. As soon as it returns something, and your invocation does not consume the returned value.
@@VioletGiraffe yes, obviously...
auto f=()[]->{return 1;}; f();
sorry if the syntax is not correct.
i do not remember what i had in mind back then.
most likely a brainfart
@@VioletGiraffe yes should have been []().
What debugger or IDE is he using? 36:12
Compiler Explorer
37:10 who thought that was a good idea
8:48 :D
czcams.com/video/DHOlsEd0eDE/video.html What? Isn't it like "The longer type names get, the more useful fully-auto comes?"
I'm not smart enough for this language. If I was writing an emulator I doubt I'd spend this much time obfuscating my code with the latest attributes and keywords just for the sake of it. I put a high value on readability and simplicity and I value my time. When it takes more than 100 columns and multiple keywords to write a correct method signature it's a sign you should take your language back to the drawing board. Nobody coming from another language is going to have a clue what is going on in c++ land and typing code should be one of the more trivial aspects of solving actual engineering problems. These cppcon talks feel short on motivating examples and tall on esoteric, introspective, snazzy new features. Which sucks because I want to be a better programmer in a pragmatic sense not just a guru.
I feel the same way. I mean Jason clearly knows the language well and I have seen some pretty cool videos that he posts (for example we ported doom to c++ ) but I think he and some of these c++ gurus have missed the forest for the trees. The language is becoming completely unreadable. I mean I cant really think of a situation where I would use [[no discard]] and I wouldn't clutter up my code with yet another keyword.
There are a TON of features in C++ that are nice for enforcing best practices, but make the code less readable. A lot of this stuff should have been default.
Attributes make your code easier to read though, that's their whole...
Should be default, but isn't. The reason for it's unfriendliness is backwards compatibility. You can't really get around that. C++ programmers recognize that it will always be a verbose and ugly language, and prioritise communicating intention with strong types and attributes.
Something that sounds easy but actually isn't. Sounds like conning yourself into something dangerously long.