Warnings for implicit constructors and wrong usage of auto

Dear all,

Recently, my team suffered from a bug due to a double bad usage of C++.

We have a function returning a reference to an object:

Object& GetObject();

Sometimes we use this function like this:

auto obj = GetObject();

This triggers a copy of the object, which we really don’t mean. The two problems are:

  1. Object does not delete the copy constructor, nor does it declare one. We have a policy of never using implicitly-declared constructors, we either use =delete or =default. Nevertheless we missed this class.

  2. A reference is demoted to a rvalue due to the usage of auto instead of auto&.

We would like clang to issue warnings in these two cases. The latter case does not really seem easy to warn about, but the former looks straightforward.

Does clang offer such warnings?

Thanks

Andrea Arteaga

+cfe-dev

Hi Andrea,

I think you might get more luck asking on the cfe-dev mailing list.

George

+cfe-dev

Hi Andrea,

I think you might get more luck asking on the cfe-dev mailing list.

George

Dear all,

Recently, my team suffered from a bug due to a double bad usage of C++.

We have a function returning a reference to an object:

Object& GetObject();

Sometimes we use this function like this:

auto obj = GetObject();

This triggers a copy of the object, which we really don’t mean. The two problems are:

  1. Object does not delete the copy constructor, nor does it declare one. We have a policy of never using implicitly-declared constructors, we either use =delete or =default. Nevertheless we missed this class.

Implicitly-defined copy constructors are ubiquitous in idiomatic C++. Maybe that’s not true in your project, but still, this seems too special-case for the compiler. Maybe a linter that has a more sophisticated model of what code is yours vs. the standard library.

  1. A reference is demoted to a rvalue due to the usage of auto instead of auto&.

This is a more reasonable thing to try to warn about. I have two concerns:- I don’t know a reasonable way to suppress the warning if you really do want to load from the l-value.

  • I have a non-specific worry that it’ll disrupt some important idiom that I’m just not thinking of.

But those are concerns that we could explore during iterative design and implementation.

John.

+cfe-dev

Hi Andrea,

I think you might get more luck asking on the cfe-dev mailing list.

George

Dear all,
Recently, my team suffered from a bug due to a double bad usage of C++.

We have a function returning a reference to an object:

    Object& GetObject();

Sometimes we use this function like this:

    auto obj = GetObject();

This triggers a copy of the object, which we really don't mean. The two
problems are:
1. Object does not delete the copy constructor, nor does it declare one.
We have a policy of never using implicitly-declared constructors, we either
use `=delete` or `=default`. Nevertheless we missed this class.

Implicitly-defined copy constructors are ubiquitous in idiomatic C++.
Maybe that's not true in your project, but still, this seems too
special-case for the compiler. Maybe a linter that has a more
sophisticated model of what code is yours vs. the standard library.

2. A reference is demoted to a rvalue due to the usage of `auto` instead
of `auto&`.

This is a more reasonable thing to try to warn about. I have two concerns:
  - I don't know a reasonable way to suppress the warning if you really do
want to load from the l-value.
  - I have a non-specific worry that it'll disrupt some important idiom
that I'm just not thinking of.

How about:

  vector<some_complex_type> v = get_vector();
  auto x = v.front();

or, worse:

  auto y = get_vector().front();

But those are concerns that we could explore during iterative design and

Yep, good example.

John.

Thanks for your reply, John.

I fully understand your points, I actually had the same concern that a reference-to-rvalue warning would be issued for perfectly reasonable and intended code. It’s still one of those warnings I would like to see when writing code in an IDE, not when compiling the full project (we would setup builds with different warning options for these two cases).

For the default constructor warning, I did not mean to be warned when a default copy constructor exists, just when one is used.

In any case, it does not seem like clang currently implements warnings like those, right?

Thank you.

Andrea

For example,

vector<int> ints{1,2,3,4,5};
auto i = ints.front();

Also, one may want to take a copy, e.g. for modifying it:

vector<string> strings{"foo", "bar"};
auto foo = strings.front();
foo.append{"tball"};

Csaba