Why should casting be avoided? [closed]

Answer 1

To elaborate on KDeveloper's answer, it's not inherently type-safe. With casting, there is no guarantee that what you are casting from and casting to will match, and if that occurs, you will get a runtime exception, which is always a bad thing.

With specific regards to C#, because it includes the is and as operators, you have the opportunity to (for the most part) make the determination as to whether or not a cast would succeed. Because of this, you should take the appropriate steps to determine whether or not the operation would succeed and proceed appropriately.

Answer 2

To be really concise, a good reason is because of portability. Different architecture that both accommodate the same language might have, say, different sized ints. So if I migrate from ArchA to ArchB, which has a narrower int, I might see odd behavior at best, and seg faulting at worst.

(I'm clearly ignoring architecture independent bytecode and IL.)

Answer 3

Casting is not inherently bad, it's just that it's often misused as a means to achieve something that really should either not be done at all, or done more elegantly.

If it was universally bad, languages would not support it. Like any other language feature, it has its place.

My advice would be to focus on your primary language, and understand all its casts, and associated best practices. That should inform excursions into other languages.

The relevant C# docs are here.

There is a great summary on C++ options at a previous SO question here.

Answer 4

Not sure if someone already mentioned this, but in C# casting can be used in a rather safe manner, and is often necessary. Suppose you receive an object which can be of several types. Using the is keyword you can first confirm that the object is indeed of the type you are about to cast it to, and then cast the object to that type directly. (I didn't work with Java much but I'm sure there's a very straightforward way of doing it there as well).

Answer 5

You only cast an object to some type, if 2 conditions are met:

1. you know it is of that type
2. the compiler doesn't

This means not all the information you have is well represented in the type structure you use. This is bad, because your implementation should semantically comprise your model, which it clearly doesn't in this case.

Now when you do a cast, then this can have 2 different reasons:

1. You did a bad job in expressing the type relationships.
2. the languages type system simply is not expressive enough to phrase them.

In most languages you run into the 2nd situation a lot of times. Generics as in Java help a bit, the C++ template system even more, but it is hard to master and even then some things may be impossible or just not worth the effort.

So you could say, a cast is a dirty hack to circumvent your problems to express some specific type relationship in some specific language. Dirty hacks should be avoided. But you can never live without them.

Answer 6

I'm mostly speaking for C++ here, but most of this probably applies to Java and C# as well:

C++ is a statically typed language. There are some leeways the language allows you in this (virtual functions, implicit conversions), but basically the compiler knows the type of every object at compile-time. The reason to use such a language is that errors can be caught at compile-time. If the compiler know the types of a and b, then it will catch you at compile-time when you do a=b where a is a complex number and b is a string.

Whenever you do explicit casting you tell the compiler to shut up, because you think you know better. In case you're wrong, you will usually only find out at run-time. And the problem with finding out at run-time is, that this might be at a customer's.