(Me || Compiler) == Stupid

  • Thread starter Thread starter Steven Nagy
  • Start date Start date
S

Steven Nagy

private void Test(short i, short j)
{
short k = i + j;
}

What the hell is wrong with this code?
"Can not implicitly convert type int to short" is the compile error.
ASP.NET 1.1 C#

Thanks
 
'Short + short' can be bigger than a 'short', and you can not implicitly
convert it to a short value due to the size. You have to do it explicitly:

private void Test(short i, short j)
{
short k = (short) (i + j);
}
 
To me this is an inconsistency in the framework;

Int32 + Int32 can be longer than an Int32 (int), but it does this silently
(wrapping), returning an Int32.
Likewise with Int64 (long), returning an Int64; yet Int16 (short) returns an
Int32 on summation.

*Presumably* this was for some some meaningful reason... not quite sure what
it is though; anybody?

Marc
 
Marc said:
To me this is an inconsistency in the framework;

Int32 + Int32 can be longer than an Int32 (int), but it does this silently
(wrapping), returning an Int32.
Likewise with Int64 (long), returning an Int64; yet Int16 (short) returns an
Int32 on summation.

*Presumably* this was for some some meaningful reason... not quite sure what
it is though; anybody?
Click to expand...

Performance. Processors are generally happier doing Int32+Int32 than
Int16+Int16, so unless you specify that you want to bound it, the
language assumes it's okay to do things the fast way.

Jon
 
There we are; and yes, that does seem like a pretty good reason to me ;-p
(not that I work with Int16 very often...)

Cheers,

Marc
 
Thanks for the response guys.
If its a processor performance thing as Jon suggested, then I am
completely ok with it.
If its anything other, then fooey on C#.

Perhaps it is important for me to pose this question as well then.
The reason I went for a (short) is because I figured it is the ideal
data type because my values won't go over 20.
Basically, its a mini chess application and I have an array declared:
short[,] Board;
Given Jon's statement about CPU performance, would I be better to have
declared as an int instead?
There won't be many arithmetic operations, mostly just comparison. The
arithmetic comes in when checking if moves are valid and so on.
It all works fine currently as a short. Whats the recommondation?
Preserve current structure as short, or do a Find/Replace with int ?
(Note, if you think there is even a minor performance improvement
either way, even if its not going to be noticeable, please indicate
so!)

Thanks
 
Steven Nagy said:
Thanks for the response guys.
If its a processor performance thing as Jon suggested, then I am
completely ok with it.
If its anything other, then fooey on C#.

Perhaps it is important for me to pose this question as well then.
The reason I went for a (short) is because I figured it is the ideal
data type because my values won't go over 20.
Click to expand...

Why not use byte then, out of interest?
Basically, its a mini chess application and I have an array declared:
short[,] Board;
Given Jon's statement about CPU performance, would I be better to have
declared as an int instead?
Click to expand...

I doubt that it'll make a significant difference for you - but if you
have a *lot* of boards in memory at a time, then the memory difference
could be significant.
There won't be many arithmetic operations, mostly just comparison. The
arithmetic comes in when checking if moves are valid and so on.
It all works fine currently as a short. Whats the recommondation?
Preserve current structure as short, or do a Find/Replace with int ?
(Note, if you think there is even a minor performance improvement
either way, even if its not going to be noticeable, please indicate
so!)
Click to expand...

I'd consider going to byte, but wouldn't move to int without
benchmarking first. You *may* find a minor performance improvement, but
I doubt it personally.
 
Ok thanks Jon.
yeah I don't know why I didn't go byte, perhaps because I am mental.

Yes, there could be lots of boards in memory at once in the future,
which is what I am catering for now.

In the trade off of faster cpu vs less ram, I guess I have the dilemna
of:

If I go for CPU, the request can be completed quicker, and then garbage
collection returns my ram.
If I go for RAM, then I can handle more simultaneous requests, but they
process slower.

Given a web site context (ASP.NET) then which should I choose?
Process the requests faster, or preserve as much ram as possible?
 
Steven Nagy said:
Ok thanks Jon.
yeah I don't know why I didn't go byte, perhaps because I am mental.

Yes, there could be lots of boards in memory at once in the future,
which is what I am catering for now.

In the trade off of faster cpu vs less ram, I guess I have the dilemna
of:

If I go for CPU, the request can be completed quicker, and then garbage
collection returns my ram.
If I go for RAM, then I can handle more simultaneous requests, but they
process slower.

Given a web site context (ASP.NET) then which should I choose?
Process the requests faster, or preserve as much ram as possible?
Click to expand...

I doubt whether the difference in either will be signficant, to be
honest - but you won't know without benchmarking (as close to real
usage as possible).
 
Back
Top