unexpected C4244 warnings

[Michael Shutt]

I am working on an ATL project in VC++6. I nearly have it completed and am
going through memory-leak detection. I am having problems with
_CRTDBG_MAP_ALLOC not working properly and am trying to figure that out,
when all of the sudden I start getting a whole slew of C4244 warnings during
compile (I am using Level 4). For example, I will get this warning from the
following lines of code:

WORD wNumerator = 100;
WORD wDenominator = 10;
WORD wResult = wNumerator / wDenominator; // get a C4244 warning on this
line

Although I no C++ expert, I have done quite a bit of ATL development and
have not ever gotten this warning for what seems to me to be a perfectly
safe operation. So my questions is two-fold:

- Should I be geting a warning here (is this a valid Level 4 warning)?
- If not, any ideas why I am getting it?

Thanks in advance for any help.

--
Michael Shutt

Please respond to newsgroup as I will not return direct emails.

[Igor Tandetnik]

Have you read a description of this warning in MSDN?

<quote>
The conversion may have a problem due to implicit integral conversions. For
example:

short a, b, c;
a = b + c; // warning
</quote>

Operands are promoted to int, the result is also int, then it is assigned to
a short.-- With best wishes, Igor Tandetnik
"For every complex problem, there is a solution that is simple, neat, and
wrong." H.L. Mencken
"Michael Shutt" <mshutt...@mediaone.net> wrote in message
news:OAGkHEvYBHA.1456@tkmsftngp04...

[Michael Shutt]

Yes, I read the description multiple times trying to understand this before
I posted here.

This is the part I didn't understand -> "Operands are promoted to int". I
suppose is the case because I am running a 32-bit operating system? Is
including an explicit cast, i.e.,

dwResult = (WORD)(wNumerator / wDenominator);

simply telling the compiler that I know that I am converting back to a
short, so don't warn me about it? It certainly does not alleviate the
"real" problem.

As a side note, it looks after switching from Level Warning 3 to 4, you
won't start getting level 4 warnings until after you do a *complete* build,
which is why I was a little baffled when these started showing up long after
I switched to level 4 and without making any code changes.

Thanks for your help.

--
Michael Shutt

Please respond to newsgroup as I will not return direct emails.

"Igor Tandetnik" <itand...@whenu.com> wrote in message
news:#Klt35vYBHA.2080@tkmsftngp02...

[Igor Tandetnik]

It has nothing to do with the bitness of the OS. C++ standard 5/9 says:

<quote>
Many binary operators that expect operands of arithmetic or enumeration type
cause conversions and yield result types in a similar way. The purpose is to
yield a common type, which is also the type of the result.
This pattern is called the usual arithmetic conversions, which are defined
as follows:
— If either operand is of type long double, the other shall be converted to
long double.
— Otherwise, if either operand is double, the other shall be converted to
double.
— Otherwise, if either operand is float, the other shall be converted to
float.
— Otherwise, the integral promotions (4.5) shall be performed on both
operands.54)
— Then, if either operand is unsigned long the other shall be converted to
unsigned long.
— Otherwise, if one operand is a long int and the other unsigned int, then
if a long int can represent all the values of an unsigned int, the unsigned
int shall be converted to a long int;
otherwise both operands shall be converted to unsigned long int.
— Otherwise, if either operand is long, the other shall be converted to
long.
— Otherwise, if either operand is unsigned, the other shall be converted to
unsigned.
[Note: otherwise, the only remaining case is that both operands are int ]
</quote>

Integral promotions are described in 4.5 and basically mean that everything
of type char or short, signed or unsigned, gets promoted to int (if it fits)
or unsigned int (if it doesn't), and enums, wchar_t and bool are promoted to
at least int. Thus all the arithmetic operations work on types no more
narrow than int. Assigning it to a more narrow type just might lose
significant digits, which is what compiler warns you about.

Now, it is true that when you divide two unsigned shorts, the result is
guaranteed to fit into an unsigned short. But the compiler does not analyze
the semantics of an arithmetic expression on the right side of assignment
operator, and doesn't try to prove logical facts about it. It only analyses
the types, and under the rules above, you have a type mismatch.
--

With best wishes,
Igor Tandetnik

"For every complex problem, there is a solution that is simple, neat, and
wrong." H.L. Mencken

"Michael Shutt" <mshutt...@mediaone.net> wrote in message

news:ONDaLIwYBHA.1796@tkmsftngp07...

[Michael Shutt]

That's good information and makes perfect sense. Thanks.

It seems, therefore, that the bit-sizes of the operands do not affect the
speed of an operation (as far as integral math is concerned). In other
words, it takes just as long to perform multiplication on a pair of char
values as a pair of int values. I wouldn't have realized that until now.

--
Michael Shutt

Please respond to newsgroup as I will not return direct emails.

<snip>

[yugami]

how would it warn you of problems if its not compiling that code?

"Michael Shutt" <mshutt...@mediaone.net> wrote in message

news:ONDaLIwYBHA.1796@tkmsftngp07...