Hello, and welcome to C++ Weekly. I'm your host,
Jason Turner, available for code reviews and on-site training. In this episode I
am going to talk to you about the one C++ feature that I really think needs to go.
It's taken me several years of teaching, training, speaking, code reviews, (and) programming
to really realize how important it is that I think this particular feature really go.
[Music]
Now
of course,
be sure as always, to check out the description of this video for links to my projects, books, swag
store, Patreon, ways that you can support this channel if you find this information interesting
to you and valuable, and ways that you can, of course, bring me in for training at your company.
I will say honestly I have been going out on a bit of a limb the last several episodes talking more
about the specific kinds of things that I would generally reserve for my training classes, but
I think that it is very important for us to start really focusing on how to write safer C++. I think
that is becoming critical - more so than it ever was before. So for this particular episode I'm
going to just type out some examples and let you start to guess what issue it is I think should go.
You do get a bit of a hint on the first example
because of the warnings we are getting from the compiler here.
Now the second one is a bit more insidious and definitely more dangerous,
and we'll get to what exactly that's doing in a moment. You can see a few
squiggles that hopefully are giving you some clues.
Now this third example is definitely directly related to the example that
we saw a few weeks ago for that PlayStation jailbreak.
This fourth example that I'm getting ready to type
in has a very specific name, and perhaps you are familiar with it,
and again, perhaps you're seeing some of the squiggles which clue you in. Now for the fifth
and final example, this is one of those things that I just like to bring up when I am doing
training and I've probably mentioned it in a few conference talks as well at this point.
Now on the chance you have not caught on yet, we're going to go ahead and walk through these
blue squiggles. Now I will say I was inspired enough during the planning of this episode that
I actually went and created my own clang-tidy checker that is not available publicly yet.
You can find it on my fork of LLVM. It definitely needs some work - I don't know, really, how much
more work it needs, I've been testing it against my own projects. So if you look here on the colon
(and I definitely need to work on where exactly this is placed), you see this message that says,
"Warning: implicit conversion from a pair of const, basic_string, basic_string to a pair of
string, string." So there are specific tests in our analyzers today to look for this exact bug,
but the error, it probably isn't clear here that there is a conversion happening from the map type,
which is a const string, string to a non-const string, string and it binds to this temporary
const reference here. So if I were to take off this ampersand then we can see that only my
error remains. Previous to this we were getting analyses from clang-tidy with existing checks
and GCC's built-in checks because of this bind to temporary thing, but my warning here tells
us that we are making a copy of data when we didn't necessarily plan to be making a copy,
and if we come down here and look at this... So what we want to focus on here are the conversion
warnings again; so I'm calling do_work and I'm passing it a string. Now do_work
expects a string_view, and most of you are going to say, "This is perfectly legitimate.
Why should I care?" but I have this "implicit conversion from string to string_view" warning,
and note that I say here "Potential for dangling reference detected." Um, this is very much not a
perfect description of the error here, but we're focusing on the fact that implicit conversion
happened. Then inside the do_work I have the string_view and I'm passing this to load_file
which expects a file system path, and I have this warning - "implicit conversion from string_view
to filesystem::path creates a new non-trivial object," and then I have a warning here that says,
"implicit conversion from string to string_view, potential for dangling reference" again. So I am
warning on all of these implicit conversions and if we look here at get_data_size, then I have a
warning, "implicit conversion from size_t (aka unsigned long) to int effects readability," so
this is again my implicit conversion warning. Then I have a warning here of "int to size_t," and I'm
the only one warning on that. This is being passed to malloc. I do not have -Wconversion enabled with
GCC, but it would warn on that if I had it enabled as well. This implicit conversion warning along
with the other warnings from our compiler and clang-tidy would have caught that PlayStation
error in several different ways. Let's focus on this right here where I'm the only one who can
warn on this. I say, "implicit conversion from derived to base causes slicing and creates a new
object." You might not have been expecting that if you had written this code, and then finally,
again, a situation that only I warn on is the case where I have this vector of shared pointers,
and I am passing each element to a function expecting a shared_ptr of const int versus a
shared_ptr of int, so I get a warning here. Again, for my tool, "implicit conversion from shared_ptr
of int to shared_prt of const int creates a new non-trivial object." So just in case
you missed the point, the point is - I think implicit conversions need to go from the language.
They offer far too many situations for real memory bugs,
accidental copies, accidental slicing, overhead, memory leaks, dangling references...
Uh, I think there are just far too many sharp edges on implicit conversions. Obviously there's
some that we do want to keep, and if you dig into this you'll see that there are a lot of implicit
conversions that just simply make the language happen. I'm going to try to get rid of as many
as I can, and I am working on a tool to that end, putting my time where my mouth is at the moment.
So I don't know. Did I go too far? Maybe not - we'll see what happens next. I'm going to keep
working on this, but be sure to leave a comment. As always, be sure to check out the links in
the video description, subscribe, and thank you for watching this episode of C++ Weekly.
[Music]