Fixing '*': operator has no effect ?

Started by
6 comments, last by gdunbar 7 years, 6 months ago

Small question:

I am getting the following warnings in my c++ code:

warning C4552: '*': operator has no effect; expected operator with side-effect

This nails to down to lines such as this:


// NOTE(final): Plane has just one face - therefore only one feature
U32 feature = 1 * CONTACT_FEATURE_FACEA_PRIME + (faceB.index + 1) * CONTACT_FEATURE_FACEB_PRIME + clipTypeOnB[pointIndex] * CONTACT_FEATURE_CLIP_PRIME;

Is there a way to disable this warning in visual studio 2015 - or change the code that the 1 is still present - without of course removing the "1" ?

Advertisement

If your compiler is giving you a warning, you ideally want to fix it if it's in your code.

But if you want to change your compiler warning settings in visual studio. Right-click on your project in the Solution Explorer -> Properties-> C/C++ tab -> Warning Level drop down and select 'Turn Off All Warnings (/W0)'. This will disable all warnings.

If you want to disable just one warning (i.e. C4552 warning) take a look at this: http://stackoverflow.com/questions/7159348/disable-single-warning-error

A better idea is to work out why it is giving you this warning, it is very likely you have done something by mistake so this is a good opportunity to check the line and make sure it is correct.


U32 feature = 1 * CONTACT_FEATURE_FACEA_PRIME

Multiplying by 1 does nothing and the compiler is pointing that out to you because there's no reason to do it, it thinks maybe you meant to do something else instead.

To remove the warning (solve) just remove the 1* bit at the start but do check that the line is correct and that you didn't intend to do something else.

I should point out that this may not be what the compiler is warning you about but at a quick glance it is the most likely cause.

Interested in Fractals? Check out my App, Fractal Scout, free on the Google Play store.

I see a few potential causes in there.

What are "CONTACT_FEATURE_FACEA_PRIME" and the other all uppercase values? Are they macros (#define values) because frequently those are all uppercase. If so, consider what they truly are after expansion, and ensure they are correct including having parenthesis wrapped around them.

Assuming they boil down to an integer, the 1* is also my next suspect.

If that still doesn't remove it, look at the disassembled version to make absolutely sure it is doing what you think it is doing.

Once you are absolutely sure that the compiler is generating the expected results, you can wrap the whole thing in paranthesis to make the warning go away, but that is a very high risk action because the compiler is telling you something is probably wrong. You need to be absolutely certain the compiler is wrong before trying to squelch the warning.

Is there a way to disable this warning in visual studio 2015 - or change the code that the 1 is still present - without of course removing the "1" ?

cl.exe (the Visual Studio compiler) does not generate warning C4552 for multiplication with 1. It generates it for an expression whose result is not captured and which has no side-effects. The following sample program demonstrates:


int main()
{
  int a = 10;
  int b = 1 * a; // you're assuming your warning is here; is isn't, this line will compile cleanly
  a * 15;        // this line, however, will generate C4552.
}

This strongly suggests that either you're looking at the wrong line of code entirely (verify the line number in the warning message) or that the macros expand in such a way that make that line do something else entirely different than what it looks like you are trying to do.

Multiplication by one in C++ isn't generally something the compiler will warn you about because it can have behavioral changes even if mathematically it is a no-op (for example it can result in type conversions).

Multiplication by one in C++ isn't generally something the compiler will warn you about because it can have behavioral changes even if mathematically it is a no-op (for example it can result in type conversions).


It's also common to have templates that for some instances produce code with this kind of no-op.

There are just some defines, no real macros at all - so the compiler should just include that expanded in the translation unit, isn´t it?.

#define CONTACT_FEATURE_FACEA_PRIME 3;
#define CONTACT_FEATURE_FACEB_PRIME 5;
#define CONTACT_FEATURE_CLIP_PRIME 11;
#define CONTACT_FEATURE_SWAP_PRIME 17;
*damn: There was semicolons at the end... problem solved.

A good example of why keeping your code clean of compiler warnings is a good idea. In this case, it was pointing out a completely legitimate issue.

Also, consider using "static const int ..." instead of #define when possible. It would have probably prevented this issue in the first place.

Good luck!

Geoff

This topic is closed to new replies.

Advertisement