[PATCH] D141569: [clang-tidy] Implement CppCoreGuideline F.18

Piotr Zegar via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Mon Mar 6 14:51:52 PST 2023


PiotrZSL added a comment.

In D141569#4163607 <https://reviews.llvm.org/D141569#4163607>, @ccotter wrote:

> bump. I never heard back on the case where using an rvalue reference for a big pod type as opposed to const ref.

I have such use cases in project, they not necessary POD, but more like a way to wrap many arguments into single class.
Something like this:

  struct A
  {
      void call();  
  };
  
  struct Parameters
  {
      A subclass;
      // here bunch of other members
  };
  
  void function(Parameters&& p)
  {
      p.subclass.call();
  }
  
  void test()
  {
      A a;
      function({a});
  }

When you change this into normal lvalue reference, then it wont compile, when you add const then it also wont compile.
In this cases I would probably used //NOLINT, so don't consider this case for this check as blocker.

For POD this issue also may happen but it's related more to the scenario when function modify input data by exploiting fact that input is not const.
In such case you may for example prepare message that would be created by using {}, then call function that would take it as rvalue, function could fill up some additional data like translation id, and send it.
By using rvalue you telling that function that it is an owner of this object now and can do anything with it, including changing it, but not necessarily need to move it.
But still this is also probably use case for NOLINT.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D141569/new/

https://reviews.llvm.org/D141569



More information about the cfe-commits mailing list