Can i avoid typecasting all the time by overloading an operator

[Jon Skeet [C# MVP]]

I'm working on a project where i use a
lot of sbyte-type variables. I notice
that most (all?) operators tend to cast
the result into int type.

While i can easily recast e.g.

sbyte something = else % 10;

into

sbyte something = (sbyte)(else % 10);

it make the code look less readable
and is a bit tedious. I've been thaugt
that overloading is a no-no, but
perhaps it's a good idea to do it here.

1. Can i overload e.g. modulo operator
using some sort of extension method,
in such manner so it looks like "%"
still but returns sbyte type?

2. Should i do so?

3. How (if not easily googleable and/or
connected to evil gotchas)?

Do all your sbyte variables actually have the same logical type? If so,
why not encapsulate that in your own type, instead of using sbyte? (It
would probably be *backed* by an sbyte).

Then you can define your own operators for your type, which will
probably all return values of the same type.

 

[K Viltersten]

I'm working on a project where i use a
lot of sbyte-type variables. I notice
that most (all?) operators tend to cast
the result into int type.

While i can easily recast e.g.

sbyte something = else % 10;

into

sbyte something = (sbyte)(else % 10);

it make the code look less readable
and is a bit tedious. I've been thaugt
that overloading is a no-no, but
perhaps it's a good idea to do it here.

1. Can i overload e.g. modulo operator
using some sort of extension method,
in such manner so it looks like "%"
still but returns sbyte type?

2. Should i do so?

3. How (if not easily googleable and/or
connected to evil gotchas)?

 

[K Viltersten]

While i can easily recast e.g.

sbyte something = else % 10;

into

sbyte something = (sbyte)(else % 10);

it make the code look less readable
and is a bit tedious. I've been thaugt
that overloading is a no-no, but
perhaps it's a good idea to do it here.

Hrmp... I Don't think this code would
compile, due to the name of the variable.

I can't believe nobody noticed it! I just
saw it myself! Shame on you, Mr. Skeet,
for missing that! It was an open goal...

 

[Jon Skeet [C# MVP]]

Hrmp... I Don't think this code would
compile, due to the name of the variable.

I'd kind of assumed it was pseudo-code... You could always make it:

sbyte something = (sbyte)(@else % 10);

Best not to though.

I can't believe nobody noticed it! I just
saw it myself! Shame on you, Mr. Skeet,
for missing that! It was an open goal...

 

[Mythran]

it make the code look less readable

and is a bit tedious. I've been thaugt
that overloading is a no-no, but perhaps it's a good idea to do it here.

Wha?!? Who told you that overloading is a no-no? Operating overloading is
there for a reason, and it works great! Why would someone not want you
using operating overloading (if used appropriately and correctly)?

Mythran

 

[K Viltersten]

it make the code look less readable

Wha?!? Who told you that overloading is
a no-no? Operating overloading is there
for a reason, and it works great! Why
would someone not want you using
operating overloading (if used
appropriately and correctly)?

One of my supervisors during my master's
thesis. I'm not claiming him to be right
nor wrong (and perhaps it was a different
type of project).

Anyhow, i'm taking your advice gladly.

 

[Jon Skeet [C# MVP]]

One of my supervisors during my master's
thesis. I'm not claiming him to be right
nor wrong (and perhaps it was a different
type of project).

Anyhow, i'm taking your advice gladly.

I would say that operator overloading should be used *very* cautiously.
I can't remember the last time I felt the need to do it (aside from
demo Complex structs). When it's useful, it's very useful. When it's
abused, it's a readability nightmare.

 

[Mythran]

I would say that operator overloading should be used *very* cautiously.
I can't remember the last time I felt the need to do it (aside from
demo Complex structs). When it's useful, it's very useful. When it's
abused, it's a readability nightmare.

Aye, Jon, and as you probably noticed, I did add at the end of my previous
post "if used appropriately and correctly". But I probably could have used
a more precise term or statement that made it clearer.

--- BELOW IS AN OFF TOPIC REMARK ---

Jon, I was just gonna email ya before you posted this reply....

Read the following link:

http://www.evga.com/articles/395.asp

Now buy it for me.

Ok? Whew, glad I convinced ya to send it to me.

Thanks,
Mythran