ReSharper reports "Assigned value is never used" when "operator=" was used in reality

I have a class that accumulates values like this:

 

class AccumulateValues : public MyValue
{
public:
using MyValue::MyValue;

AccumulateValues() = default;
AccumulateValues(const MyValue& myValue) : MyValue(myValue) { }

AccumulateValues& operator=(INT32 myValue) { SSet(myValue); return *this; }
AccumulateValues& operator=(const MyValue& myValue) { SSet(myValue.Get()); return *this; }
AccumulateValues& operator=(const AccumulateValues& myValue) { SSet(myValue.Get()); return *this; }

protected:
void SSet(INT32 myValue)
{
if (MyOK == Get())
MyValue::Set(myValue);
}
};

And a code that is using it like this:

AccumulateValues values;

values = MyFunction1();
values = MyFunction2();
values = MyFunction3();


I am getting the following warning from C++ ReSharper at lines with the functions 1 and 2: "Assigned value is never used".

If I change them to:

values.operator=(MyFunction1());
values.operator=(MyFunction2());
values.operator=(MyFunction3());


Then the warning goes away. Is this a known issue?

 

Thanks,

Kamil

9 comments

Hello,

R++ assumes that operator= has the usual assignment semantics, and that means that consecutive assignments are redundant. I believe in general it is true - would you prefer this analysis to be disabled when there's a user-provided operator=?

Thanks,

Igor

0

Generally I find the warning to be valuable so wouldn't want to disable it globally and rather just live with it if nothing can be done.

 

I like the proposal of automatic detection of a user provided operator=. I think this would solve it.

 

I just started evaluating R++ and this is the last warning I have in a file I am currently working on...

 

Thanks!

Kamil

0

But why are assignments in your example not redundant? Does operator= in AccumulateValues have some side effects?

0

There is a logic in the SSet function that takes different branch based on the value. The value provided in the argument is stored based on what it represents.

In other words, yes the operator= has side effects.

 

A more complex solution would be ability to mark within R++ which "operator=" members have side effects. But I would be satisfied with just detection of user provided opearator=.

0

If we looked at user-provided operator=, it would mean that the analysis would be disabled for all non-POD types. This is probably an exaggeration, since most assignment operators don't have side-effects - e.g. we want the analysis to run for std::vector. We'll see if we can come up with a way to silence it.

Please note that you can also disable a specific analysis either project-wide or locally if you find it too noisy. Thanks for your feedback!

0

Any chance of turning this into "RSCPP-X" in the issue tracker? - This is the last thing that prevents many files that I work on to go from "yellow" into "green".

[As I mentioned earlier I prefer not to just turn-off the warning]

 

BTW: I have completed evaluation of R++ - I am very satisfied in general - and just got a license.

 

Thanks,

Kamil

0

Kamil,

Thanks a lot for your support!

We still believe suppressing this analysis for types with user-defined assignment operators would generally make it of little use (because it effectively would be disabled for most user-defined types). You can always file an issue in the tracker and we can see if it gets any votes, but I'd again suggest disabling this analysis if it doesn't work too well for your code.

If you have any other problems, do not hesitate to file a request though. Thanks again!

0

Before I put the request in the tracker (and as I have noticed it would land in the sea of ~1600 other requests :) please tell me do you already have an infrastructure to "blacklist" just specific type/class from code inspection?

I actually don't need a fully automated way of detecting user provided "=" operators. I think a sufficient solution would be to manually exclude "AccumulateValues" from "Assigned value is never used" inspection. Is there any kind of existing mechanism that could be relatively easily extended for this request?

 

Thanks,

Kamil

0

Unfortunately we don't have a mechanism like that, but we need one - another related request is about the ability to mark functions which accept printf-style format strings for the corresponding analysis to work on them (https://youtrack.jetbrains.com/issue/RSCPP-15890).

I filed https://youtrack.jetbrains.com/issue/RSCPP-18615 for a way to mark operator= as having side-effects.

Thanks!

0

Please sign in to leave a comment.