CppCon 2018: Kate Gregory “What Do We Mean When We Say Nothing At All?”
Vložit
- čas přidán 8. 06. 2024
- CppCon.org
-
Presentation Slides, PDFs, Source Code and other presenter materials are available at: github.com/CppCon/CppCon2018
-
They say silence can speak volumes. In a C++ application there are many places where not using a keyword or a piece of punctuation is a deliberate decision that carries a lot of information. Consider not marking a member function const, or virtual, or consider not indicating that a parameter is passed by reference. While in some cases this may be an oversight, a reliance on defaults that might or might not be appropriate, in others its a deliberate decision based on careful thought and design. How is a reader to know which is the case?
In this talk I will show some of the many places where nothingness carries meaning, and talk about approaches to increase the information others can get from your nothingness.
-
Kate Gregory, Gregory Consulting
Partner
Kate Gregory has been using C++ since before Microsoft had a C++ compiler. She writes, mentors, codes, and leads projects, in both C++ and .NET, especially for Windows. Kate is a Microsoft Regional Director, a Visual C++ MVP, has written over a dozen books, and speaks at conferences and user groups around the world. Kate develops courses on C++, Visual Studio, and Windows programming for Pluralsight.
-
Videos Filmed & Edited by Bash Films: www.BashFilms.com
*-----*
Register Now For CppCon 2022: cppcon.org/registration/
*-----*
I love Kate, best talks
0:08 "I came from east coast" ... lost opportunity to say, "and now I'm on the coast west." Ah, never mind. This is going to be good :)
Kate thx so much for these talks. I work a lot with c++ beginners and I send all of them your way.
For those on C++17, I think std::invoke is probably perfect for making immediately invoked lambdas more obvious. For example,
const int i = std::invoke([]() { return 42; });
Also, I believe the implementation can be used with C++14 trivalliy, and possibly C++11 with some work.
Sounds like a good advice, @Matthew Walker!
I think invoke is really nice but I personally prefer an explicit iife function instead. It's just 2 lines to write and it states your intend very clearly in such a case.
25:00 At the end of Sprial: assert(false);
For functions with unused parameters I like writing the name as a comment i.e. f(int /** state **/); That way you know the variable is unused but you are still able to give it a name in cases where that provides useful information.
Love Kate!
Wow, nodiscard is fantastic.
good talk!
Write your code as if it will be maintained by your child. 👍
or violent psychopath who knows where you live. Hopefully it's not the same...
C. J. Date used to say (and probably still does) that any place that you say something by saying nothing, you should be allowed to say that nothing explicitly, and that you usually should do so. I think the first part is almost inarguable, and the second is usually good advice. This is especially true for people who are forced to constantly hop between languages, where the default and normal so often differs between them. I am also a big fan of linters, more recently called static analyzers, and for some reason even more recently often called linters again. I applaud and appreciate all easily-accessible means to affirmatively declare "This is indeed what I intended to do" especially when it is equally plausible that it was just a mistake. Early languages and early language versions emphasized so heavily making it easy to type fewer characters, at the expense of having lots of rules and exceptions to them carried in our heads. Decades of hoping comments would catch these things have shown they don't, too many people and (almost all) linters and compilers ignore them. It is a little bit frustrating for those working in several languages that they all have different means of accomplishing this, but it is all good. Working in dynamic languages has made me appreciate what a huge percentage of actual mistakes that I can and do really make can be caught by the compiler in modern C++, and I appreciate every one of them. When I was doing C++ all the time, I remember how many time I wrote a big piece of code, had like 9 compiler errors, felt like I'd never finish, fixed them, and every test case went flying right thru correct. This is considerably less likely to happen for me in the dynamic languages. If I missed a test case, it is likely not going to pass when I add it. Cube that if someone other than me is calling my code...
Bottom line, I love the Kate talks, this included.
Great talk and I agree with almost everything, but I do disagree with two things. First, (44:16) using [ string s = ""; ] instead of [string s;] tells me a lot. When I see that its explicitly initialized to "" I can assume that the string is starting out empty but will be added to and built up to its final value [ s += "Hello"; s += " world"; ]. If its just declared [string s;] then I'll instead assume it is going to be set to something concrete later [ if (Q) s = "Yes; else s = "No"; ]. I prefer seeing [ string s = ""; for (auto x : something) s += x; ] because it mirrors the equivalent for literal types [ int s = 0; for (auto x : stuff) s += x; ] which makes everything consistent. It is also free since the [= ""] part get's optimized away.
Second, although a smaller gripe, (32:05) leaving the name completely out of the signature AND the definition is too much loss of information, imho. What is that last parameter? I know it's unused but knowing WHAT it is helps me understand WHY we aren't using it. If you're implementing a function [int taxes(int provRate, int fedRate, int munRate);], I'd prefer to leave in all the names of variables in the signature and then leave out the name of the variable in the definition where it is signaled that we don't use it. In all honesty, this is where a new attribute should be added to the standard. [int taxes(int provRate, int fedRate, [[unused]] int munRate){ }] just makes so much sense. It makes it clear to the reader that municipal rate does not affect this calculation and lets the compiler know to warn us if it starts being used when it later is decided it should be used.
Great talk none the less! :)
I also don't like un named parameters. But I think stupidly named are even worse. Not as bad as misleading names, but still.
Like const char * strstr ( const char * str1, const char * str2 ); //#1
Someone took the effort to name them but the names are useless and stupid, they don't mean anything, give zero information.
In contrast, they could have used char *strstr(const char *haystack, const char *needle) with meaningful names... #2
If there is a unused parameter I would just name them with unused_ prefix (unused_munRate)
(void)unused_munRate; always helps suppressing unused variable warnings in my experience. (the release version of assert could also do that...)
And if they are not used might as well give them default value, so the caller doesn't even have to bother with coming up with a placeholder.
#1: from www.cplusplus.com/reference/cstring/strstr/
but it's not the only site
char *strstr (const char *s1, const char *s2); // www.geeksforgeeks.org/strstr-in-ccpp/
fresh2refresh.com/c-programming/c-strings/c-strstr-function/
www.techonthenet.com/c_language/standard_library_functions/string_h/strstr.php
www.ibm.com/docs/en/i/7.4?topic=functions-strstr-locate-substring
#2: www.tutorialspoint.com/c_standard_library/c_function_strstr.htm
or
char *strstr( const char* str, const char* substr ); // en.cppreference.com/w/c/string/byte/strstr
Code is for people, not machines
Solution to implicitly explaining IIFE pattern to newbies is to name the lambda and invoke it on the very next line:
auto my_var_initializer = [&]() -> T { /*...*/ };
const T my_var = my_var_initializer();
I wish I had learned about these things before ...
In school you only learn HOW to write code, not the "philosophy" behind how/why to write it a certain way ...
Cool talk but im not going to write noexcept(false), it looks dumb
noexcept(!true) is much better.
40:15 "Scott" and "no raw loops"? Which Scott? Did she instead mean to say "Sean" as in Sean Parent?
I am guessing that Scott has been saying it even longer than Sean has, or to more people. They are two of the most famous people to have said that to many, but there are more all the time....
6:30, I rather that inc() private.