Extending operator + (plus) for byte/short type

[K Viltersten]

While i know that the bytes are cheap today,
i still prefer to use a byte (or short) when
i know that the entity counted isn't larger
than 255 (or 65k). However, it's a real pain
to cast every time i perform an operation.

Example:
private byte a, b;
public byte MyProperty
{ get { return (byte)(a + b); } }

How can i avoid doing that? I'd like to
redeclare/overload the arithmetical
operators so they return a byte (or short)
when computing two bytes (or shorts).

Is it easily doable? Is it doable?

--
Regards
Konrad Viltersten
--------------------------------
sleep - a substitute for coffee for the poor
ambition - lack of sense to be lazy

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

Re: Extending operator + (plus) for byte/short type

K Viltersten wrote:

While i know that the bytes are cheap today,
i still prefer to use a byte (or short) when i know that the entity
counted isn't larger
than 255 (or 65k). However, it's a real pain
to cast every time i perform an operation.
>
Example:
private byte a, b;
public byte MyProperty
{ get { return (byte)(a + b); } }
>
How can i avoid doing that? I'd like to redeclare/overload the
arithmetical operators so they return a byte (or short)
when computing two bytes (or shorts).
>
Is it easily doable? Is it doable?

I don't think it is doable.

You should change your coding style and use int. Not only is the space
saving insignificant, but you potentially could end up spending more
CPU cycles and memory for code.

Arne

[Jeroen Mostert]

Re: Extending operator + (plus) for byte/short type

K Viltersten wrote:

While i know that the bytes are cheap today,
i still prefer to use a byte (or short) when i know that the entity
counted isn't larger
than 255 (or 65k). However, it's a real pain
to cast every time i perform an operation.
>
Example:
private byte a, b;
public byte MyProperty
{ get { return (byte)(a + b); } }
>

It *should* be a pain. You get a good indication of the work the CPU has to do.

Operating on 32-bit integers is vastly more efficient for a 32-bit CPU than
operating on bytes. The only reason you could have to use bytes is to save
memory, but you have to be pretty tight on that before you can justify the
slowdown in processing. And you have to show that you're actually *saving*
memory: more instructions are needed to manipulate bytes, and those take up
memory too.

About the only time you encounter bytes is in byte arrays. Individual bytes
are converted to ints for any nontrivial operation, and they should stay
that way until you store them back.

Public properties should basically never be smaller than an int, it doesn't
pay (unless, again, you can show that you really need the memory) or when
they're part of a predefined interop structure.

Using "short" or "byte" to enforce ranges is a bad idea: it's easy to throw
in a cast to force the value to be in range, but does this actually produce
the correct result? Checking the range explicitly in the setter is a better
idea.

How can i avoid doing that? I'd like to redeclare/overload the
arithmetical operators so they return a byte (or short)
when computing two bytes (or shorts).
>

Can't be done in C#. In fact, it can't be done in any .NET language I'm
aware of. Those operations map to CLR primitives and overloading them from a
language would be decidedly strange -- not to mention inefficient.

--
J.

[Mike Schilling]

Re: Extending operator + (plus) for byte/short type

Arne Vajhøj wrote:

K Viltersten wrote:

>While i know that the bytes are cheap today,
>i still prefer to use a byte (or short) when i know that the entity
>counted isn't larger
>than 255 (or 65k).

That is, 127 or 32767. Both types are signed.

>However, it's a real pain
>to cast every time i perform an operation.
>>
>Example:
>private byte a, b;
>public byte MyProperty
>{ get { return (byte)(a + b); } }
>>
>How can i avoid doing that? I'd like to redeclare/overload the
>arithmetical operators so they return a byte (or short)
>when computing two bytes (or shorts).
>>
>Is it easily doable? Is it doable?

>
I don't think it is doable.
>
You should change your coding style and use int. Not only is the
space
saving insignificant, but you potentially could end up spending more
CPU cycles and memory for code.

Unless you've got arrays of them, I suspect that there's no space
saved by using "byte" or "short" insead of "int". They're probably
allocated on 32-bit boundaries, just like the larger types, with the
unused 24 or 16 bits simply wasted.

[Mike Schilling]

Re: Extending operator + (plus) for byte/short type

Mike Schilling wrote:

Arne Vajhøj wrote:

>K Viltersten wrote:

>>While i know that the bytes are cheap today,
>>i still prefer to use a byte (or short) when i know that the
>>entity
>>counted isn't larger
>>than 255 (or 65k).

>
That is, 127 or 32767. Both types are signed.
>

>>However, it's a real pain
>>to cast every time i perform an operation.
>>>
>>Example:
>>private byte a, b;
>>public byte MyProperty
>>{ get { return (byte)(a + b); } }
>>>
>>How can i avoid doing that? I'd like to redeclare/overload the
>>arithmetica l operators so they return a byte (or short)
>>when computing two bytes (or shorts).
>>>
>>Is it easily doable? Is it doable?

>>
>I don't think it is doable.
>>
>You should change your coding style and use int. Not only is the
>space
>saving insignificant, but you potentially could end up spending
>more
>CPU cycles and memory for code.

>
Unless you've got arrays of them, I suspect that there's no space
saved by using "byte" or "short" insead of "int". They're probably
allocated on 32-bit boundaries, just like the larger types, with the
unused 24 or 16 bits simply wasted.

Please ignore the foregoing; I hadn't realized I was in a C# group
rather than a Java group.

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

Re: Extending operator + (plus) for byte/short type

Mike Schilling wrote:

Arne Vajhøj wrote:

>K Viltersten wrote:

>>While i know that the bytes are cheap today,
>>i still prefer to use a byte (or short) when i know that the entity
>>counted isn't larger
>>than 255 (or 65k).

>
That is, 127 or 32767. Both types are signed.

Byte is 0..255 because it is unsigned in C# - they got it right.

Short is -32768..32767, but I don't think it is important.

>>However, it's a real pain
>>to cast every time i perform an operation.
>>>
>>Example:
>>private byte a, b;
>>public byte MyProperty
>>{ get { return (byte)(a + b); } }
>>>
>>How can i avoid doing that? I'd like to redeclare/overload the
>>arithmetica l operators so they return a byte (or short)
>>when computing two bytes (or shorts).
>>>
>>Is it easily doable? Is it doable?

>I don't think it is doable.
>>
>You should change your coding style and use int. Not only is the
>space
>saving insignificant, but you potentially could end up spending more
>CPU cycles and memory for code.

>
Unless you've got arrays of them, I suspect that there's no space
saved by using "byte" or "short" insead of "int". They're probably
allocated on 32-bit boundaries, just like the larger types, with the
unused 24 or 16 bits simply wasted.

Could very well be.

Arne

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

Re: Extending operator + (plus) for byte/short type

Mike Schilling wrote:

Mike Schilling wrote:

>Arne Vajhøj wrote:

>>K Viltersten wrote:
>>>While i know that the bytes are cheap today,
>>>i still prefer to use a byte (or short) when i know that the
>>>entity
>>>counted isn't larger
>>>than 255 (or 65k).

>That is, 127 or 32767. Both types are signed.
>>

>>>However, it's a real pain
>>>to cast every time i perform an operation.
>>>>
>>>Example:
>>>private byte a, b;
>>>public byte MyProperty
>>>{ get { return (byte)(a + b); } }
>>>>
>>>How can i avoid doing that? I'd like to redeclare/overload the
>>>arithmetic al operators so they return a byte (or short)
>>>when computing two bytes (or shorts).
>>>>
>>>Is it easily doable? Is it doable?
>>I don't think it is doable.
>>>
>>You should change your coding style and use int. Not only is the
>>space
>>saving insignificant, but you potentially could end up spending
>>more
>>CPU cycles and memory for code.

>Unless you've got arrays of them, I suspect that there's no space
>saved by using "byte" or "short" insead of "int". They're probably
>allocated on 32-bit boundaries, just like the larger types, with the
>unused 24 or 16 bits simply wasted.

>
Please ignore the foregoing; I hadn't realized I was in a C# group
rather than a Java group.

Besides the byte type range, then it should be just as valid for C#.

Arne

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

Re: Extending operator + (plus) for byte/short type

Jeroen Mostert wrote:

K Viltersten wrote:

>While i know that the bytes are cheap today,
>i still prefer to use a byte (or short) when i know that the entity
>counted isn't larger
>than 255 (or 65k). However, it's a real pain
>to cast every time i perform an operation.
>>
>Example:
>private byte a, b;
>public byte MyProperty
>{ get { return (byte)(a + b); } }
>>

It *should* be a pain. You get a good indication of the work the CPU has
to do.
>
Operating on 32-bit integers is vastly more efficient for a 32-bit CPU
than operating on bytes.

Usually X bit CPU means that the virtual addresses are X bits wide.

It does not say anything about register width, memory bus width, width
of instruction operands etc..

I am rather confident that modern CPU's are indeed more optimized for
operations on 32 bit entities than 8 bit entities (even though x86 is
traditionally very byte and short friendly), so I agree with your
conclusion, but I will not tie it the 32 bitness.

About the only time you encounter bytes is in byte arrays. Individual
bytes are converted to ints for any nontrivial operation, and they
should stay that way until you store them back.

Agree.

Public properties should basically never be smaller than an int, it
doesn't pay (unless, again, you can show that you really need the
memory) or when they're part of a predefined interop structure.

I would tend to let the modeling determine the type.

Arne

[Jeroen Mostert]

Re: Extending operator + (plus) for byte/short type

Arne Vajhøj wrote:

Jeroen Mostert wrote:

>K Viltersten wrote:

>>While i know that the bytes are cheap today,
>>i still prefer to use a byte (or short) when i know that the entity
>>counted isn't larger
>>than 255 (or 65k). However, it's a real pain
>>to cast every time i perform an operation.
>>>
>>Example:
>>private byte a, b;
>>public byte MyProperty
>>{ get { return (byte)(a + b); } }
>>>

>It *should* be a pain. You get a good indication of the work the CPU
>has to do.
>>
>Operating on 32-bit integers is vastly more efficient for a 32-bit CPU
>than operating on bytes.

>
Usually X bit CPU means that the virtual addresses are X bits wide.
>
It does not say anything about register width, memory bus width, width
of instruction operands etc..
>

True, true -- although the term "X-bit CPU" is actually vague enough to
indicate any of these things.

>Public properties should basically never be smaller than an int, it
>doesn't pay (unless, again, you can show that you really need the
>memory) or when they're part of a predefined interop structure.

>
I would tend to let the modeling determine the type.
>

If your model actually includes 16-bit and 8-bit types, sure. Most models
don't happen to include things like "integers with a range of -32,768 to
32,767", though -- and when they do, modeling them with the most convenient
integer type (rather than the one that would fit the range exactly) is still
not a bad idea.

--
J.

[Jeroen Mostert]

Re: Extending operator + (plus) for byte/short type

Jeroen Mostert wrote:
<snip>

If your model actually includes 16-bit and 8-bit types, sure. Most
models don't happen to include things like "integers with a range of
-32,768 to 32,767", though -- and when they do, modeling them with the
most convenient integer type (rather than the one that would fit the
range exactly) is still not a bad idea.
>

This should be "implementi ng them", obviously.

--
J.

[Mike Schilling]

Re: Extending operator + (plus) for byte/short type

Arne Vajhøj wrote:

Mike Schilling wrote:

>Mike Schilling wrote:

>>Arne Vajhøj wrote:
>>>K Viltersten wrote:
>>>>While i know that the bytes are cheap today,
>>>>i still prefer to use a byte (or short) when i know that the
>>>>entity
>>>>counted isn't larger
>>>>than 255 (or 65k).
>>That is, 127 or 32767. Both types are signed.
>>>
>>>>However, it's a real pain
>>>>to cast every time i perform an operation.
>>>>>
>>>>Example:
>>>>private byte a, b;
>>>>public byte MyProperty
>>>>{ get { return (byte)(a + b); } }
>>>>>
>>>>How can i avoid doing that? I'd like to redeclare/overload the
>>>>arithmetica l operators so they return a byte (or short)
>>>>when computing two bytes (or shorts).
>>>>>
>>>>Is it easily doable? Is it doable?
>>>I don't think it is doable.
>>>>
>>>You should change your coding style and use int. Not only is the
>>>space
>>>saving insignificant, but you potentially could end up spending
>>>more
>>>CPU cycles and memory for code.
>>Unless you've got arrays of them, I suspect that there's no space
>>saved by using "byte" or "short" insead of "int". They're
>>probably
>>allocated on 32-bit boundaries, just like the larger types, with
>>the
>>unused 24 or 16 bits simply wasted.

>>
>Please ignore the foregoing; I hadn't realized I was in a C# group
>rather than a Java group.

>
Besides the byte type range, then it should be just as valid for C#.

Perhaps. It's possible for the JIT to allocate all of the bytes
together on 8-bit boundaries, all the shorts together on 16-bit
boundaries, etc. I know that Java doesn't do this (at least for
local variables) from the JVM specs; I don't know how one would
determine this in .NET.

[Ben Voigt [C++ MVP]]

Re: Extending operator + (plus) for byte/short type

Jeroen Mostert wrote:

K Viltersten wrote:

>While i know that the bytes are cheap today,
>i still prefer to use a byte (or short) when i know that the entity
>counted isn't larger
>than 255 (or 65k). However, it's a real pain
>to cast every time i perform an operation.
>>
>Example:
>private byte a, b;
>public byte MyProperty
>{ get { return (byte)(a + b); } }
>>

It *should* be a pain. You get a good indication of the work the CPU
has to do.
Operating on 32-bit integers is vastly more efficient for a 32-bit
CPU than operating on bytes. The only reason you could have to use
bytes is to save memory, but you have to be pretty tight on that
before you can justify the slowdown in processing. And you have to
show that you're actually *saving* memory: more instructions are
needed to manipulate bytes, and those take up memory too.

All x86 CPUs have 8- and 16-bit versions of most instructions. They may or
may not have longer encodings than the 32-bit ones. Certainly using 8- or
16-bit immediate values is faster than 32-bit immediate values.

>
About the only time you encounter bytes is in byte arrays. Individual
bytes are converted to ints for any nontrivial operation, and they
should stay that way until you store them back.
>
Public properties should basically never be smaller than an int, it
doesn't pay (unless, again, you can show that you really need the
memory) or when they're part of a predefined interop structure.
>
Using "short" or "byte" to enforce ranges is a bad idea: it's easy to
throw in a cast to force the value to be in range, but does this actually
produce the correct result? Checking the range explicitly in the
setter is a better idea.

Unless you're on a communication boundary, such as sockets. If the field is
16-bits then better to use a short variable than send something different
from what the user requested.

>

>How can i avoid doing that? I'd like to redeclare/overload the
>arithmetical operators so they return a byte (or short)
>when computing two bytes (or shorts).
>>

Can't be done in C#. In fact, it can't be done in any .NET language
I'm aware of. Those operations map to CLR primitives and overloading them
from a language would be decidedly strange -- not to mention
inefficient.

While overloading operators on built-in types (all operands are built-in
types) is not possible in any language I know, C++/CLI certainly is a .NET
language that doesn't suffer from the problem of operators performing
unnecessary integral promotion.