No operators defined on ushort

[Axel Dahmen]

Hi,

I want to start a technical discussion on the fact that C# doesn't define
any mathematical operators on other integral types than int.

Simple things like the following just aren't possible in C#:

ushort a,b,c;

a = b = 0;
c = a - b;

Whatever integral data type you use, you'll always get an error "can't
implicitly convert to int." What's the purpose of this?? If the language
provides types like byte or ushort I want to use them. I want to see
overflow errors whenever routines miscalculate something.

What the compiler does here is technically and mathematically incomplete.
And it should be fixed ASAP.

Anyone?

Axel Dahmen

[mikeb]

Axel Dahmen wrote:

No, they both don't perform integer arithmetic using int (if they do, it's a
a compiler peculiarity, not a language feature).
I'm not sure I call it a feature - it's simply part of the language
standard. Please excuse any errors below when I quote from the standard
- the PDF I have apparently does not permit copying to the clipboard.

In my copy of the C++ standard (ISO/IEC 14882:1998(E)), the sections for
various operators (for example 5.6 Multiplicative operators and 5.7
Additive operators) say that "the usual arithmetic conversions are
performed" on the operands.

The usual arithmetic conversions are defined at the start of section 5:

=============== =============== =============== =============== =======
- 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.
...
...
...
=============== =============== =============== =============== =======

Section 4.5 - Integral promotions - indicates that type char, signed
charm unsigned char, short int, or unsigned short int can be converted
to int if int can represent all values of the source type; otherwise,
the source rvalue can be converted to an rvalue of type unsigned int.

If you don't have a copy of the standard, the draft standard contains
the same language, and is available at:

ftp://ftp.research.att.com/dist/c++std/WP/CD2/body.pdf

The C language specification has similar language.

And you don't get a warning
either.

I guess if someone's choosing a particular data type, he's aware of its
peculiarities. In fact, he might be using it *because* of its peculiarities.
If he doesn't, he might simply use int anyway.
This is all true. However in C#, if the programmer wants to do
arithmetic on short types, then the programmer will have to use explicit
casts in many more cases than a programmer who wants to use ints. This
has nothing to do with completeness or correctness of the language;
however, it makes the language less convenient in this case.

The .NET runtime may perform its integral calculations internally by using
int on PC platforms; however, I don't mind. I want to discuss about C# as a
platform independant language and some lack therein.
--------------------------------
"mikeb" <ma************ @mailnull.com> schrieb im Newsbeitrag
news:#W******** ******@TK2MSFTN GP09.phx.gbl...

Axel Dahmen wrote:

Well, Yves, I know these documents. Though they explain the effect
itself
and how to deal with C#'s incomplete data type implementation, they
don't
discuss the fact that the missing operators render C# incomplete.

Here is my point of view: Mathematically and in Informatics science, a
native scalar data type establishes a K vector space. - In C#, only the
integer data type fulfills this requirement. All other integral C# data
types are crippled so far.

Regarding this aspect, C# is faulty. To get a truly comprehensive (a
"valid") language, C# needs to add operators to all native scalar data
types.

I might be wrong, but in case I'm not, the arguments in this discussion
should lead to implementing the missing operators into C#.

ANSI C and C++ also always perform integer arithmetic using int (or
larger) types. It's just that in these languages you do not get an
error when assigning an int into a smaller integral type (you might get
a warning, though). The C# language designers decided that silently
truncating integral values was the source of enough bugs that they do
not allow implicit conversions if the conversion can potentially lose

data.

--
mikeb