Re: [lmi] Detecting whether move semantics actually take place [Was: Install several more clang packages]

[Vadim Zeitlin]

On Mon, 18 Jul 2022 15:48:14 +0000 Greg Chicares <gchicares@sbcglobal.net> 
wrote:

GC> I was really just hoping to use 'clang-tidy'.

 FWIW I have a "in progress" .clang-tidy file where I've disabled/tweaked a
number of clang-tody warnings. Would it be useful to send it to you, even
in this far from finished version or will you want to make your own choices
anyhow?

GC> So far, I've figured out that I need '-extra-arg=-std=c++20', and I've
GC> tested one tiny file.

 For testing on a single file I run it like this:

        % clang-tidy --config-file=.clang-tidy zero_test.cpp -- clang++-14 
...all the flags taken from "make -n" output ...

 For running it on the all files I've used https://github.com/rizsotto/Bear
to create compile_commands.json file expected by clang tools and then I
could just do

        % run-clang-tidy -j16 -q

(but there will be a _lot_ of output, so you'd better redirect it
somewhere).

 Again, I hoped to package all this nicely and present it to you in an
easier to use form, but didn't have time to do this yet, sorry. If you
think this would be useful, I could resume working on this now. Should I?


GC> Let me pose a hypothetical question first: does this line
GC>      db = std::move(da);   // D& operator=(D&&)
GC> actually perform a move and not a copy, in a context where
GC> class D defaults all special member functions?

 If the defaulted move assignment operator actually exists and is not
deleted, then this will perform a move, yes.

GC> Here's what 'clang-tidy' says:
GC> 
GC> clang-tidy sandbox_test.cpp -extra-arg=-std=c++20 2>&1 |less
GC> 
GC> /opt/lmi/src/lmi/sandbox_test.cpp:276:6: note: Moved-from object 'da' is 
moved
GC>      db = std::move(da);   // D& operator=(D&&)
GC>      ^~~~~~~~~~~~~~~~~~
GC> 
GC> so it appears to detect that the intention of that line of
GC> code is actually realized.

 I think it is, but you could check it by making the class D not movable
and checking if this diagnostics is still given.

GC> On a large code base, that sort
GC> of information might be overwhelming. But for this little
GC> test, it has real value. A move assignment operator might be
GC> undeclared, or inaccessible, or deleted, and in all (AFAIK)
GC> of those cases, copy assignment would silently be substituted.
GC> There doesn't seem to be a C++ standard way to ascertain
GC> whether a move actually takes place. But the compiler surely
GC> knows what it did, and a tool built on top of the compiler
GC> can give this information.

 If you wanted to ensure that a copy doesn't happen here, you'd have to
delete the (usual) assignment operator. But if you want to allow moving
without requiring it, I indeed don't see any way to ascertain that the
value is moved.

 But I don't see any value in the warning/note above, to be honest. Letting
aside the question of dealing with hundreds if not thousands of them in the
real code base, how would you notice if it is _not_ given?

 Generally speaking, if you decide to find the subset of clang-tidy
warnings you're interested in yourself, please be prepared to disable 90%
of them because many of them are just completely inappropriate in general,
even if they might be helpful in some very specific circumstances (for
completeness, let me mention the special NOLINT comments that can be used
to disable warnings for some specific line or region of the code, but I
don't believe it's going to be generally useful to litter the code with
them neither).

 Regards,
VZ

pgpU0ejs1Oi21.pgp
Description: PGP signature