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?

 

[Arne Vajhøj]

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]

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.

 

[Mike Schilling]

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

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]

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


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.

 

[Arne Vajhøj]

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.

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

 

[Arne Vajhøj]

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

 

[Arne Vajhøj]

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

 

[K Viltersten]

While i know that the bytes are cheap today,

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

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.

I don't approve. I hate you all!
SLAM! <slamming the door>
Woooooaaaaa....! <crying behind the door>
" " <awkward silence>
....
Sight... <acceptance of the better ways>



Got it. Thanks. I guess i was trying to be a
smart ass and missing on the first, i only
landed on the latter.

 

[Jeroen Mostert]

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.

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.

 

[Jeroen Mostert]

Jeroen Mostert wrote:

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 "implementing them", obviously.

 

[Mike Schilling]

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]]

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.

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.

 

[Ben Voigt [C++ MVP]]

I don't approve. I hate you all!
SLAM! <slamming the door>
Woooooaaaaa....! <crying behind the door>
" " <awkward silence>
...
Sight... <acceptance of the better ways>



Got it. Thanks. I guess i was trying to be a
smart ass and missing on the first, i only
landed on the latter.

While one can make an argument that it's better for byte * byte to return
int than byte, it's absolute insanity that byte & byte returns anything
larger than byte.