CppCon 2018: Kate Gregory “What Do We Mean When We Say Nothing At All?”

—
—
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.
—

*-----*
*-----*

[MatthewWalker]

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.

[MatthewChaplain]

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

[amaarquadri]

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.

[dennisrkb]

Kate thx so much for these talks. I work a lot with c++ beginners and I send all of them your way.

[-taz-]

25:00 At the end of Sprial: assert(false);

[bdafeesh]

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! :)

[jvsnyc]

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.

[ManuelBTC]

Write your code as if it will be maintained by your child. 👍

[chrisparker]

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();

[themeeman]

Cool talk but im not going to write noexcept(false), it looks dumb

[youdonotknowmyname]

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

[nbulous]

40:15 "Scott" and "no raw loops"? Which Scott? Did she instead mean to say "Sean" as in Sean Parent?