We are using Warning Level 4, and keeps getting warning C4244 (conversion
from 'int' to '<TYPE>', possible loss of data), even though the numbers
involved on both sides of the assignment ('+=', '-=') are the same type
(shorter that int, for example unsigned short). How can we make the compiler
happy without lowering the warning level, and without disabling the warning
itself by using a #pragma? I.e. what do the compiler wants us to do?
/Stefan
Could you maybe show an example of what you mean? Say in
5 or 6 lines of code?
--
Dan Evens
(Standard disclaimers etc. No spam please.)
dan....@hydro.on.ca
unsigned short ushStartX = 0;
unsigned short ushStartY = 0;
unsigned short ushEndX = 0;
unsigned short ushEndY = 0;
unsigned short ushMapStartX = m_ushMapStartX;
unsigned short ushMapStartY = m_ushMapStartY;
. . .
unsigned short ushDiff = (unsigned short) (ushEndX + ushMapStartX -
(unsigned short) m_header.m_lNumBlocksX);
if(ushMapStartX >= ushDiff)
{
ushMapStartX -= ushDiff; // Generates Warning C4244: '-=' : conversion
from 'int' to 'unsigned short', possible loss of data
}
else
{
ushEndX -= (ushDiff - ushMapStartX); // Generates Warning C4244: '-='
: conversion from 'int' to 'unsigned short', possible loss of data
ushMapStartX = 0;
}
. . .
/Stefan
Dan Evens <dont_spam@me> skrev i
diskussionsgruppsmeddelandet:01be8fe5$2fcd9ec0$a4cc0a8a@honzevensd...
As for solving the problem, remember that the true meaning of a C-style cast
is "Shutup, Dammit!":
ushEndX -= (unsigned short) (ushDiff - ushMapStartX);
This should work, but since it essentially make it the same as the first
line giving the warning, we may be stick in the same boat.
I think ultimately the problem is, if you subtract one number from
another, the result might go negative, and VC wants to warning you about
that.
--
Truth,
James [MVP]
http://www.NJTheater.Com -and-
http://www.NJTheater.Com/JamesCurran
Stefan Rådström wrote in message ...
> ushEndX -= ; // Generates Warning C4244: '-='
>Hi all,
>
>We are using Warning Level 4, and keeps getting warning C4244 (conversion
>from 'int' to '<TYPE>', possible loss of data), even though the numbers
>involved on both sides of the assignment ('+=', '-=') are the same type
>(shorter that int, for example unsigned short). How can we make the compiler
>happy without lowering the warning level, and without disabling the warning
>itself by using a #pragma? I.e. what do the compiler wants us to do?
When you say:
short int x = 0;
short int y = 1;
x += y;
It's equivalent to:
x = x+y;
which, due to the C and C++ promotion rules, means:
x = int(x)+int(y);
So, you're storing an int into a short int, hence the warning, which is
actually somewhat legitimate, because addition of two shorts can overflow
short, and assuming short is less capacious than int, which it is in VC++,
you could have done something about it, by storing the result in an int. As
for a workaround, you might want to try compiling at warning level 3 and
promoting the level 4 warnings you like to level 3. For the operator+ form,
you could say:
x = static_cast<short int>(x+y);
You could also use #pragma warning to disable the warning, but you need to
decide for yourself how important the warning is and carefully choose the
#pragma's extent. You also might consider using short only as a storage form
and perform arithmetic on ints. With some CPUs and compilers, that can be
significantly more efficient than calculating directly with shorts.
--
Doug Harrison
dHar...@worldnet.att.net
/Stefan
Dan Evens <dont_spam@me> skrev i
diskussionsgruppsmeddelandet:01be9026$7dd6f8f0$a4cc0a8a@honzevensd...
signed short sh1 = SHRT_MAX;
signed short sh2 = SHRT_MAX;
unsigned short ush1 = USHRT_MAX;
unsigned short ush2 = USHRT_MAX;
int n1 = INT_MAX;
int n2 = INT_MAX;
sh1 += sh2; // warning C4244: '+=' : conversion from 'int' to 'short',
possible loss of data
sh1 -= sh2; // warning C4244: '-=' : conversion from 'int' to 'short',
possible loss of data
ush1 += sh2; // warning C4244: '+=' : conversion from 'int' to 'unsigned
short', possible loss of data
ush1 -= sh2; // warning C4244: '-=' : conversion from 'int' to 'unsigned
short', possible loss of data
n1 += n2; // OK
n1 -= n2; // OK
If it is so that the warning is issued because the danger of losing data,
why is it not issued for the last two cases (int)? The same reasoning should
be true for them.
/Stefan
Doug Harrison <dHar...@worldnet.att.net> skrev i
diskussionsgruppsmeddelandet:OwaTVSDk#GA....@cppssbbsa02.microsoft.com...
>This example investigates the different cases:
>
> signed short sh1 = SHRT_MAX;
> signed short sh2 = SHRT_MAX;
> unsigned short ush1 = USHRT_MAX;
> unsigned short ush2 = USHRT_MAX;
> int n1 = INT_MAX;
> int n2 = INT_MAX;
>
> sh1 += sh2; // warning C4244: '+=' : conversion from 'int' to 'short',
>possible loss of data
> sh1 -= sh2; // warning C4244: '-=' : conversion from 'int' to 'short',
>possible loss of data
> ush1 += sh2; // warning C4244: '+=' : conversion from 'int' to 'unsigned
>short', possible loss of data
> ush1 -= sh2; // warning C4244: '-=' : conversion from 'int' to 'unsigned
>short', possible loss of data
> n1 += n2; // OK
> n1 -= n2; // OK
>
>If it is so that the warning is issued because the danger of losing data,
>why is it not issued for the last two cases (int)? The same reasoning should
>be true for them.
The difference is that short (and char) undergoes promotion to int in
expressions, while here, at least, int is just itself, and there's nothing
you can do to help the int case.
Hey, I did say the warning is only somewhat reasonable. :) I think you could
argue that by saying:
sh1 += sh2;
you said exactly what you wanted to say, and since there's no way inside the
language to express your intent more explicitly while still using shorts and
+=, it doesn't warrant a warning.
Note that in this case, C4244 is a level 4 warning, and this is what MS says
in the /W4 documentation:
"/W4 should be used occasionally to provide “lint” level warnings and is not
recommended as your usual warning level setting."
I agree. W3 is much more suitable for the experienced developer. W4 includes
a number of warnings that might be of interest to someone just learning the
language, but after seeing them once, they can become noise, and it's time
to pull out #pragma warning or drop down to W3. I always compile at W3, and
there are still a number of warnings I always disable.
--
Doug Harrison
dHar...@worldnet.att.net
That would be true if you were alone programming a project. Unfortunately,
it is not so. We have to use W4 since a lot of potentially hazardous
constructs is not detected at W3, for example having a function that takes a
reference to an object, and then create a temporary object (using
type-casting) when calling that function (CClass& foo(CClass& rObj) called
as CClass& rObj = foo(CClass(junk));). And there are a lot of more examples.
/Stefan
>That would be true if you were alone programming a project. Unfortunately,
>it is not so. We have to use W4 since a lot of potentially hazardous
>constructs is not detected at W3, for example having a function that takes a
>reference to an object, and then create a temporary object (using
>type-casting) when calling that function (CClass& foo(CClass& rObj) called
>as CClass& rObj = foo(CClass(junk));). And there are a lot of more examples.
Yep, that's a problem. Binding a temporary to a non-const reference has
actually been illegal for a long time now.
I'll agree there are a handful of level 4 warnings I wouldn't mind having at
a lower level, which is why I suggested in an earlier message compiling at
level 3 and moving selected level 4 warnings to that level. My opinion is no
doubt influenced by the practical inability to compile with VC's (draft)
standard (Dinkumware) C++ library at level 4. That library actually moves
some lower-level warnings to level 4; <yvals.h> alone moves 8 warnings to
level 4, some of them important, which, of course, implies you should
compile at W4, but if you do, you get a torrent of warnings. It also
disables some warnings, and then you have a bunch of Windows and MFC headers
that do the same thing. Hopefully, this will get better, because right now,
it's hard to know what compiling at a given warning level really means.
--
Doug Harrison
dHar...@worldnet.att.net