No operators defined on ushort

  • Thread starter Thread starter Axel Dahmen
  • Start date Start date
A

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
 
The following works for me. It would seem that the subtraction operator is
defined but returns an int. Go figure.

ushort a,b,c;


a = b = 0;
c = (ushort)(a - b);


--Ken
 
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#.



-----------------------------------
 
Axel Dahmen said:
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#.
Click to expand...

I think the arguments in this discussion would be much better placed if
they were concerned with usefulness rather than academic completeness.

Whether or not C#'s non-int data types are "crippled" doesn't seem to
have stopped people writing C# code which works, does it? The question
shouldn't be whether or not C# is "incomplete", it's whether it can be
made potentially *more* useful than it already is.

I would certainly be interested to hear from the language authors on
why these choices were made, but if there are some appropriate
practical reasons, I for one have no problem in sacrificing
"completeness" for "usefulness".
 
Axel said:
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#.
Click to expand...

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.
 
Jon,

adding the missing operators has practical impact, of course. First of all
it would make an end to the clumsy spelling. Furthermore, ask yourself: Why
are the smaller integral types implemented into a language anyway?

However, your view regarding practical issues is wrong because this
discussion is not about the semantics of .NET, the syntax of C# or Visual
Studio features but about C#'s completelyness. Just because people write
programs in C# and these programs work doesn't mean everything in the
language is correct. I might say for one, the job simply isn't done yet.
 
No, they both don't perform integer arithmetic using int (if they do, it's a
a compiler peculiarity, not a language feature). 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.

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 said:
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
Click to expand...
data.
 
Axel Dahmen said:
adding the missing operators has practical impact, of course. First of all
it would make an end to the clumsy spelling.
Click to expand...

Do you mean casting?
Furthermore, ask yourself: Why
are the smaller integral types implemented into a language anyway?
Click to expand...

I'm not trying to defend the lack of operators on those types - as I
said, I don't know the reasons myself, and would be interested to hear
them. I was suggesting that you were coming at the issue from an
unhelpful angle.
However, your view regarding practical issues is wrong because this
discussion is not about the semantics of .NET, the syntax of C# or Visual
Studio features but about C#'s completelyness. Just because people write
programs in C# and these programs work doesn't mean everything in the
language is correct. I might say for one, the job simply isn't done yet.
Click to expand...

It doesn't mean everything in the language is as good as it could be,
but that's a long way from your view that the language is "crippled"
and that it's not "valid" which makes it sound completely unusable.
 
The runtime only defines operations for number of 4 or 8 byte length. I'm
not one of the CLR architects, but my understanding is that this was done
for a couple of reasons. First, operations on 4 or 8 byte numbers are more
efficient than smaller sizes on many processors. Also, adding in additional
support for smaller types would require more work and complexity both in the
runtime and the JIT.

--
Eric Gunnerson

Visit the C# product team at http://www.csharp.net
Eric's blog is at http://blogs.gotdotnet.com/ericgu/

This posting is provided "AS IS" with no warranties, and confers no rights.
 
Axel said:
No, they both don't perform integer arithmetic using int (if they do, it's a
a compiler peculiarity, not a language feature).
Click to expand...

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.
Click to expand...

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.
 
Back
Top