Bjoern Milcke wrote:
Hi,
I am a bit late with warning-freeness, I just now resynced against a
master build that contains warnings01 and pals. Maybe this problem here
is not new, but I didn't find anything about this.
I came across the following piece of code:
String a;
xub_StrLen n = 0;
n += a.Len();
This breaks on Windows (due to -werror). Because of the warning:
warning C4244: '+=' : conversion from 'int' to 'USHORT', possible loss
of data (in the last line of the fragment)
String is a typedef to UniString. UniString::Len() returns xub_StrLen.
So, here we have a xub_StrLen::operator+( xub_StrLen ), which should
work without conversion, no matter what xub_StrLen is. Actually,
xub_StrLen is currently a typedef to USHORT which is a typedef to
sal_uInt16 which is a typedef to "unsigned short" on Windows.
The only explanation I have for this is that there is no operator+= for
xub_StrLen, therefore the expression is expanded to:
n = (unsinged short)( (int)n + (int)(a.Len()) );
But why? There should be a lossless operator+= (and also +) for unsinged
short. And a typedef should be more or less an alias? And it is a POD
type, too.
Does anybody have an idea what the problem is here?
By the holy standard, x += y where x, y are short works by promoting x,
y to int x', y', adding x' + y', converting int x' to short x'' and
assigning x'' back to x. MSC chose to warn about this (about the
potentially lossy "converting int x' to short x''" part).
Rewriting this to
n = n + a.Len();
works. But it doesn't look much different.
Yes, MSC does not warn about that one, I guess it is a bug. It does
warn about
n = n + M;
where M is larger than unsigned short.
Just checked:
unsigned short foo() { return 42; }
void bar()
{
unsigned short n = 0;
n += foo();
}
also creates the warning. So it doesn't have to do with typedefs. This
looks like a compiler bug to me.
Its not a bug, its a feature. I also wondered about it at first, but
then started to change some occurrences of x +=/-=/*= to x = x +/-/* y.
Not a nice code change, to be sure of, but at least there were not too
many occurrences. And if you use rtl::OUString instead, the problem
will go away (as its length type is sal_Int32). And, the MSC warning
C4244 is also triggered in other, useful places, so I would not want to
just disable it.
-Stephan
Confused,
Bjoern
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
